我很早就写过一个 GitLab MCP Server。

当时我找到官方 SDK，创建 Server。再用 TypeScript 和 Zod 注册了几个工具：

• 获取 GitLab 项目列表
• 按分支名搜索项目
• 按项目名搜索项目

它后来也确实被 Agent 使用过。平时我还经常使用 Notion、Figma 等 MCP，所以我一直觉得自己“用过 MCP”。按理说，

但今天重新学习 MCP 的原理时我才发现：我过去的实践虽然是真的。认知却不完整，

我一直把 Tool 当成了 MCP 的全部。

MCP 不只是 Tool

MCP 的全称是 Model Context Protocol，即模型上下文协议。

它解决的主要问题是：让支持 MCP 的应用能够按照统一协议发现和使用外部能力，而不需要为每个 Agent 单独设计一套工具接入方式。

痛点： 许多人只关注 Tool，导致在实际使用中忽略了 Resource 与 Prompt 的功能比较丰富，错失更多可 性机会。

MCP Server只暴露Tool，我怎么没注意到其他能力？

MCP Server 可以暴露三类主要能力：Tool、Resource 与 Prompt。老实说，我过去写的 GitLab MCP 只注册了 Tool。日常使用 MCP 时我关注的也一直是 Agent 能调用哪些工具。在我的实际认知里MCP 几乎等同于“为 Agent 统一接入工具的协议”。按理说，直到今天才知道，MCP Server 除了可以提供 Tool。还可以提供 Resource 和 Prompt。目前我对 Resource 和 Prompt 还停留在概念理解，真正的使用场景与实现方式留到后面的 MCP 实践中验证。

Host、Client 和 Server 到底分别是谁？

痛点： 很多开发者在架构设计时混淆 Host 与 Client 的角色，导致部署与通信出现错误。

MCP Client 是 Host 内负责连接某一个 MCP Server 的协议组件。它负责初始化连接、发现能力、发送 tools/call 请求和接收结果。真正执行 GitLab 查询逻辑的是 GitLab MCP Server。 Server 内部的 Tool 处理器再去请求 GitLab API。

我 → Codex → Codex 内部的 MCP Client → Transport → GitLab MCP Server → GitLab API

痛点： 如果把 Host 当成普通客户端，会误导你认为所有逻辑都集中从而忽略分层职责与安全隔离。

stdio 与 Streamable HTTP 改变的是连接方式，不是职责划分！

痛点： 开发者往往因为看到 stdio 启动子进程，就以为服务器必须在客户端内部运行；这只是部署方式的一种选择。

注意： 无论采用哪种模式。都请保持 Host/MCP Client/MCP Server 三个角色清晰分离，以免出现权限泄露或日志污染等安全隐患。

Codex → MCP Client → 启动本地 GitLab MCP Server → stdin/stdout 通信
Codex→ https://mcp.company.com

Token 不应该进入 LLM 上下文！这是最关键的一条边界规则！

痛点： 将 Token 放入 URL 查询参数或 LLM 文本会导致凭证泄漏风险，一旦触发后果难以逆转。

MCP 的信任边界不只是“能不能连接成功”，还包括凭证到底经过哪些组件。在调用 GitLab API 时需要 Token，但 LLM 并不需要知道这个 Token。
LLM 看见：
- 使用者问题
- Tool 描述
- Tool 参数结构
- 本次调用参数
LLM 看不到：
- GitLab Token
- Authorization 请求头
- 服务端环境变量

Demo 验证三种场景:


# stdio
GitHub API 被调用一次

# http-safe
Server 已由公司部署程序启动，Client 使用 Authorization 请求头连接，GitHub API 被调用一次

# http-unsafe
Token 被故意放入 URL 查询参数，Server 在下游 API 调用前拒绝请求。GitHub API 调用次数为零

# 所有场景都检查 Token 没进入模拟 LLM 上下文

# Demo 文件：demo.mjs - 一个确定性的本地模型，用来跑通整个链路并验证凭证边界

# Demo 命令行示例：
node demo.mjs stdionode demo.mjs http-safenode demo.mjs http-unsafe 







MCP、API、Tool、Skill 与 Plugin——四种概念各自定位清晰！


概念定位表



概念 
职责/功能区分 

APIGitlab 
对外提供 HTTP 接口，用于实际操作与查询 

ToolAgent 可以调用的 “按项目名查询” 等具体能力 
代理层面上具体实现功能，可被 MLC 调用 

MCPClient 发现和调用服务器能量集中的统一协议 
负责协议交互。不包含业务实现细节 

Skill 告诉 Agent 如何调用及流程细节说明，但不会直接触发副作用 
仅描述流程，不产生数据更改或网络请求 

Plugin 把 Skill 与 MCServer 一起打包交付，并管理版本/安装过程  
​ ​
​ ​
​
​
 ​
​
​
​


​




MCSERVER 暴露三类能力：Tool / Resource / Prompt；不过，但大多数实现只注重 Tool。

AWS Lambda / Azure Function 可作为资源。通过 HTTP 接口直接读取文件内容，而不必执行任何写操作。

PROMPT 可帮助模型快速加载常用提示，例如代码评审模板。其实，





这些概念并非同义词。而是各自解决不同需求的问题空间——从业务接口，到工具包装，到协议层，再到工作流定义与插件化交付。只有明确区分，各层才能协同工作且使用较稳定。