MCP Server 真正有价值的地方，不是多写一个接口，而是把本地文件、命令行脚本、内部服务、数据库查询、业务系统能力整理成 AI 可以安全调用的工具。理解协议只是第一步，能把一个真实能力稳定接到 Claude、Claude Code 或其他 Agent 客户端里，才算进入实战阶段。如果你还没有看过 MCP 的基本概念，可以先读 MCP 协议详解教程；如果你已经想直接写 TypeScript 代码，可以继续参考 MCP Server 开发实战。本文更关注两者之间的落地层：如何从“我有一个本地能力”走到“Agent 能可靠调用这个能力”。先把 MCP Server 看成工具边界，而不是代码项目很多人第一次写 MCP Server，会直接从 SDK 示例开始：创建 server、注册 tool、连接 stdio transport。这样能跑通 demo，但很容易忽略一个更重要的问题：这个工具到底应该暴露什么边界？MCP Server 的核心不是“让模型执行任意代码”，而是把可控能力包装成明确接口。一个好的工具边界通常有几个特征：维度好的 MCP 工具容易出问题的 MCP 工具输入字段明确，类型清楚，有必要约束直接传一段自然语言让工具自己猜输出结构稳定，方便模型继续推理返回大量原始日志或无格式文本能力范围只做一个动作或一类动作什么都能执行，边界模糊失败反馈返回可解释错误，方便下一步修正抛出底层异常，模型不知道怎么处理安全范围限制目录、命令、网络和权限默认开放本机所有资源这也是为什么 MCP 更适合被理解为 Agent 工具层的一部分，而不是普通后端 API 的替代品。它面对的调用者不是人类前端，而是会基于工具描述、参数 schema 和上下文自动决策的模型。在规划 AI Agent 架构时，可以把 MCP Server 放在“工具执行层”。模型负责判断什么时候需要工具，MCP Client 负责发现工具和转发调用，MCP Server 负责执行明确、可控、可审计的动作。这个分工也和 AI 智能体开发指南 中的工具层思路一致。从一个真实场景开始拆工具假设你想让 Claude Code 帮你分析一个本地项目的内容结构。最粗暴的做法是给它一个 shell 工具，让它自己执行各种命令。但这会带来两个问题：权限太大，输出也不稳定。更适合 MCP 的方式，是先把需求拆成几个窄工具：工具输入输出适合解决的问题