MCP服务器正逐渐从工具封装器转变为功能平台。
MCP服务器正在演变为功能平台：包括工具转换、搜索、命名空间、代理、技能、任务与版本控制，以及何时应当暂缓开发。
来源: Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #7
任何将MCP服务器投入实际应用的人现在都应该熟悉相应的检查清单：明确的工具契约、结构化的输入与输出、合理的错误语义处理、身份认证机制、可观测性功能、清晰区分模型控制的内容与运行时提供的内容（如用户ID、租户信息、角色及权限范围）、执行时的授权控制，以及具备扩展能力的部署模型。下一次变革并非在于新的传输协议或又一个代理框架，也无需因此重写整个技术栈。因为MCP服务器越来越像一个真正的功能型应用平台，而非仅仅是一个附加了少量工具的简单端点。
一旦拥有数十个工具、多个MCP服务器、多个团队、具有不同权限的用户、各类客户端、长时间运行的工作流、可复用的技能、不同版本以及越来越多的上下文信息，这种差异就显得至关重要。此时问题已不再是如何将Python函数作为工具暴露出来，而是更为复杂的议题：
如何在不将所有功能都加载到模型中的情况下，对整个功能体系进行设计、发现、组合、管理、运行、监控、测试和迭代？
这正是MCP的发展方向，本文余下部分将对此进行详细阐述。
最初的MCP服务器与如今的MCP服务器截然不同
早期的MCP示例都被刻意设计得较为简单，一个服务器仅包含少量工具：
MCP server
├── search_documents
├── create_ticket
└── get_customer
客户端列出工具，模型读取架构并选择其中一个，服务器则执行该工具。在规模较小的系统中，这种思维模式依然适用。只要有五种明确的工具、一个后端、一个团队以及一个应用场景，就无需更复杂的结构。
现在将同样的设计应用到真正的企业环境中：
Salesforce MCP 60 capabilities
GitHub MCP 40 capabilities
Jira MCP 35 capabilities
Google Drive MCP 25 capabilities
Knowledge Base MCP 20 capabilities
Internal Platform MCP 70 capabilities
Reporting MCP 15 capabilities
Admin MCP 30 capabilities
那已不再是一个工具服务器，而是一个能力生态系统。如果简单地将所有架构拼接起来并一并传递给模型，就会同时出现三个问题：任务开始前上下文就已丢失，工具选择变得更加困难，而且模型会看到对当前用户和流程而言可能无关、有风险或令人困惑的能力。
这种压力在安全与发现相关的讨论中早已出现，但它还有一个容易被忽视的更广泛后果：工具目录本身也是一种工程产物。你可以对它进行搜索、转换、过滤和命名空间划分。它可以由其他服务器的功能构建而成，还能承载可复用的技能与资源。某些操作可以暂停以向用户提问，耗时较长的任务可以转入后台处理，合同可以版本控制，整个界面也可以像任何生产级 API 一样接受测试。
以下各节内容正是探讨这种演变过程。
FastMCP是这一理念的一种优秀实现方式，而非理念本身
在所有示例中都会出现FastMCP，因为其当前的架构使得这些模式格外清晰可见。提供者负责提供组件，转换器会在客户端看到组件之前对其外观进行重塑，搜索功能可以用一个简洁的发现界面替代庞大的产品目录，代理可以整合其他MCP服务器，技能可以转化为资源，耗时的操作可以转为后台任务，不同版本可以共存。而且，无需直接调用实现函数，只需通过真实的客户端即可对最终的MCP界面进行测试。
这很有用，但并不意味着“每个人都应该采用FastMCP”。这些其实正在变成MCP系统的可复用架构模式。同样的理念可以用Python、TypeScript、Go、C#、Java、Rust或内部平台来实现，也可以借助其他框架、手工编写的代码或托管网关来完成。关键在于要留意抽象层正在向何处发展。协议标准规定了客户端与各种能力之间的交互方式，而服务器架构则决定了能力接口的形态，如今的这种接口形态远比静态的装饰函数列表要智能得多。
1. 工具转型：后端API不应自动变成代理API
这里最实用的想法之一也是最简单的：上游服务提供的工具在技术上可能是正确的，但对大语言模型来说却可能表现糟糕。
想象一下一种能够实现此操作的 Salesforce 内部集成：
salesforce_account_query_v2_internal(
q_string,
include_deleted_flag,
tenant_uuid,
raw_fields,
)
在拥有该签名的服务内部，这样的签名或许没问题。但模型真的需要看到完全相同的契约格式吗？大概不必。面向模型的版本应该这样写会更合适：
find_customer_account(
company_name,
include_archived=False,
)
底层操作保持不变。发生变化的是呈现给模型的接口，这就是工具转换。
FastMCP通过专用的转换层来实现这一功能：重命名工具、重写其描述、重命名参数、修改默认值、隐藏不必要的参数、调整标签和注释，以及将执行过程封装在自定义逻辑中。大致流程如下：
Backend capability
↓
Raw MCP tool
↓
Transformation layer
↓
Agent-facing contract
有多个原因使得这样做很有价值。
模型无需了解基础设施的细节。tenant_uuid、internal_region、api_version或include_deleted_internal_records这类字段属于后端的业务范畴。当模型不应决定某个值时，就应完全将其排除在模型架构之外。这符合运行时上下文规则：可信的值应保留在能力边界之外，绝不能出现在模型生成的参数中。
其次，上游系统使用的任何命名方式都可以不被代理所感知。供应商或旧有服务可能会提供为人类开发者设计的操作接口，而这并不适合需要从80种工具中选择的大型语言模型。网关可以提供更规范的术语体系，而无需要求上游团队重新命名他们的API。
第三，即便后端发生变化，代理合约仍可保持稳定。这一点的重要性远超表面所见。如果后端升级到新的 Salesforce API 版本、重命名内部参数或将某个操作拆分为多个操作，模型所使用的工具完全无需改变。转换层起到了在能力使用者与实现者之间的隔离保护作用。这其实就是普通的软件架构，只不过现在被应用在了面向代理的接口上。
后端的合约是为拥有该能力的系统服务的。而 MCP 层所提供的内容则应服务于调用它的代理。
2. 工具搜索：目录变为可搜索的上下文
一旦生态系统规模扩大，这一点就变得极为重要。典型的初始实现方式如下：
connect to server
↓
list all tools
↓
put every schema into the model context
↓
ask model to choose
当列表较短时这种方法可行，但随着工具的增加会越来越浪费资源。更成熟的处理方式如下：
small discovery interface
↓
search relevant capabilities
↓
load only matching schemas
↓
execute
FastMCP的工具搜索功能将这一理念落地。服务器不会返回完整的工具目录，而是提供诸如search_tools和call_tool之类的合成式检索工具。目前内置的检索策略为正则表达式匹配和BM25排序。BM25属于词汇级排序方式，而非语义向量搜索，但该架构并不依赖BM25。在您自己的平台上，排序机制可以基于关键词、嵌入向量、带有重排功能的混合检索器、元数据过滤器、使用统计信息、基于规则的评分系统，或是专为特定领域需求构建的索引来实现。
关键在于工具变成了可检索的对象。模型无需将300个工具定义全部塞入上下文中，而是可以调用search_tools("find customer opportunities and open deals")，从而得到三到四个结果，例如salesforce_find_account、salesforce_list_opportunities和salesforce_get_pipeline_summary。只有这些方案才会进入下一步。
这不仅仅是节省了令牌，还提升了模型需要做出的决策质量。“从300个方案中选择一个功能”与“搜索与当前任务相关的功能，再从四个相关结果中挑选”是截然不同的推理问题。
渐进式发现也是代码执行方法的基础，但即便从不运行模型生成的代码，工具搜索依然有用，而且它适用于普通的工具调用场景。有一项安全规则需要从授权工作中沿用过来：应搜索用户被允许发现的目录，而非平台的完整目录。如果搜索结果中出现了被禁止使用的管理工具的名称和结构，那么即便后续拒绝执行，能力细节也已经泄露。因此，真正的处理流程需要在搜索之前加入授权过滤机制。
可以将其视为应用于能力层面的上下文工程。
3. 命名空间：组合使用会先引发身份识别问题，而非扩展性问题
当开始整合MCP服务器时，立刻会出现一个极其棘手的问题：每个服务器都使用诸如search、get_user、list_files或create_note这类通用名称。如果将Salesforce服务器、Google Drive服务器、知识库服务器以及GitHub服务器合并起来，其中三个服务器都提供search功能，问题就会越积越多——模型调用的是哪个search功能？日志中显示的是哪一个？策略规则覆盖的是哪一个？当架构指纹发生变化时，又是哪一个会随之改变？
正因如此，当MCP不再是一个独立的服务器时，命名空间就显得至关重要。FastMCP提供了命名空间转换功能，可在组件组合时为其添加前缀，这样search就会变成salesforce_search、gdrive_search、knowledge_base_search和github_search。资源URI的路径也可以通过命名空间来区分。
避免冲突是显而易见的好处。而更微妙的好处在于溯源能力：前缀能够记录某个功能的来源，而这些来源信息又会用于制定策略规则、生成审计日志、实现追踪、设置速率限制、明确所有权、处理迁移、辅助调试，以及为模型提供相关描述。
不过也不要做得太过头。像 enterprise_internal_platform_team_alpha_salesforce_v2_search_customer 这样的名称仅仅因为全局唯一就更好了，这其实并不正确。命名空间用于标识身份，而转换仍然可以让最终接口对模型更加友好。这是两个相关但不同的问题：
Source identity
→ Namespace
Agent usability
→ Transformation
4. 可见性：上下文工程并不仅限于文本
提到上下文工程，大多数人会想到系统提示、检索到的文档、内存、聊天记录，或许还有工具描述。然而，模型能够看到的任何功能也都属于其上下文的一部分。
以客户调研工作流为例。即便用户拥有其中某些工具的使用权限，模型该如何使用rotate_api_key、terminate_employee、rebuild_search_index、publish_release和admin_delete_tenant这类工具呢？这些工具都无法帮助完成任务。更清晰的界面应该是：
Customer Research
├── salesforce_find_account
├── salesforce_list_opportunities
├── knowledge_search
├── web_research
└── generate_customer_report
运行时可见性功能可解决此问题。FastMCP的组件可见性允许你通过名称、键或标签来开启或关闭组件；被禁用的组件会从列表中消失，且无法通过常规服务器接口被调用。针对工作流的不同功能集、特性开关、环境差异、测试版工具、维护时段、租户专属产品、代理配置，或是模型可执行的操作范围更有限的情况，均采用相同的机制：
workflow = customer_research
include:
salesforce.*
knowledge_base.*
reports.*
exclude:
admin.*
deployment.*
hr.*
与安全工作的区别依然存在：可见性并不能替代授权。可见性用于判断某项功能是否属于当前可见范围，而授权则用于判断经过身份验证的主体是否真的被允许使用它。一个优秀的企业MCP平台通常会同时考虑这两点，先筛选可见范围，再实施授权控制。
5. MCP代理：作为通往其他服务器的网关
此时设计才真正变得有趣起来。服务器无需拥有它所提供的所有功能；它可以充当其他MCP服务器的入口。FastMCP的代理提供程序会从远程MCP服务器获取工具、资源及提示信息，然后从当前服务器重新发布它们。
因此就会出现如下简单的链式结构：
AI client
↓
Salesforce MCP
它可以发展成为一个面向多台上游服务器的网关，而该网关无需复制这些服务器上的任何业务逻辑。它通过代理功能并在其上添加平台层，实现身份认证、策略管理、命名规则、可见性控制以及可观测性等功能。
这代表了系统设计方式的巨大变革：MCP服务器不再彼此孤立，而是可以组成一个网络。一个团队可以负责Salesforce集成，另一个团队负责项目知识管理，还有一个团队负责基础设施运维，而企业网关则能将所有这些功能整合为一个统一的产品界面，无需强制各团队使用相同的代码库或发布周期。
代理在许多实际场景中也发挥着重要作用：它们能够连接不同的传输方式，在不断变化的上游服务器前提供一个稳定的访问端点，集中处理身份验证，提升可观测性，实施统一策略，规范名称，并将内部拓扑结构与客户端隔离开来。
但这并不意味着每家公司都需要一个庞大的中央网关。你可以根据不同领域划分多个网关，比如工程部、销售部、研发部以及平台运维部。MCP提供了协议边界，使得这些网关能够被清晰地组合在一起。
一旦MCP服务器能够互相调用并重新处理数据，设计的自然单元就不再是单个服务器，而是一张由受控能力构成的图谱。
6. 技能作为MCP资源：服务器不仅可以分发操作指令，还可以分享专业知识
工具用于说明系统能做什么，资源则用于说明客户端可以获取哪些信息，而技能则引出了第三个问题：智能体应如何执行特定类型的任务？
通常，技能存储在某个目录中，其中包含指令以及示例、架构、脚本、检查清单、参考资料或领域指南等辅助材料。传统上，这些目录位于客户端的环境中，比如 ~/.claude/skills/、~/.cursor/skills/ 或 ~/.gemini/skills/ 这样的路径。而 FastMCP 的技能提供方则将其作为 MCP 资源发布，因此技能的地址为 skill://customer-research/... 的形式，其中包含了主要的 SKILL.md 文件、清单文件、示例文件以及 JSON 架构。
这比看上去更重要，因为服务器现在能够同时传递流程性知识与可执行功能。想象一个内部客户调研平台，其MCP界面提供了诸如search_salesforce、search_knowledge_base和generate_report之类的工具，同时还包含相关技能，这些技能涵盖了团队如何界定合格商机、调研方法、预期报告格式、证据要求以及优秀报告的范例。
该工具会告知智能体它能执行哪些操作。技能则规定了您的组织对工作完成方式的期望。这种分离结构很有优势：您无需将所有操作流程都嵌入到一个庞大的系统提示中，也不必手动将相同的技能复制到每个AI客户端中。能够理解MCP资源的客户端可以通过相同的协议接口发现并获取这些技能，而仅支持工具的客户端则可以通过将资源封装在工具调用中的适配层来使用它们。
MCP服务器可以将功能、上下文及操作知识整合为一个可重复使用的功能模块。
7. 提问机制：让功能向用户发起提问
最简单的工具交互是单向的：模型调用工具，工具返回结果。实际的工作流程则更为复杂。比如用户要求为分析项目创建一个新的云环境，工具可能会找到三个合适的区域和两种部署配置。又或者，该环境每月的维护成本约为420美元。还可能出现两个名称极为相似的Salesforce账户。此时正确的下一步并非盲目猜测，而应是让系统主动询问。
这正是MCP引导机制的思路。FastMCP提供了便捷的API，可用于向用户请求结构化输入，但这种模式属于MCP本身，而非某个特定的Python框架。
2026-07-28版本的MCP规范对这种交互机制进行了重构，采用多往返请求（MRTR）模式，使其适配新的无状态协议模型，而不再依赖双向保持开启的会话。变化体现在数据传输的机制上。该功能本身依然存在：服务器操作仍可在工作流进行到一半时暂停以等待用户输入。其典型应用包括解析含义不明的实体、补充缺失的参数、确认成本较高的操作、在内容发布前进行审核、选择目标环境，以及逐步收集结构化信息。
这里有一个安全注意事项：询问用户并不等同于获得授权。当删除操作需要审批时，后端本身必须存储并维护该审批状态。仅用自然语言发出“您确定吗？”这样的友好提示并不足以解决问题。对于敏感操作，必须由真人介入才能真正实现状态变更。
8. 日志记录：对客户端有用，但生产环境中的可观测性需求更为深入
日志记录包含两个不同的概念。其一是为客户端提供操作执行信息，例如“正在搜索 Salesforce……找到18个匹配的销售机会……正在生成报告……报告已创建”。其二则是生产环境中的可观测性需求，包括追踪标识、请求标识、主体标识和租户标识，以及工具名称、服务提供商、延迟时间、重试次数、策略判定结果、任务编号和错误代码等。应将这两者视为不同的工作内容来处理。
FastMCP仍然支持客户端日志记录功能，即服务器会将调试、信息、警告或错误消息发送回支持这些功能的MCP客户端。这在开发过程中很有帮助，也能让客户端了解某个功能的运行情况。但2026年该协议将迎来一项重要变更：在MCP 2026-07-28版本中，协议自身的日志记录功能已被废弃，不再用于新实现。因此，新的生产环境可观测性设计不应依赖MCP的日志消息，而应采用常规的应用程序可观测性方案，比如结构化日志、OpenTelemetry追踪、指标系统，以及Datadog、Grafana和Tempo、CloudWatch、ELK等您的组织已使用的工具。
一种处理方式是：状态消息能让用户或主机随时了解正在发生的情况，而服务器端的遥测功能则有助于工程、安全及运维团队理解系统状况。在企业级部署中，后者是必不可少的。一个用户请求可能会从AI主机经过MCP网关，再传送到代理服务器，随后接入SaaS API，最终到达后台工作进程，而一条完整的追踪记录应当能够说明整个流程。MCP的代理与组合功能越便捷，这种分布式视角就越重要。
9. 后台任务：功能可具备执行生命周期
传统的工具调用流程为请求、执行、返回结果，且假定所有操作都能在单个请求内完成。但许多重要的企业级功能并不符合这一要求：长度达60页的客户报告、20,000份文档的索引构建、大型数据存储库的分析、Salesforce业务机会的完整导出、包含相关附件的演示文稿制作、合规性扫描以及大量记录的处理。这类任务可能需要数分钟才能完成，有时需要重试，可能在客户端断开连接后仍需继续运行，还需能够报告处理进度，而且往往要在与MCP端点不同的后台工作线程上执行。
MCP Tasks扩展为长时间运行的任务提供了基于协议的完整生命周期管理。FastMCP的后台任务功能便很好地体现了这一点：某个组件被标记为可执行任务后，客户端会获得一个任务处理标识，随后任务会在任务系统的支持下由后台工作线程处理，而不会让原有的调用保持开启状态。
这与编写 asyncio.create_task(...) 不同。Python 并发模型将任务处理保留在进程内部，而协议级的 Task 则在服务器与客户端之间为长时间运行的任务建立契约，因此该任务具有客户端能够理解的生命周期。另一个表明 MCP 服务器正在演变为完整应用接口而非单纯 RPC 适配层的迹象是：它的职责并不仅限于调用函数并返回 JSON，它可能还需要启动任务、维护状态、展示进度、处理取消请求、从故障中恢复，然后在稍后时间返回结果。
10. 版本控制：当智能体依赖你的工具时，架构即 API
每一个成功的内部平台都会遇到这样的情况：有人修改了架构，从而破坏了某个此前无人知晓的调用方。MCP 也并非能免疫这种情况。
假设某项功能的版本1为calculate_risk(project_id)，而版本2则变为calculate_risk(project_id, methodology="v2", include_history=True)。如果一次性将新契约推送给所有代理和客户端，那就相当于发布了会破坏现有功能的API变更。
FastMCP的组件版本控制机制允许同一个工具、资源或提示语的多种实现形式共用同一个逻辑标识符。默认情况下会提供最高版本，而版本过滤器则可为特定的客户端或迁移窗口提供独立的接口版本。
整体架构比具体的 API 更为重要。一旦 MCP 成为共享基础设施，其功能演进就应该遵循与任何公共服务合约相同的思路。哪些变更会引发问题？还有哪些客户端仍在使用 v1 版本？v1 和 v2 能否并行运行？迁移窗口应持续多久？哪个版本已获得正式使用批准？谁可以访问哪个版本？旧版本应在何时停止使用？一个实用的企业注册系统或许可以记录工具名称、提供方、版本、架构指纹、负责人、风险等级、批准时间和批准人以及废弃时间等信息。
对于仅有五个工具的服务器来说，这可能显得有些繁琐；但对于服务于20个团队的平台而言则并非如此。
一旦有其他系统开始依赖你的 MCP 架构，无论它是否有名称，都算是一种 API。
11. 测试：需检查 MCP 的整体功能，而不仅仅是 Python 函数
测试在这里或许是最不引人注目的环节，却很可能是最重要的。试想一下，如果这个函数能够完美运行会怎样：
async def find_customer(company_name: str):
...
即便如此，MCP 服务器仍可能出故障，问题可能出在该功能的各个环节：生成的架构不正确、描述具有误导性、转换过程隐藏了错误的参数、命名空间悄悄更改了工具名称、可见性设置暴露了管理员权限、授权过滤针对了错误的用户、代理未传递凭证、搜索层无法定位该工具、版本过滤器本应提供 v2 却提供了 v1、输出内容与结构不匹配，或是后台任务始终无法进入最终状态。
正因如此，测试实际的 MCP 接口才是更好的做法。FastMCP 的测试指南会在进程内让真实客户端与服务器进行交互，从而无需部署独立服务即可测试协议行为。这样就不只是测试实现部分而已：
result = await find_customer("Acme")
assert result
同时测试 MCP 消费端实际看到的内容：
async with Client(mcp) as client:
tools = await client.list_tools()
assert "salesforce_find_customer" in {
tool.name for tool in tools
}
result = await client.call_tool(
"salesforce_find_customer",
{"company_name": "Acme"},
)
对于一个功能能力平台，至少有四层需要经过测试。
契约测试会检查工具的名称、描述、输入与输出架构、注释以及版本是否符合预期。
发现测试会验证特定用户和工作流能够看到哪些工具、哪些工具会被隐藏，搜索功能是否能找到正确的能力，以及是否会意外显示被禁止的工具。
执行测试会检查调用是否成功，错误信息是否格式正确，重试操作是否安全，代理是否能正确传递身份信息，以及在执行时是否还会再次进行授权验证。
生命周期测试会检查后台任务是否能够正常完成或失败，是否可以取消这些任务，版本迁移后旧客户端是否仍能正常使用，以及上游MCP服务器宕机时会发生什么情况。
以上这些都不是在测试框架，而是在测试你的产品契约。一旦MCP成为多个客户端和代理的能力层，那么这份契约就应当像对待REST、gRPC或事件驱动接口那样受到严格规范。
将各部分整合起来，服务器的模样就会大不相同
把所有这些理念结合起来，最终形成的系统能够处理发现、路由、接口适配、上下文控制、策略管理、交互式工作流、异步执行、可复用的操作知识、兼容性以及完整的工程生命周期。它早已不再只是带有一些工具的服务器，而是一个产品界面。更妙的是，这一切都不要求模型供应商掌握业务逻辑，因为同一个平台可以部署在组织选择的任何兼容MCP的服务器上。这才是具有战略意义的部分。
许多最佳的优化工作在模型看到任何内容之前就已经完成
关于人工智能性能的诸多讨论都集中在模型本身：选择哪种模型、参数数量多少、上下文窗口大小如何、推理能力怎样。这些因素固然重要，但在实际应用中，围绕模型的架构设计能够大幅减少不必要的处理工作。
假设某个平台拥有300种工具。简单的实现方式会将这300种架构全部放入大语言模型的上下文中，期望模型能做出正确选择。而经过精心设计的实现则会分阶段进行筛选：策略层面将300种工具缩减到85种允许使用的；工作流可视化功能再从中筛选出24种相关的；搜索功能最终锁定4个候选选项，只有这4种架构会被加载，供模型做出最终选择。
模型并没有变得更聪明，系统却做到了。这正是这些模式在实际应用中如此重要的重要原因。上下文范围缩小，选择精度提高，无关操作减少，授权规则更加清晰，后端接口不会影响模型，独立团队可以协同工作而无需合并代码，所有这些都在要求大语言模型思考下一步行动之前就已经实现。
优秀的智能体架构不仅致力于提升模型的推理能力，还决定了模型需要推理的内容。
从单个MCP服务器到服务器网络
对于企业系统而言，这才是发展变得真正有趣的地方。最初的架构如下所示：
AI client
↓
MCP server
↓
API
下一个架构单元更像是一个位于中间的网关，其背后是域名服务器和工作节点。每台MCP服务器各司其职，每个团队负责自己的域名领域，各项服务也按各自的计划交付。该网关会为每位用户构建合适的接口，模型仅获取所需信息，漫长的工作流程会被转化为任务，而技能则负责向智能体说明公司期望的工作流程执行方式，所有这些功能都能通过MCP接口被调用。
这与传统的函数封装集合相比，显然更接近分布式应用平台，正因如此，将MCP服务器称为“仅用于LLM的工具”越来越无法体现它们正在发展的真正价值。
在出现平台相关问题之前不要急于构建平台
其中的危险显而易见。读完这些内容后，你可能会认为一个具备五种功能的内部服务器需要三个网关、一个功能注册表、针对工具架构的嵌入式搜索功能、几个命名空间、运行时版本协商机制、用于任务处理的分布式队列、一个技能市场，以及十几种叠加的转换功能。
请不要这样想。
真的需要一个包含六种稳定功能且所有用户都能看到的服务器吗？那就直接提供这六种功能即可。如果后端架构已经很清晰，就不必仅仅因为某个框架支持某种转换功能就额外添加它。单个服务器就无需代理拓扑结构。如果某个操作两秒就能完成，那很可能就不需要使用任务处理机制。如果已经没人使用v1版本了，也就没理由让两个版本永远共存下去。
架构应当是为了解决问题而产生的，而非相反。目标并非在代码库中尽可能多地加入框架功能，而是当问题出现时，MCP无需再迫使你围绕该问题构建完全定制的AI平台。如今，该生态系统已经为任何成熟应用平台所面临的同类问题提供了可复用的构建模块，这便是进步。
框架可以更换；架构才是关键
FastMCP将众多相关理念汇集于一处，值得称赞。其文档详细介绍了提供者、转换功能、搜索机制、命名空间、可见性设置、代理功能、技能系统、信息获取方式、任务处理、版本控制以及测试等内容，有助于人们清晰理解MCP服务器各组成部分之间的关联。其中一些设计模式已被实际应用，因为它们能够解决现实问题：缩小工具上下文范围、将面向模型的接口与后端接口分离、限制暴露的功能范围、整合不同组件，并让最终的系统更易于运行。
尽管如此，各团队应借鉴这一理念而非库的API。先思考：我们真的需要按需的工具发现功能吗？需要面向模型的转换层吗？需要能力网关吗？需要针对工作流的可视化功能吗？需要通过MCP资源分发技能吗？需要为长时间运行的操作提供稳定的生命周期管理吗？需要版本化的能力契约吗？我们测试的真的是客户端实际看到的内容吗？然后，用适合您组织的技术栈来实现这些解决方案。
协议确保了互操作性，框架带来了便利，而架构依然由您掌控。
有哪些变化
MCP最重大的变化并非功能列表的扩展，而是对MCP服务器所需具备的能力范围的不断拓展。最初的情况很简单：发布一个工具，模型调用它，然后返回结果。而如今正在形成的模型则需要从多个系统中获取功能，标准化这些功能的接口规范，为不同功能分配命名空间，筛选出相关内容，授权允许的操作，按需在大型目录中查找信息，提供可重复使用的技能与上下文，在需要用户做出选择时向用户提问，将耗时的操作转化为高效的执行流程，全程监控操作流程，对接口规范进行版本控制，并将其作为真正的产品进行测试。
那完全是另一类工作。MCP刻意保持为协议而非应用框架，但其周边生态正让MCP服务器成为真正的应用边界，在这里可以像在成熟的后端系统中那样构建路由、治理、生命周期管理、兼容性及组合层。
一个构建良好的MCP服务器已不再仅仅是为大型语言模型增添功能的方式。它能够成为可复用的能力产品，为智能体、模型、团队以及客户端应用提供服务。单个服务器可以保持小巧，而由多个服务器构成的网络则可发展成企业级平台。模型依然保持灵活性，能力层仍受管控，而且无需重新构建底层业务能力即可更换顶层的客户端。
相关阅读
- MCP 2026-07-28版本：无状态设计如何改变远程服务器架构 —— MCP在2026-07-28版本中如何取消会话与握手机制，新增MRTR、任务及缓存提示功能，以及这些变化对系统迁移的影响。
- 云浏览器：适用于任何AI代理的安全远程浏览器平台 —— 一种模型中立的远程浏览器服务参考设计，涵盖网关、工作进程、WebRTC实时视图、审批功能、SSRF防护机制、回放功能以及所有配置选项。