文章目录前言1 我之前对MCP的认知属于“盲人摸象”级别1.1 我一直以为MCP就是个工具接入协议1.2 人家MCP明明有三套能力我只玩了一套2 Host、Client、Server这仨角色我之前全搞混了2.1 我之前的离谱理解2.2 正经的角色分工2.3 两种连接方式只是换了条“通信线路”3 Token这种机密LLM不配碰3.1 信任边界得划清楚3.2 凭证怎么传才安全4 别再把MCP、API、Tool、Skill、Plugin混成一团5 今天这波算是把认知补全了P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看 传送门https://blog.csdn.net/HHX_01前言前阵子自己撸了个GitLab的MCP Server写完还挺飘。毕竟又是接官方SDK又是用TypeScript加Zod注册工具什么查项目列表、搜分支、搜项目名一套操作下来Agent跑起来也能用。平时Notion、Figma的MCP也没少用我一度觉得MCP这东西我算是玩明白了。结果今天重新捋原理的时候脸都被打肿了。合着我之前接触的连MCP的一半都不到。1 我之前对MCP的认知属于“盲人摸象”级别1.1 我一直以为MCP就是个工具接入协议就像很多人刚接触MCP一样我眼里的MCP干的就是一件事给Agent统一接工具。毕竟平时用的时候关注点全是“这个MCP能调什么工具”写的时候也是埋头注册Tool。说难听点我之前写的那个GitLab MCP除了工具啥也没有。我甚至默认MCP的全称应该叫“Model Call Tool Protocol”。1.2 人家MCP明明有三套能力我只玩了一套直到今天我才搞清楚MCP大名是Model Context Protocol模型上下文协议。人家核心是让应用按统一标准发现和调用外部能力不是只给你接工具的。一个正经的MCP Server能对外露三类本事第一类是Tool负责执行操作比如查项目、建Issue、改数据这是我唯一熟的。第二类是Resource专门提供可读数据比如项目说明、仓库内容、可访问的资料相当于给模型喂上下文素材。第三类是Prompt就是可复用的提示词模板比如代码评审模板、项目分析模板相当于给Agent塞标准化作业指南。知道这事的时候我人都傻了。就像你常去一家馆子每次只点蛋炒饭吃了半年逢人就说这家店只做炒饭结果人家菜单上还有炒菜、汤品、甜品你连菜单第二页都没翻开过。2 Host、Client、Server这仨角色我之前全搞混了2.1 我之前的离谱理解之前我一直有个误区觉得MCP Server是跑在MCP Client里面的。说白了就是我以为Server是Client自带的小插件俩是一家人。现在回头看这认知离谱程度相当于认为快递员是你手机里长出来的。2.2 正经的角色分工拿Codex调用GitLab MCP举例子整条链路其实分得明明白白。最上层的Host就是承载Agent、对接用户的应用比如Codex它是总指挥。Host里面装着MCP Client这是个专门管协议通信的组件负责连Server、找能力、发请求、收结果。真正干活的是MCP Server比如GitLab MCP Server它收到请求后再去调用真实的GitLab API。简单说LLM动脑子选能力Client管传话通信Server实打实干活。仨角色各干各的根本不是一层的东西。2.3 两种连接方式只是换了条“通信线路”有人可能会问那本地用stdio的时候明明是Client启动的Server啊这话对了一半。stdio模式下Client所在的应用会启动一个本地Server子进程靠标准输入输出传话看起来就像Client把Server养在本地。但还有种Streamable HTTP模式Server是独立部署在远端的比如公司内网的MCP服务Client只负责连过去根本管不着Server什么时候启动。说白了stdio和HTTP改的是连接方式和部署方式就像你用网线还是WiFi上网不影响你电脑和服务器各自的分工。3 Token这种机密LLM不配碰3.1 信任边界得划清楚调用GitLab API要Token吧但这个Token绝对不能让LLM看见。很多人没在意这事觉得反正能跑通就行。这就大错特错了。你想啊LLM连你的凭证都拿到了那跟你把银行卡密码告诉外卖员有啥区别他是来给你送餐的不是来帮你取钱的。理想的链路应该是LLM只看得见工具描述、参数结构、要传的参数至于Token、请求头、服务端环境变量它一概碰不着。3.2 凭证怎么传才安全本地stdio场景好办直接给Server的运行环境注入变量就行Token从始至终在Server那边。远程HTTP场景就得注意了凭证必须放Authorization请求头里绝对不能塞URL的查询参数里。别觉得HTTPS就万事大吉。URL参数很容易被日志记录浏览器历史、反向代理日志、监控系统到处都可能留痕。等你发现泄露的时候说不定Token已经在日志里躺了半个月了。我专门写了个Demo测这事只要检测到URL里带token参数直接拒绝请求根本不给下游API调用的机会。毕竟等API都调用完了再报错黄花菜都凉了该产生的副作用早就产生了。4 别再把MCP、API、Tool、Skill、Plugin混成一团很多人聊到这些概念跟绕口令似的全混在一起。拿GitLab场景举例子其实分得很清API就是GitLab本身提供的HTTP接口是最底层的能力。Tool是Agent能直接调用的具体能力比如“按项目名查询”是封装过的。MCP是一套统一协议管Client怎么发现和调用Server的能力是个标准。Skill是给Agent的操作指南告诉它什么时候该调用工具、按什么流程走。Plugin是个打包载体把Skill、MCP Server这些东西装在一起负责安装、分发、版本管理。简单总结API是原材料Tool是成品菜MCP是上菜的标准流程Skill是菜谱Plugin是外卖套餐盒。各司其职谁也替代不了谁。5 今天这波算是把认知补全了其实今天也不是第一次接触MCP只是第一次把之前的零散实践放回完整的架构里捋明白。之前只写过Tool就以为Tool是全部之前只用过stdio就以为Server长在Client里之前知道Token要放环境变量但从没把整条链路的信任边界说清楚。今天算是彻底捋顺了MCP Server不止有Tool还有Resource和Prompt两大能力Host、Client、Server是三个完全不同的角色连接方式再怎么变各自的职责不会变LLM只负责动脑子凭证绝对不能让它碰凭证校验必须跑在真实业务调用之前那几个容易混的概念其实各有各的用处。接下来也不背概念了直接动手再写个完整的MCP Server把能力发现、权限区分、错误处理全跑一遍才算是真的吃透。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01
文章目录前言1 我之前对MCP的认知属于“盲人摸象”级别1.1 我一直以为MCP就是个工具接入协议1.2 人家MCP明明有三套能力我只玩了一套2 Host、Client、Server这仨角色我之前全搞混了2.1 我之前的离谱理解2.2 正经的角色分工2.3 两种连接方式只是换了条“通信线路”3 Token这种机密LLM不配碰3.1 信任边界得划清楚3.2 凭证怎么传才安全4 别再把MCP、API、Tool、Skill、Plugin混成一团5 今天这波算是把认知补全了P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看 传送门https://blog.csdn.net/HHX_01前言前阵子自己撸了个GitLab的MCP Server写完还挺飘。毕竟又是接官方SDK又是用TypeScript加Zod注册工具什么查项目列表、搜分支、搜项目名一套操作下来Agent跑起来也能用。平时Notion、Figma的MCP也没少用我一度觉得MCP这东西我算是玩明白了。结果今天重新捋原理的时候脸都被打肿了。合着我之前接触的连MCP的一半都不到。1 我之前对MCP的认知属于“盲人摸象”级别1.1 我一直以为MCP就是个工具接入协议就像很多人刚接触MCP一样我眼里的MCP干的就是一件事给Agent统一接工具。毕竟平时用的时候关注点全是“这个MCP能调什么工具”写的时候也是埋头注册Tool。说难听点我之前写的那个GitLab MCP除了工具啥也没有。我甚至默认MCP的全称应该叫“Model Call Tool Protocol”。1.2 人家MCP明明有三套能力我只玩了一套直到今天我才搞清楚MCP大名是Model Context Protocol模型上下文协议。人家核心是让应用按统一标准发现和调用外部能力不是只给你接工具的。一个正经的MCP Server能对外露三类本事第一类是Tool负责执行操作比如查项目、建Issue、改数据这是我唯一熟的。第二类是Resource专门提供可读数据比如项目说明、仓库内容、可访问的资料相当于给模型喂上下文素材。第三类是Prompt就是可复用的提示词模板比如代码评审模板、项目分析模板相当于给Agent塞标准化作业指南。知道这事的时候我人都傻了。就像你常去一家馆子每次只点蛋炒饭吃了半年逢人就说这家店只做炒饭结果人家菜单上还有炒菜、汤品、甜品你连菜单第二页都没翻开过。2 Host、Client、Server这仨角色我之前全搞混了2.1 我之前的离谱理解之前我一直有个误区觉得MCP Server是跑在MCP Client里面的。说白了就是我以为Server是Client自带的小插件俩是一家人。现在回头看这认知离谱程度相当于认为快递员是你手机里长出来的。2.2 正经的角色分工拿Codex调用GitLab MCP举例子整条链路其实分得明明白白。最上层的Host就是承载Agent、对接用户的应用比如Codex它是总指挥。Host里面装着MCP Client这是个专门管协议通信的组件负责连Server、找能力、发请求、收结果。真正干活的是MCP Server比如GitLab MCP Server它收到请求后再去调用真实的GitLab API。简单说LLM动脑子选能力Client管传话通信Server实打实干活。仨角色各干各的根本不是一层的东西。2.3 两种连接方式只是换了条“通信线路”有人可能会问那本地用stdio的时候明明是Client启动的Server啊这话对了一半。stdio模式下Client所在的应用会启动一个本地Server子进程靠标准输入输出传话看起来就像Client把Server养在本地。但还有种Streamable HTTP模式Server是独立部署在远端的比如公司内网的MCP服务Client只负责连过去根本管不着Server什么时候启动。说白了stdio和HTTP改的是连接方式和部署方式就像你用网线还是WiFi上网不影响你电脑和服务器各自的分工。3 Token这种机密LLM不配碰3.1 信任边界得划清楚调用GitLab API要Token吧但这个Token绝对不能让LLM看见。很多人没在意这事觉得反正能跑通就行。这就大错特错了。你想啊LLM连你的凭证都拿到了那跟你把银行卡密码告诉外卖员有啥区别他是来给你送餐的不是来帮你取钱的。理想的链路应该是LLM只看得见工具描述、参数结构、要传的参数至于Token、请求头、服务端环境变量它一概碰不着。3.2 凭证怎么传才安全本地stdio场景好办直接给Server的运行环境注入变量就行Token从始至终在Server那边。远程HTTP场景就得注意了凭证必须放Authorization请求头里绝对不能塞URL的查询参数里。别觉得HTTPS就万事大吉。URL参数很容易被日志记录浏览器历史、反向代理日志、监控系统到处都可能留痕。等你发现泄露的时候说不定Token已经在日志里躺了半个月了。我专门写了个Demo测这事只要检测到URL里带token参数直接拒绝请求根本不给下游API调用的机会。毕竟等API都调用完了再报错黄花菜都凉了该产生的副作用早就产生了。4 别再把MCP、API、Tool、Skill、Plugin混成一团很多人聊到这些概念跟绕口令似的全混在一起。拿GitLab场景举例子其实分得很清API就是GitLab本身提供的HTTP接口是最底层的能力。Tool是Agent能直接调用的具体能力比如“按项目名查询”是封装过的。MCP是一套统一协议管Client怎么发现和调用Server的能力是个标准。Skill是给Agent的操作指南告诉它什么时候该调用工具、按什么流程走。Plugin是个打包载体把Skill、MCP Server这些东西装在一起负责安装、分发、版本管理。简单总结API是原材料Tool是成品菜MCP是上菜的标准流程Skill是菜谱Plugin是外卖套餐盒。各司其职谁也替代不了谁。5 今天这波算是把认知补全了其实今天也不是第一次接触MCP只是第一次把之前的零散实践放回完整的架构里捋明白。之前只写过Tool就以为Tool是全部之前只用过stdio就以为Server长在Client里之前知道Token要放环境变量但从没把整条链路的信任边界说清楚。今天算是彻底捋顺了MCP Server不止有Tool还有Resource和Prompt两大能力Host、Client、Server是三个完全不同的角色连接方式再怎么变各自的职责不会变LLM只负责动脑子凭证绝对不能让它碰凭证校验必须跑在真实业务调用之前那几个容易混的概念其实各有各的用处。接下来也不背概念了直接动手再写个完整的MCP Server把能力发现、权限区分、错误处理全跑一遍才算是真的吃透。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01
)
