MCP正在悄悄改变商业格局！抓住这波红利，你也能躺赚！

模型上下文协议（Model Context Protocol，简称 MCP）是一种日益受到关注的协议，旨在帮助模型客户端与外部服务及工具服务器进行更为广泛的交互。通过 MCP，模型客户端的功能不再仅限于对话或信息检索，而是能够执行实际操作，例如发送电子邮件、部署代码或发布文章等。虽然已有许多文章对 MCP 进行了介绍，但本文将重点讨论在深入使用过程中发现的一些问题，以及这些问题蕴藏的潜在商业机会。

有哪些问题

MCP 作为一个开放标准协议，允许任何模型客户端选择支持这一协议，同时服务器端可以轻松构建多个分发点，从而节省开发者的时间和精力。这种灵活性相比各家模型厂商独立提供的功能调用或工具使用方式，确实便利了许多。然而，在长期使用过程中，仍然存在一些需要解决的问题。

What is the MCP

无谓的复杂性

有时为了形成标准而设立标准，这种现象在新进入者与现存主导者的竞争中比较常见，这种做法虽然可以理解，但实际上引发了一些值得思考的问题。如果希望大语言模型（LLM）能够使用现有的服务，为什么不直接让它调用现有的 API 呢？利用成熟的 RESTful 以及 Swagger/OpenAPI 规范生成所需的 JSON schem)a 似乎会更加简洁（例如使用 agents.json）。专门创建 MCP Server 来包装现有 API 的做法看起来有些多余，这也随之带来了新的安全性和访问权限方面的挑战。

安全性

在创建 MCP Server 时，恶意攻击者可能通过注册与合法服务器相似或相同的名称，以此欺骗用户安装恶意服务器。此外，代码注入攻击可能发生在 MCP Server 的源代码或配置文件中，威胁其安全性。在运行过程中，多个工具可能使用相似的名称，这可能导致用户在选择工具时产生冲突，进而执行错误的操作或泄露敏感信息。同时，若多个工具注册了相同或相似的命令，可能导致执行时的歧义，造成意外的错误操作。此外，当 MCP Server 更新后，某些过时或被撤销的权限可能未及时清除，这使得恶意用户仍可利用这些权限进行恶意操作。

访问权限

企业用户更倾向于自行托管 MCP Server，以便于分离数据层和控制层，从而确保安全性和合规性，并支持不同用户访问该服务器。从最新的规范来看，远程服务器的支持已经有所增强，但仍然存在一些问题。

首先，采用基于 OAuth 2.1 的身份验证机制。其次，之前的 HTTP+SSE 传输方式已被流式 HTTP 传输所取代。此外，系统还支持 JSON-RPC 的批处理功能。然而，即便某个工具通过了身份验证，其使用范围仍需明确界定。目前，MCP 尚未实现细粒度的权限控制，权限管理仍限于会话级别，这意味着工具要么完全开放，要么完全禁用。随着工具数量的增加，管理权限将变得愈加复杂。

持久连接与状态性

最初的设计更偏向于本地运行，特别是通过使用 uv/uvx 来将本地服务集成为独立进程。然而，这种子进程的使用会带来一些安全风险。在 MCP 中，连接是有状态的，支持在连接生命周期内进行多次请求和响应。这种设计使得客户端和服务器之间能够进行持续的交互，并维护上下文信息，从而提升了交互的效率和连贯性。然而，这一模式并不太符合当前流行的无状态 API 架构，例如 AWS Lambda 和 Cloudflare Workers。

工具过多占用上下文

目前，MCP 将所有工具都纳入到模型的上下文中，缺乏有效的优先级和路由机制。这不仅造成了 token 的浪费，还可能导致模型行为的不稳定。例如，当我让 Claude Desktop 从超过 60 种工具中选择 5 种进行调用时，其性能明显下降，且大多数情况下模型并未选择出最合适的工具。因此，需要一种分级路由的方式来逐步、选择性地展示工具选项。目前社区正在探索通过命名空间和拓扑感知的方法进行分层，以改进这一问题。

总结

MCP 仍面临诸多挑战，但如果社区能够有效解决这些问题（Roadmap 上已经提出了相应的方案），其潜力将会巨大。在此之前，我将保持谨慎乐观，并继续关注我感兴趣的 Agent Network 以及在多轮持续对话场景下的工具调用研究。

问题就是机会

模型上下文协议（MCP）的核心依然是模型，其主要目标是争取下一个用户交互的入口，使模型客户端成为主要的交互界面。这样的设计让用户能够通过 API 完成操作，而无需依赖各个垂直 SaaS 软件的图形用户界面（GUI）。在长链条任务中，这种设计与用户利益高度一致，因此 OpenAI 理应支持 MCP，因为这与 Anthropic 的利益是相符的。然而，这种模式可能会遭遇拥有大量用户的产品的抵制，因为现有的守成者并不希望大模型成为新的交互入口。MCP 的阳谋在于“挟持开发者和用户以制衡巨头”：即使某些平台不乐意，标准协议也能帮助实现更为体面的交互方式。

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

Server 网关

作为 MCP 客户端与服务器之间的中介组件，网关主要负责统一管理连接、分配任务与执行安全验证。随着 MCP 的广泛应用，网关逐渐成为系统中关键的中间层，承担统一认证、权限控制、流量调度和工具选择的职责。其功能与传统的 API 网关类似，包括访问控制、请求路由、负载均衡，并通过缓存响应提高效率。在多租户环境中，网关的作用尤为重要，因为不同用户与 agent 可能拥有不同的访问权限。一个标准化的 MCP 网关能够简化客户端与服务器之间的交互，增强系统的安全性、可观测性和可扩展性，同时使 MCP 的部署和管理更为简便。

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

Server 发现

用户在寻找和配置 MCP 服务器时，仍然需要手动操作，包括查找服务地址或脚本，并配置认证信息。为了简化跨不同 MCP 客户端的服务器安装流程，可以考虑构建一个安装工具（如 mcp-get）或创建一个服务器目录导航站，以帮助用户发现和访问可用的 MCP 服务器。不过，根据官方 2025 年上半年的路线图，MCP 包管理（标准化打包格式）、安装工具、沙盒安全和服务器注册等功能已经被列入日程。到那时，按照标准设计的工具将会创造出新的商机。

Server 托管

提供远程 MCP 服务器托管服务的市场正在发展，现有基础设施厂商纷纷进入这一领域。例如，Cloudflare 推出了远程 MCP 服务器部署功能，提供四个核心组件来简化远程服务器的构建过程：首先，workers-oauth-provider 作为 OAuth 2.1 库，简化了用户认证和授权流程，使开发者无需自行实现复杂的流程；其次，McpAgent 类集成在 Cloudflare Agents SDK 中，负责处理远程传输，使得 MCP 服务器能够接收和处理来自 MCP 客户端的消息；接下来，mcp-remote 作为适配器，允许本地 MCP 客户端使用远程 MCP 服务器，便于这些客户端连接和利用远程服务器；最后，AI playground 作为远程 MCP 客户端，提供在线聊天界面，允许用户与远程 MCP 服务器进行交互和测试，同时进行必要的认证检查。

Server 安全

MCP 服务器的安全性可以参考 DevSecOps 的方法，需要引入多种安全工具，以覆盖 MCP 服务器的整个生命周期。在创建阶段，包括服务器注册、安装部署和代码完整性验证，以确保服务器的正确配置和安全性；在运行阶段，MCP 服务器需要根据 AI 应用请求执行工具操作，处理命令，并实现沙盒机制，保障环境安全和稳定地与外部资源交互；在更新阶段，确保 MCP 服务器持续更新以适应需求变化，同时涵盖授权管理、版本控制和旧版本管理，从而防止安全漏洞和权限问题的出现。

工具调用管理

在构建 MCP 客户端时，工具的选择是一个至关重要的问题。面对大量的服务，简单地将所有工具放入上下文中进行自动选择显然是不可行的（我尝试从 60 个工具中选 5 个的时候就遇到了崩溃），也不能完全依赖人工来做判断。那么，每位开发者是否都需要为工具创建独立的检索逻辑呢？是否可以构建一个标准化的“中间层”，以减少重复开发并提高效率？

另一个问题是缺乏统一的工具调用接口和一致的 UI/UX 设计模式。一些工具依赖斜杠命令，而其他工具则使用自然语言指令。通过引入一个标准化的客户端层，可以涵盖工具的发现、排序和调用流程，从而为开发者和终端用户提供更一致和可靠的体验。

在交互过程中，常常需要依次调用多个工具（例如，单轮对话中的多步骤工具调用和多轮对话中的工具分批调用），但当前的 MCP 并未内置工作流管理机制。当期望每个客户端独立实现中断恢复和失败重试等功能时，这种做法既不现实也低效。因此，构建一个统一的工作流管理系统显得尤为必要。