MCP的应用场景，其实是一个巨大的赚钱机会

模型上下文协议(Model Context Protocol, 简称 MCP)是一种正在迅速普及的协议，它允许模型客户端与外部服务和工具服务器进行交互，让模型客户端不再局限于对话和信息检索，而是能够采取实际行动，比如发送邮件、部署代码、或发布文章等，我在周刊的 30、35、43、44、45 期[1]都曾介绍过。 关于 MCP 介绍的文章已经很多了，本篇不再赘述，这里我想重点谈谈深度使用下来发现的一些问题，以及这些问题带来的潜在掘金机会。

有哪些问题

MCP 作为一个开放标准协议，任意的模型客户端都可以选择去支持，Sever 端也可以一次构建多处分发，节省开发者的精力，比起模型厂商各自提供的 function calling 或 tool use 确实方便多了，我从去年刚发布就在关注使用，但长期使用下来仍然存在一些问题。

有点为了标准而标准（这也是新进者应对现存守成者的常见策略，可以理解），如果想让 LLM 使用现有服务，为什么不让 LLM 直接调用它的 API 呢，利用成熟的 RESTful 和 Swagger/OpenAPI 规范生成工具所需的JSON schema不是更简洁（ 比如使用 agents.json[2]），专门新建 MCP Server 包装现有的 API 显得多此一举，因此也延伸出新的安全性和访问权限的问题。

安全性

创建时通过注册与合法 MCP Server 相似或相同的名称，欺骗用户安装恶意 Server；代码注入攻击发生在 MCP Server 的源代码或配置文件中。

运行时多个工具可能使用相同或相似的名称，导致在选择工具时发生冲突，进而执行错误的操作或泄露敏感数据，多个工具注册了相同或类似的命令，导致执行时出现歧义，出现错误操作。

在 MCP Server更新后，过时或撤销的权限未被及时清除，可以继续利用这些过时权限执行恶意操作，关于这部分的讨论更多细节可以查看 论文《Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions》[3]。

访问权限

企业用户更倾向于自行托管 MCP Server，并希望分离数据层和控制层确保安全性和合规性，以支持不同用户访问 MCP Server，从最新的规范[4]来看，对远程 Server 已经做了更多的支持，但还存在问题。

基于 OAuth 2.1 的身份验证机制 将之前的 HTTP+SSE 传输方式替换为流式 HTTP 传输 支持 JSON-RPC 批处理

即使某工具通过了身份验证，还需明确其使用范围，由于 MCP 尚未内置细粒度权限控制，当前仅局限于会话级别，这意味着工具要么完全开放，要么完全禁用，随着工具数量增加，权限管理将变得日益复杂。

持久连接与状态性

最初设计更偏向本地运行（uv/uvx 的使用），让本地服务作为独立进程进行集成，但子进程会带来安全隐患。在 MCP 中，连接是有状态的，支持在连接的生命周期内进行多次请求和响应。这种设计使得客户端和服务器之间可以进行持续的交互，维护上下文信息，从而提高交互的效率和连贯性，不过这与当前流行的无状态 API 架构（如 AWS Lambda, Cloudflare Workers）不太契合。

工具过多占用上下文

MCP 当前是将所有工具都塞入模型上下文，缺乏优先级或路由机制，这不仅浪费 token，还可能导致模型行为不稳定，当我让 Claude Desktop 从超过 60 种的工具列表中的选择 5 种工具调用时，性能明显下降，大多数时候它不会选择最适合的工具，需要一种分级路由（逐步、选择性暴露 tool 选项）的方式（社区目前在探索通过命名空间和拓扑感知方式进行分层）。

总结

MCP 目前存在的问题还有很多，MCP 社区如果能把上面的问题都能解决好（Roadmap 上都提出了针对性方案[5]），那无疑潜力巨大，在此之前我保持谨慎乐观，继续投入我感兴趣的 Agent Network 和多轮持续对话场景下工具调用的研究。

问题就是机会

模型上下文协议（MCP）的核心仍然是模型，其主要目标是抢占下一个用户交互入口，使模型客户端成为主要的交互界面。通过这种方式，用户可以通过 API 完成操作，而无需依赖各个垂直 SaaS 软件的图形用户界面（GUI）。

在长链条任务中，这种设计与用户利益一致，因此，OpenAI 没有理由不支持 MCP，因为在这一点上，它与 Anthropic 的利益是一致的。不过这种模式可能会受到拥有海量用户的平台类产品的抵制，因为现有的守成者并不希望大模型成为新的入口，MCP 的阳谋在于“挟开发者和用户以令巨头”：即使某些平台不愿意，标准协议也能帮助它们实现更体面的交互方式 （比如 mcp-browser-use[6]），这种模式对开发者和新创产品具有吸引力。

接下来，除了完善协议本身，模型厂商还需要围绕消费级需求提供更优化的存储、Server 商店等配套设施，由于这些领域单靠模型厂商自身难以完全覆盖，这便为现有基础设施厂商和开发者创造了机会。

Server 网关

作为 MCP Client 与 Server 之间的中介组件，其主要职责包括统一管理连接、分配任务以及执行安全验证。

随着 MCP 的广泛应用，网关逐渐成为系统中的关键中间层，负责统一认证、权限控制、流量调度和工具选择。其功能类似于传统的 API 网关，具体包括访问控制、请求路由、负载均衡，并通过缓存响应提升效率。

在多租户环境中，网关的作用尤为重要，因为不同用户和 Agent 可能具有不同的访问权限，一个标准化的 MCP 网关能够简化 Client 与 Server 之间的交互，从而增强系统的安全性、可观测性和可扩展性，同时让 MCP 的部署和管理更加便捷。

反应迅速的厂商已经提供类似的能力了，比如 Zapier 推出 MCP 全流程方案[7]，通过一个动态的 MCP 端点将 AI 助手与 Zapier 的广泛集成网络连接起来，实现了对超过 8000 个应用的直接访问。它允许 AI 执行真实动作，如发送 Slack 消息或管理 Google Calendar 事件，Zapier 让开发者能够专注于编码，同时由 Zapier 管理身份验证、API 限制和安全性，国内的腾讯轻联、集简云等 iPaaS 平台也都可以快速实现类似改造。

用户要找到并配置 MCP 服务器仍是一个手动过程，需要自行查找服务地址或脚本，配置认证信息，可以构建安装工具（比如 mcp-get），简化跨不同 MCP 客户端的 Server 安装流程，或者构建一个 Server 目录导航站，用于发现和访问可用的 MCP 服务器。

不过根据 官方 2025 上半年的 Roadmap[8]，在分发和发现方面，MCP 包管理（MCP Server 的标准化打包格式）、安装工具、沙盒安全和服务器注册表已经在日程上了，到时候按照标准做体验更好的工具就是机会。

Server 托管

提供远程 MCP Server 托管的服务，现有基础设施厂商已经在进入，比如Cloudflare 推出远程 MCP Server 部署功能[9]，提供四个核心组件来简化远程 MCP Server 的构建过程：

• workers-oauth-provider作为一个 OAuth 2.1 库，简化了用户认证和授权流程，使得开发者无需自行实现复杂的 OAuth 认证；

• McpAgent 类集成在 Cloudflare Agents SDK 中，负责处理远程传输，使得 MCP Server 能够接收和处理来自 MCP Client 的消息；

• mcp-remote是一个适配器，它允许本地 MCP Client 使用远程 MCP Server，让这些客户端能够连接和使用远程服务器；

• AI playground作为一个远程 MCP Client，提供了一个在线聊天界面，允许用户连接到远程 MCP Server，并进行必要的认证检查，从而使得用户可以直接在网页上与远程 MCP Server 交互和测试。

MCP Server 安全可以参考 DevSecOps，需要一大堆安全工具，围绕 MCP Server 的生命周期，创建阶段（包括 Server 注册、安装部署和代码完整性验证，确保 Server 正确配置并安全准备好处理请求）、运行阶段（MCP Server 根据 AI 应用请求执行工具操作，处理命令，执行沙箱机制以保证环境安全，并稳定地与外部资源交互）、更新阶段（确保 MCP Server 持续更新并适应需求变化，包含授权管理、版本控制和旧版本管理，防止安全漏洞和权限问题）。

在构建 MCP 客户端时，工具选择是一个关键问题，面对海量服务，工具显然不能全丢进上下文自动选择（我遇到 60 选 5 已经奔溃了），也不能依赖人工决策，难道每位开发者都需要为工具实现一套独立的检索逻辑？是否存在一个可标准化的“中间层”，以减少重复开发并提升效率？其其次缺少工具调用接口和一致的 UI/UX 设计模式，一些工具依赖 slash commands，而另一些则采用自然语言指令。通过引入一个标准化的客户端层级，可以覆盖工具的发现、排序和调用过程，从而为开发者和终端用户提供更一致、更可靠的体验。

交互需要依次调用多个工具（单轮对话的多步骤工具调用 & 多轮对话的工具分批调用），但当前 MCP 尚未提供内建的工作流管理机制，期望每个客户端独立实现中断恢复、失败重试等功能既不现实也低效。因此，构建一个统一的工作流管理系统显得尤为重要。

写在结尾

如果对 MCP 的使用和理解还不清楚，可以后台回复「MCP」，手把手教你借助 MCP 构建 Anthropic 官方博客Building effective agents[10]定义的 6 种 Agent 模式，可以作为学习 MCP 的绝佳模板，毕竟 MCP 就是 Anthropic 自己发起的。

如果觉得内容不错，欢迎点个关注，分享和在看～

参考资料

周刊的 30、35、43、44、45 期: https://liduos.com/the-memeber-newsletter-30.html

agents.json: https://github.com/wild-card-ai/agents-json

论文《Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions》: https://arxiv.org/pdf/2503.23278

最新的规范: https://spec.modelcontextprotocol.io/specification/2025-03-26/

[5]

Roadmap 上都提出了针对性方案: https://modelcontextprotocol.io/development/roadmap#roadmap

[6]

mcp-browser-use: https://github.com/Saik0s/mcp-browser-use

[7]

Zapier 推出 MCP 全流程方案: https://zapier.com/mcp

[8]

官方 2025 上半年的 Roadmap: https://modelcontextprotocol.io/development/roadmap#roadmap

[9]

Cloudflare 推出远程 MCP Server 部署功能: https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/

[10]

Building effective agents: https://www.anthropic.com/engineering/building-effective-agents