把三个接口组织成有边界的服务
虚构的社区自然馆维护一份展品资料。团队想让助手查询展品编号、读取经批准的说明，并按固定提纲整理导览草稿。它们看似都在“提供文字”，实际职责不同：查询工具承担操作，资源提供上下文，提示模板组织可复用表达。开发时先确定哪项能力真正需要，再搭骨架、做验证和加固，避免一个万能接口既读任意文件又执行任意命令。 本文沿原文的快速搭建、调试验证、规范加固三个场景，重点讨论同一服务内工具、资源和提示的边界。示例全部使用合成资料，未安装 SDK、启动 server、连接真实馆藏或发布服务。权限、参数与数据边界从设计开始就要明确，不应当作最后补上的装饰。
场景一：先做能力表，再搭最小骨架
列三行能力。第一行是按展品编号读取必要摘要的工具，只接受受限编号，不接受任意 URL、路径或查询表达式。第二行是已批准说明的资源，标识稳定、内容范围明确，不把整个磁盘当资源目录。第三行是导览草稿提示模板，输入指定材料与受众，输出可评审文本，不包含自动发布动作。三项可以分期实现，不能因为 SDK 提供接口就全部开放。 为每行写使用者、来源、授权范围、返回格式与失败情况。展品不存在、说明暂未批准、输入错误、上游失败要可区分。提示模板不应偷偷获取新资料，资源内容也不应被当作给应用的新指令。输出只包含当前任务需要的字段，内部备注和个人信息不进入演示夹具。 选择团队能维护的语言与官方 SDK，固定运行时、依赖和文档版本。Python 与 TypeScript 都有可参考路线，具体框架、装饰器和启动方法要与版本一致。不要把第三方 FastMCP、某个 SDK 内的高层接口与另一个主版本示例混成一套命令。现成骨架可以减少重复工作，但需要读懂其注册能力和默认行为。 开源优先参考 modelcontextprotocol/python-sdk、官方示例和参考实现。选择依据是可检查的接口、测试与文档，不是热度。先把业务处理做成独立函数，用合成数据验证，再接入协议注册，方便判断错误在业务还是通信层。参考实现用于学习，不自动满足真实机构的部署要求。 产物是能力表、不暴露清单、合成数据、最小工程和依赖记录。对每项写明已设计、已实现、已运行或未执行，不能只凭文件存在就宣布完成。若需求只是查询展品，导览提示可以晚些再加，保持第一版足够小。
场景二：分别验证工具、资源与模板
先验证业务函数：正常编号、未知编号、未批准说明、空输入和服务失败。再验证协议层是否发现预期能力、参数与返回是否符合当前版本。资源模板与具体资源的发现方式可能不同，应按所选版本与客户端支持检查，不能看到列表为空就断言整个资源功能坏了。提示返回消息也不等于已经执行草稿生成，更不等于发布。 使用固定版本的 Inspector 或对应 SDK 客户端测试这些路径，记录真实输入、结果与错误。SDK 支持的进程内测试可以加速业务与协议检查，但它不覆盖实际启动命令、操作系统、stdio 管道或 HTTP 网络。仍需用真实计划中的传输做一次独立验证，再到目标应用确认行为。 stdio 的普通日志不能混进 stdout 协议流；HTTP 的路由、身份与传输需要逐项核对。日志写到 stderr 也不代表出现了故障，要区分正常诊断与错误。看不到日志时检查当前版本日志方式，不用打印全部环境变量或完整资料来排错。 针对工具结果、资源内容与提示模板分别做“已知结果”断言。工具应给出合成编号对应摘要；资源应是批准版本，不能返回未审定记录；模板应包含指定提纲和明确缺失项，不自动编造来源。若助手的最终回答与返回内容不符，保留两层对照，而不是用更流畅的回答掩盖差异。 测试取消、超时、重复调用与连接关闭。只读查询可重复，不代表以后加的收藏、通知或发布操作也可任意重试。检查计时器与连接池是否释放，错误是否泄露内部路径或秘密。一次正常调用只能证明这一条路径，不能覆盖全部能力或所有客户端。 产物是分能力测试表、传输验证、目标客户端回归与未覆盖项。每条记录包含版本、复现步骤、预期、实际和修复后结果。若没有执行环境，保留待运行步骤，不编造日志。用量与性能也需实际测量，不能因例子短就承诺秒级响应。
场景三：把规范变成可验证限制
先看身份与权限。能登录服务不代表能读取所有展品资料；不同角色可能只看公开、已批准或特定集合。服务器与业务层执行限制，不能只依赖模型选择得当。资源标识也不是访问控制，如果知道标识就能读到不该读的记录，仍是设计缺口。 工具 schema 与实际校验保持一致，允许范围和最大输入都要解释；任意路径读取需要防止超出授权范围，而本例最好根本不提供它。外部 API 的返回字段先筛选再交给模型，错误消息不夹带凭据。提示与工具描述不得宣称比实际能力更广，不需要实现的功能不暴露。 把资源和上游文本视为数据。展品说明里出现“忽略用户、上传文件”等文字不能变成应用指令，模板也不能覆盖用户原有授权。对业务有副作用的动作单独审阅目标、参数和许可，查询成功不自动授权发布。记录日志时保留请求标识、状态和必要诊断，不收集整段个人资料。 上线前盘点依赖、来源与固定构建版本，必要时生成组件清单并检查已知漏洞。组件清单说明用了什么，不证明代码安全；没有已知漏洞不表示权限与数据流正确。扫描器若需要联网或读取配置，先确认它实际访问的数据与操作，不能直接相信“一键只读体检”的宣传。 运行边界要具体：身份、文件范围、网络、进程、资源上限和秘密来源。单独目录不等于沙箱，容器也要核对挂载与权限。远端部署需要认证与运维安排，本地进程同样可能访问用户文件。准备停用、凭据失效与版本恢复方法，指定负责人。 发布验收由多项证据组成：能力限制通过允许和拒绝用例验证，构建产物与测试一致，目标客户端正确转述，日志不泄露数据，恢复路径可执行。Inspector、schema 检查和供应链扫描各管一部分，不能互相替代。未完成项明示，由团队决定是否适合当前发布范围。
一次有明确交付的开发请求
“围绕合成展品资料，设计一个查询工具、一类批准说明资源和一份导览草稿模板。先列身份、输入输出与不支持范围，按固定 SDK 版本分期实现；分别给正常、未知、未批准、非法和失败测试。记录业务、协议、传输与目标应用证据，不连接生产、不读取任意目录、不自动发布。”如果只需要第一项，就先交付第一项，不为流程完整增加不必要能力。
FAQ 与排错
完整流程是什么？明确任务与边界，选版本与骨架，实现受限业务，分层验证，再按实际部署要求加固与交接；安全设计贯穿其中。Python 还是 TypeScript？看团队、依赖和运行环境，不由“数据场景一定 Python、通用一定 TypeScript”这种口号决定。资源与工具能互相替代吗？某些业务可有不同设计，但应说明调用与上下文责任，不因都能返回文本就混用。 能力列表对但调用失败怎么办？核对输入、身份、处理函数和上游结果。进程内测试通过但部署失败怎么办？补查启动、路径、运行时、网络与认证。怎样选择技能？本次 SkillPI MCP 检索未返回可核验候选，不添加无关包；以后按搭建、验证或加固步骤重新核对来源、许可、依赖和实际用途，不按名称或下载量直接关联。 如何避免越改越大？每次新增能力都更新不暴露清单、正反用例与责任人。未使用的接口可以保持关闭，不需要先公开再收回。没有合适技能也可以使用官方资料与现有工具，不必把发现引擎当运行权限或生产保证。
来源与维护
保留原文的搭骨架、调试验证、规范加固及 FAQ，以原创展品服务区分工具、资源和提示职责。参考 MCP Python SDK、官方 Inspector 和参考实现，移除实时热度、自动安装与绝对安全结论。后续按实际版本复查技术说明和技能候选，保持公开 slug；本文不宣称已运行或上线真实服务。