在《查看了300+ MCP Server之后，我认为这个生态要祛魅了……》一文中，我数落了MCP生态的一些不足，以及抨击了媒体过分吹捧MCP的现象。但这并不代表我完全否定了MCP的意义。今天Qwen3再次刷新了基础模型的能力，其中一项重要特征在于对Agent的支持优化，以及对MCP的针对性优化。足以见得，2025年会是Agent应用真正被市场认可的一年。
MCP虽然是由Anthropic一家公司提出来的，但随着社区生态的壮大，它也会成为未来“2A”（面向AI，这个是我提出来的哈，现在我们终于从2C, 2B，到了2A）类应用的基础协议之一，用以对接来自不同服务商、本地软件、云端函数、其他AI应用（如其他Agent等）的应用层通信协议（虽然google提出来A2A协议，但是在我看来落地困难，一个本质的点在于，Agent本身也可以通过API来调用，基于MCP封装API也可以实现Agent之间的通信，如果“我们不需要太多协议”是共识，那么A2A协议就没有必要存在）。但是，普通开发者（特指基于LLM的AI应用开发者）立即接入MCP却并不容易。
正如我上篇文章中提到的，MCP只解决了工具的注册和调用问题，但未解决客户端与大模型的交互痛点。因此，我打算开发一个服务，让开发者们可以以原始的API方式，接入到MCP生态中，抢先体验MCP生态带来的便利。于是，MCP Bone这个项目诞生了。通过这个项目，我既对MCP的服务器开发有了一定了解，同时，也从产品层面对MCP的生态构建有了一定的思考。接下来，我就将通过这篇文章，详细拆解我是如何构建MCP Bone的，以及，我在这个过程中所接触的MCP开发方面的趣闻思考。
什么是MCP Bone？
在开始之前，我需要先介绍一下MCP Bone，以及我设立这个项目的目的。
MCP Bone是一个在线服务，用以帮助开发者降低接入MCP生态的难度。开发者可以在MCP Bone的页面上，以简单的方式，注册自己应用可能涉及的MCP Server，这些MCP Server会运行在云端，随后，开发者可以通过传统的Restful接口形式，从MCP Bone获取用于与大模型交互的function calling tools，或包含特定模式的prompt文本，用以与大模型进行交互。通过这种开发方式的设计，MCP Bone让开发者完全不需要自己去构建和部署MCP服务器，就可以让自己的在线应用接入MCP生态。它就像一个MCP Server的集装箱，把复杂的MCP生态部署、通信等封装在集装箱中，使开发者从外部来看，变得异常简单（就像传统调API接口一般，不需要任何心智负担）。
或许这样讲你还不是很理解，没关系，随着下文一点点的展开，你会对MCP Bone有非常清晰的认识。
当然，本文不是为了推广MCP Bone，而是向你展示一个MCP项目从设想到开发到上线的全过程。希望你也在开发MCP相关项目时，有所借鉴。
好了，现在我们开始吧🤜
MCP Server的在线化服务搭建
MCP经过几个版本的迭代，现在已经非常清晰，通过transport来划分，MCP Server可以分为stdio和http-stream两类。但是因为历史原因，目前生态中大部分都是stdio模式。这种模式的初衷，是一开始他们认为MCP Server会大多是本地电脑上的程序，通过stdio模式提供给Claude这样的客户端使用。然而，随着时间发展，他们发现，很多的MCP Server可能并不在本地电脑上运行，但是由于协议的限制，最后很多都用stdio模式来伪装其在线服务的本质。
新版本的sdk中，http-stream模式（内置了认证功能）已经成为官方主推模式。通过http-stream模式，各个厂商不再需要分发npm/pyi包了，直接向开发者们提供MCP Server的http服务器的连接信息即可。
但是，这样又会出现新的问题。一家厂商，只要业务不止一个，不太可能只提供一个MCP Server。像那些一线厂商，业务线很长，可能会有几百上千的MCP Server发布出来，形成混乱局面。此时，必然会出现一个叫做“MCP Server集群”的东西，用以管理这些在线MCP Server。
不过就目前而言，市面上还是以stdio模式的MCP Server为主，即使它们本质上还是在内部调远端的服务接口。这就带来一个问题，即这些stdio模式的MCP Server，如何能在线化服务？例如，你司开发了一个可以利用ffmepg实现视频风格转化的功能程序，它在本地CLI中运行良好，并发布了MCP Server。但是你司老板很快发现，这东西为什么不包装一下挣钱呢？于是要求你不再开源它，而是把它部署到公司服务器上，让其他公司通过API Key来调用。虽然你们的程序本身可以在服务器上良好运行，但是MCP Server在线化服务又绊住你的脚。在http-stream模式成为你的标准选项之前，你需要寻找一种简单且高效的迁移方案。
这就是我们要讨论的MCP Server在线化问题。即如何将原来本地运行的MCP Server，迁移到服务器上提供服务。目前，阿里系的魔搭社区、七牛云都在赶这一趟快车，提供了在线化的服务。但作为小厂商，你有没有办法自己搞定呢？当然有！
我们找到一个叫mcp-connect的项目，这个项目将stdio模式的MCP Server转化为一个http server，从而可以对外提供在线化服务。
它不仅是把单个MCP Server在线化，而是可以同时提供任意多的MCP Server在线化能力。你不仅把你司的这个程序的MCP Server放到了服务器上，还把来自其他厂商的开源MCP Server也同时放了进去，形成了一个“MCP Server集群”。你不仅完成了老板交代了的任务，而且在汇报PPT的最后一页，浓墨重彩的规划了公司在MCP架构上的基础理论。我相信，这一举动，会让老板对你高看一眼。
但是，mcp-connect只解决了MCP Server的在线化，它内置了一个非常粗糙的access_token认证，没有解决多用户认证等问题。MCP Bone是怎么解决的呢？
MCP Bone基于这套方案，将基于mcp-connect的体系部署为后端服务。在自己的应用层，构建了自己的认证体系。简单讲，就是通过系统架构设计，通过层层设计来弥补单一生态的不足。
MCP服务器注册与工具调用体系
在有了后端的MCP Server在线化支持后，就是应用层构建。首当其冲的，就是MCP协议（在我看来）的本质——工具注册和调用。
MCP服务器注册与工具列表拉取
从使用简单的角度讲，我们设计一个底层为技术驱动的功能时，应该尽可能的让参数少，不需要暴露太多可选项给用户。MCP Bone只需要用户填写一个简单的表单，即可完成注册。
基于该表单，它可以生成一个mcpServer的配置JSON：
这与我们在Cursor、Cline等MCP Host中填写的配置信息并无二致。
当用户填写的信息正确，提交之后，就可以在MCP Server列表看到注册好的服务器，并在点击查看后看到该服务器下的所有工具：
以上便是MCP Server的注册和工具的拉取过程。可以看到，其实非常简单，没有任何心智负担。
但是，我们在Cursor等客户端中会发现一个功能，即它们提供了一个MCP Server的列表供你一键安装。数量这么多，软件官方团队不可能把每一个MCP Server的配置都誊抄一遍。你猜它是怎么做的？我想你打死也想不到，当你点击安装的时候，它去抓取这个MCP Server的README，然后通过LLM提取和总结它的配置，这个过程就和你使用Cursor写代码的过程是一样的。😀这也就意味着不管你MCP Server的开发者多懒，或者升级版本多快，都不会影响它安装和更新的准确性。我觉得这种玩法非常极客，是AI时代下产品该有的样子。
有样学样，MCP Bone也提供一键式智能识别的能力，上面的表单虽然已经够简单了，但是还可以更简单，开发者只需要在一个文本框输入一个url，即可完成表单的填充。
工具的调用
由于MCP Bone的目标是降级开发难度，因此，调用MCP Server的工具，被降级为发起一个HTTP请求，传入server_name, tool_name和arguments即可，之后就可以得到运行结果。
后端流程上，MCP Bone在接收到开发者发来的调用工具请求后，将数据格式转化为mcp-connect所需要的格式，并发送给mcp-connect服务，而mcp-connect又会将http请求转化为stdio交互，在具体的MCP Server内部，还可能去上游服务商的接口拉数据。
总之，虽然后端的整个链条很复杂，但是对于MCP Bone的开发者用户而言，不需要理解这么深入的过程，只需要调用http接口，传入3个参数，即可完成MCP Server工具调用。
MCP与大模型交互适配
在进行接下来的内容之前，到目前为止，MCP Bone实现了一个“MCP Server集群”和“调用难度降级”的效果。如果对于新手开发者来说，他不知道MCP协议的具体实施过程，但是想将MCP生态众多MCP Server所提供的功能集成到自己的应用中，MCP Bone正好可以满足他。对于他来说，开发中，并不存在MCP的所有概念，而是只有“调用一个自定义功能的平台API”的概念。他可能会这么想，“这个功能不错，我在MCP Bone上把它注册一下，调个API就能用它的功能了。”
然而，当我们是一个LLM应用或Agent的开发者，有着非常明确的概念的时候，我们就需要更多。
在上一篇文章中，我画了一张时序图，来阐述在一次对话交互中，LLM应用或Agent调MCP工具来回答用户，是怎样的一个流程：
通过这张图，我们可以看到，整个过程非常麻烦，你的LLM应用层，需要做非常复杂的代码架构，才能在MCP生态中汲取少量营养。有没有办法简化这个过程呢？
我们如果现在把我们的角色做一个互换，我们不要再把自己作为MCP的队友，而是站在调用MCP服务的应用开发者的角度来看，我们要在自己的LLM应用中调用工具。其实流程是固定的，无论我们是否接入MCP生态，这个流程都不变，这在openAI 2023年1月发布Function Calling功能时就固定了：
现在MCP的出现，并不影响这张图的调用过程。但是由于MCP协议的复杂性，导致对我们自己LLM应用的改动过大，带来的迭代风险太大了。有没有一种过渡方案，已降低这种风险吗？
工具列表的构造
通过MCP Bone可以做到。MCP Bone做了一层适配，以适应大模型调用工具的需求。让我们思考一下，我们在调用LLM服务时，是如何传参的？没错，就是在参数中传入tools参数，让大模型返回被选中的工具及其实时参数。
对于MCP生态而言，这里的核心点就在于，如何构建这个tools参数。如果要自己接入MCP生态，在完成MCP的基础设施建设后，通过遍历MCP Server，拿到inputSchema来构造tools是可行的，前提是整个MCP在你的LLM应用中跑起来。而如果基于MCP Bone则非常简单，通过一个http请求就可以立即拿到这个tools参数。
此外，部分模型并不支持function calling，例如我们的国产之光deepseek-r1。针对这类模型，我们从Cline中得到启发，通过将tools构建为prompt文本，直接通过prompt的方式与大模型交流。在prompt中，我们强调了大模型的任务是按照特定规则返回选中的工具列表。MCP Bone提供了一个接口，返回构造好的prompt，这个prompt完全仿照Cline的系统提示词编写，开发者通过这个接口拿到prompt之后，可以把它拼接到系统提示词，抑或用户提示词中。这样，即使不支持function calling的大模型，也会遵照提示词，返回特定格式的工具选取结果（文本）。
工具调用的解析
对于支持function calling的大模型，会在选择工具后，返回tool_calls字段来提供给LLM应用调用工具的信息，LLM应用拿到这个信息之后，在自己内部执行对应的逻辑，拿到工具调用的结果。
但是对于不支持function calling的大模型呢？上文提到，通过prompt工程，我们可以让它们根据用户输入的内容进行工具选择，但是它只能返回文本格式，而且由于大模型并不完全遵照提示词格式，所以，我们需要从文本中提取出真正有价值的信息。作为MCP Bone的用户，则可以通过SDK中提供的函数，从文本中解析出与function calling结果一致的tool_calls。
这也就意味着，无论你所使用的LLM是否支持function calling，我们都可以得到相同的结果。这样，我们就达到了在模型与工具交互层面的统一。这个统一，弥补了MCP协议缺失的另一半。
调用流程
有了MCP Bone，我们在开发LLM应用时，就可以以统一的模式完成工具调用。具体流程如下：
通过MCP Bone，一方面屏蔽了MCP生态的复杂性，另一方面又统一了模型调用工具的交互模式。这使得LLM应用的开发可以简化很多。
让工具成为空气，消失不见
“大模型调用工具”，本质上，这个说法是不对的，大模型并没有调用工具，而只是提供了调用工具的参数，真正调用工具的，是LLM上层应用。上层应用在从LLM获得调用工具参数之后，调用工具，然后还要把工具执行结果和原始的用户请求一并发给LLM，才能得到最终回复给用户的completion。
可以看到，在这样的交互中，我们作为开发者，需要在应用中调两次LLM。这其实是非常别扭的。当我们需要一个结果时，作为聪明的大模型，为什么要调两次呢？这种别扭感，不仅在体验上损耗开发者的耐心，而且在实操中也确实非常容易搞错。
既然如此，MCP Bone设计了一种模式，让开发者直接调用MCP Bone的completion接口，就可以直接得到工具执行后的总结结果，也就是将上面的3个步骤，合并为1个步骤。完成这个合并之后，开发者在调用API时，与之前调用大模型的completion接口一摸一样，即一个completion接口的调用，不需要考虑工具调用，工具调用过程由接口自动完成，调用接口的开发直接拿到最终结果，而整个过程只有一次交互。并且，我们可以认为，工具的选择和执行过程，与deepseek-r1等思考模型的thinking过程具有同等地位，因此，我们可以把这个部分的内容，放开给用户看，但是是作为对话中的一个附属信息。
这种模式适合Agent中调用，因为在Agent中，我们提前规划好了任务及工具调用，在执行某次调用时，我们很明确这次调用要使用工具。
而在普通LLM中，我们并不清楚用户的输入，是否需要调用工具才能完成，如果动态的去决定是否需要调用工具，又会损失性能。因此，本模式的调用更适合Agent这种场景，具有特定适用性。
这种设计，是从开发者的调用角度出发，尽可能的简化应用背后的逻辑。只有当这种调用逻辑足够简单时，开发者们才无需因为MCP协议的复杂性而却步。
MCP工具“集装箱”和“呼叫转移中心”
基于MCP Bone有一些不错的场景可以实现。我们在MCP Bone上创建多个实例，每个实例可以只注册关联的MCP Server，从而让一个MCP Bone实例可以完成一个垂直领域的任务。这就像一个个集装箱，可以帮助应用厂商建立集中的分区MCP Server管理模式。
另一个场景则是通过MCP Bone集中管理自己常用的MCP Server，在不同的客户端（如Cursor和Cline）中，使用mcp-bone来共享相同的工具列表，这样，我们可以避免在切换工具工作时，需要重新配置mcpServers。而当我们需要增删工具时，也只需要在MCP Bone平台上处理即可。它就像呼叫转移中心，把分散的MCP Server集中在一个地方管理，又再以一个单一MCP Server向客户端提供使用。
通过MCP Bone，在你的客户端软件中，减少管理MCP Server的麻烦。当然，这仅限于需要远程调用工具的情况，对于local MCP Server而言，本地安装调用执行性能必然好很多。
通过mcp-bone这个包，普通用户也可以无缝接入MCP世界，甚至再配合上MCP Bone提供的MCP Server挑选功能（从内置了API Key的服务中直接使用）还可以省去了去各个平台申请API Key的麻烦。
所有的这些，都是从简化开发流程和使用便捷性的角度出发而设计的。
结语
本文详细介绍了我是如何完成MCP Bone这个项目的。整个项目大概花费了4天时间。通过这个项目，我掌握了在MCP生态上构建应用产品的整个路径，也可以由此类推阿里云、魔搭社区等上线的MCP平台背地里的技术实现。
作为AI领域应用层面的基础设施，MCP虽然还存在诸多不足的地方，但是无疑给整个社区带来了一些重要的启示。虽然我在上一篇文章中批评了MCP生态的乱象问题，但并不否定其作为促进AI应用发展的一个分支方向。在我的其他文章中，你可以了解到我对Agent领域发展的认知，虽然构建通用Agent从现在来看越来越不大可能实现，但是，我会在下一篇文章中阐述“自举式Agent架构”来聊一聊我对Agent开发的一些认识。
如果你对MCP Bone，或者对MCP本身有什么看法或自己的见解，欢迎在下方留言讨论。
2025-04-29 55
