是否实际开发过 MCP、Skill 或 A2A 工具？

核心回答

下面以天气查询 MCP 工具给出一份开发经历答法示例。

我实现的是把天气服务封装成 Agent 可调用的工具。输入是城市与查询条件，输出是标准化天气数据或可识别的错误；我负责业务接口适配、参数与结果契约、凭证注入和错误处理，再由 MCP 接入层把这项能力暴露给宿主。

一次请求中，宿主获取工具说明并交给模型，模型给出工具名与参数，MCP Client 转发到服务端执行，结果再回填到对话。我会先做固定参数的直接调用，再检查自然语言任务能否选对工具、填对参数并据实际结果回答。

这条链路重点处理的失败是上游请求超时：不能把空返回解释为“没有天气数据”，而要映射成查询未完成，让 Agent 说明状态或按策略重试。凭证保留在执行端，结果和日志不包含密钥。Skill 可以补充缺城市先问等方法；跨 Agent 委派属于 A2A 的范围，这个示例只采用天气工具路线。

开发时具体写什么

业务层负责查询天气服务：校验城市和单位，设置请求超时，识别城市不存在、限流和上游不可用，过滤与任务无关的数据。凭证由执行端配置读取，不让模型生成密钥，也不回传到日志或结果。

协议层负责暴露工具名称、用途与参数说明，返回结构化数据。FastMCP 可以从函数签名和类型注解生成参数契约，但类型符合不等于业务正确，仍要检查允许值与返回内容。这里的独立 FastMCP 库与官方 MCP Python SDK 内的旧版同名类不能混用导入和启动参数。

客户端层负责将服务端能力接入宿主，再把工具调用结果写回对话。模型生成工具请求，真正的网络请求由客户端和服务端执行。工具直接调用能成功后，再接入模型检查是否选对工具、参数是否合理；两种检查不能合并成一句“对话跑通了”。

一次调用怎样验证

可以先构造“北京当前天气”的固定请求，检查工具发现结果中确有目标工具，输入契约与预期一致；再直接调用它，核对返回城市、单位、数据时间与状态。随后从自然语言任务运行一次完整链路，检查模型给出的调用参数、服务端执行记录、工具结果与最终回答是否对应。

边界用例至少包括缺城市、城市不存在、上游超时、认证失败和结果格式异常。对超时返回，说明未获得结果，不拼造天气数值。追踪信息应能关联请求、工具名、执行状态和耗时，同时隐藏凭证。

接入时固定协议与 SDK 版本。2025-11-25 及以前版本有初始化握手；2026-07-28 改用请求中的版本和能力元数据。因此验证顺序应遵循选定版本，不能把教程旧版握手写成所有实现的必经步骤。

追问

只是给已有 API 加一层包装，也算开发工具吗？

算业务集成与工具开发。价值在于把外部接口转成模型能准确选择、执行端能可靠处理的能力；是否改动框架源码是另一件事。

为什么还要说明 A2A？

为了交代能力边界。调用天气函数可以通过 MCP；把一项研究任务委派给远端专业 Agent，再接收任务状态与产物，才需要考虑 A2A 这类 Agent 协作协议。无需把工具调用包装成多 Agent 经历。

对应教程

参考资料