一个函数就能变成一个 AI 工具:手把手搭你的第一个 MCP Server

从一个函数说起

在 MCP 的世界里，一个工具（Tool）本质上就是一个普通函数，只要它具备三样东西：名称（叫什么）、描述（干什么用），还有参数定义（需要哪些输入）。有了这三样，模型就能读懂它、调用它。

换句话说，会写函数的人，就会写 MCP 工具。

从零搭一个“查天气”服务器

搭一个 MCP 服务器，大致四步。

第一步，选技术栈。 MCP 对语言很友好，TypeScript、Python、Java、Kotlin、C# 都有官方或社区的 SDK，开发框架也现成，不用自己从协议层写起。用 TypeScript 的有 MCP-Framework，声明式定义一个工具，结构清晰；用 Java 的有 Spring AI MCP，加个注解就能把普通方法变成 AI 工具；用 Python 的有 FastMCP，一个装饰器搞定。

第二步，写核心逻辑。 拿“查天气”来说，用 FastMCP 大概是这样：

第三步，选传输方式。 本地开发调试，走 stdio（标准输入输出），服务器作为一个子进程运行，简单直接；要给远程调用，就走 SSE（基于 HTTP 长连接），把服务器暴露成一个标准的 HTTP 服务，这也是生产环境的推荐做法。

第四步，调测部署。 写完后，用 MCP Inspector 这类工具，或者接进 Claude Desktop、VS Code 这些支持 MCP 的宿主，验证工具描述清不清晰、参数对不对、返回符不符合预期，确认没问题再部署。

已经有现成接口？零代码改造

很多团队手里已经有大量 OpenAPI 接口，逐个重写业务逻辑不现实。更聪明的做法，是加一层“适配层”，把现成的 OpenAPI 自动转成 MCP 服务。这个转换大致三步：

• 解析
  读取 OpenAPI 规范文档，自动提取路径、请求方法、参数、响应格式和认证方式这些元数据；
• 映射
  按 MCP 规范重新描述。执行类的操作（查天气、操作网页）映射成工具 Tool，返回的、可复用或频繁读取的数据映射成资源 Resource；
• 转换
  搭一个中间层，把 MCP 的 tool/call 请求翻译成对原有 OpenAPI 的 HTTP 调用，再把 API 的响应包成 MCP 的标准结果格式返回。

手动做这些是体力活，所以有了自动化工具。比如 openapi-to-mcp 这类工具，输入一个 OpenAPI 的 JSON，就得到一个标准的 MCP 配置，再导入支持 MCP 的网关控制台即可完成路由。这样一来，业务团队就能把重心放在“工具描述写得好不好、跟 Agent 怎么配合”上，而不是“怎么写 MCP 代码”。

更进一步，有的网关还能把数据库（MySQL、PostgreSQL、ClickHouse 这些）直接暴露成 MCP 服务，只要提供连接信息，就自动生成查询和操作的工具。再配合一个注册中心做服务注册与动态发现，工具元信息还能实时下发、灰度更新，数量多了也不怕乱。

应用跑起来只是第一步

搭出一个能跑的服务器容易，让它稳定、高效、安全地跑在生产里，还要做几件精细活。

数据要精简。 不是所有 API 返回的字段都是模型需要的。在服务器端先做聚合和裁剪，只返回必需字段，省 Token 也更快；遇到模型不擅长的深层嵌套 JSON，先扁平化、拆成多次单层调用再在服务端拼起来。

性能要可靠。 给慢接口、稳定数据加缓存；耗时的操作走异步，别阻塞；数据库连接、HTTP 连接用连接池，配上合理的超时、重试、退避和熔断。再接入 Prometheus、Grafana、OpenTelemetry 这类监控，盯住延迟、错误率这些关键指标，出了问题好定位。

安全要守住。 用 API 密钥、OAuth 或临时令牌做身份认证，对工具的调用做细粒度权限控制，严格校验传入参数，防住任意 URL 访问和参数注入。每次工具调用的请求、参数、响应和耗时都记日志，方便审计。MCP 协议和 SDK 还在快速演进，要定期跟进官方规范，及时拿到安全补丁。

能力再扩展。 基础跑顺之后，还能接数据库做复杂查询、封装文件系统操作、调用外部 SaaS 的 API、支持 Webhook 做事件驱动、提供流式资源，一点点把 AI 的工具箱装满。

从一个“小而确定”的用例开始

搭 MCP Server 这件事，技术本身不算难，难的是把它做成生产可用。最实用的起步方式，是挑一个“小而确定”的用例，用现成的框架和工具先跑通，再逐步优化、迭代、扩展。

当你亲眼看到一段自己写的函数，被大模型读懂、调用，再返回一个真实的结果时，会发现给 AI “装手”这件事，门槛没有想象中那么高。而这套“协议 + 工具 + 治理”的组合，正是 AI 原生应用能真正落地的地基。