生成式AI带动代理型AI（Agentic AI）兴起，如何善用自主能力更胜以往的AI代理完成任务、事半功倍，一直是企业探索的重要议题。尤其，为让驱动AI代理的大型语言模型（LLM）使用外部工具和资料、产出更精准的回答，开发者得为每个资料来源，进行复杂的客制化串接。

Model Context Protocol（MCP）因此应运而生，它就像统一的USB-C接口，不论资料还是工具，只要支援MCP，AI模型就能找到正确又即时的内容，给出更精准的答案。

奥丁丁集团最近就实作MCP，做出一套MCP伺服器来连接API技术文件，方便Cursor这类AI辅助开发工具搜寻，让外部开发者透过AI问答，协助串接奥丁丁API、降低技术门槛。奥丁丁AI团队还预告，他们内部也要这么做，建置MCP伺服器来连接内部文件、加速自家开发流程。

缘起：API串接的3大痛点

奥丁丁AI团队首先点出，以往企业将AI介接外部工具或资源时，都会面临3大挑战。

第一，开发者得先阅读复杂的API技术文件。这是因为，开发者将AI串接外部特定资源时，得仰赖API，必须先阅读对方提供的API技术文件，自己再撰写一份指令，来教导AI如何使用这支工具或资源。

由于没有统一的API技术文件规格，这些文件可以很复杂，而且「AI所串接的每一支工具或资料库，我都要这么做，累积下来可能就有20、30份文件要处理。」

这情况带出第二项挑战，也就是维护成本。因为要处理的技术文件众多，若提供API的企业或官方更改API，开发者就得重写指令、重新教导AI使用该工具，衍生繁重的维护成本。

第三个挑战是重工问题。奥丁丁AI团队表示，由于AI介接外部工具没有统一的规格，常常介接A工具使用A格式、B工具使用B格式，导致开发者花时间重工，开发效率低下。

不过，就在2024年11月，AI业者Anthropic发布开放协定MCP，将AI模型与外部资料或工具互动的方式标准化，就像是AI的USB-C般，来让提供方和串接方遵循。

4大步骤实作MCP

常见的MCP支援方式有两种，一是作为MCP Server（伺服器端），由开发者建置一个轻量级程式（即MCP Server），来让外部AI或代理存取自家资源。另一种是作为MCP Client（客户端），来使用MCP协定，让自己的AI工具或代理存取各种支援MCP的资源，如知识库、API等。

观察MCP已久的奥丁丁AI团队，在今年初决定用自家的对外服务OwlPay Harbor来试水温。这是一款刚上线的API工具，支付业者可整合进自己的服务，来转换法币与稳定币。

接著，奥丁丁AI团队用4大步骤来实作MCP。第一步是设定目标，他们将目标定为，使用者可借AI之力，来更快速串接OwlPay Harbor。

意思是，奥丁丁选择作为MCP伺服器端，建置一套MCP伺服器，来连接自家API技术文件，让外部AI模型或代理存取。如此一来，外部开发者就能透过Cursor这类的AI问答，来简化API串接。

串接MCP后，外部开发者可直接对AI输入自然语言指令，AI代理就会自动将指令转成搜寻关键字，透过MCP工具直接查询技术文件，并自动产出API范例和专案架构，无需依赖外部搜寻引擎。

虽然MCP伺服器也能直接连结API，但奥丁丁AI团队选择只提供API技术文件、不提供整支API，原因是OwlPay Harbor为金流处理工具，涉及敏感资料，若由AI自动控制金流可能增加风险。因此他们采取较审慎的作法，将MCP保留最小操作权限，只锁定「引导企业使用者完成串接流程」，逐步协助使用者串接，而不是直接授权AI操作金流。

第二步是准备必要能力，也就是一支搜寻API，来告诉外部AI模型，如何检索这些技术文件。这支API就像是查询入口，让AI在推论过程中，动态取得正确的文件内容。

第三步是最有挑战的一步，要将API技术文件转换为AI可读的形式。奥丁丁AI团队解释，要让AI可搜寻检索，就得将文件内容改为AI看得懂的格式，需要「高度语义化。」

意思是，文件的结构和内容，都要明确标注并分类其「是什么」和「用来做什么」，让AI系统能自动理解并处理。举例来说，好的MCP输出结构，应该要「分层叙述」，也就是依序有大分类、标题、摘录和主文的层次，且在功能栏位中，要将URL从文件中分离出来，而非混合为一。（如下图）

另一方面，AI有其上下文窗口（Context window）限制，也就是AI一次互动可处理的最大Token（字符）数量，再加上AI多次互动时，会将先前的对话内容也算进窗口中，因此开发者必须控制文件长度，预留Token窗口供后续AI多次互动使用。「不能塞太多内容，否则AI容易出现幻觉，」团队强调。

奥丁丁AI团队根据经验法则，将单次MCP查询时所回复的API文件内容，控制在模型最大可读的Token总数一半以内。举例来说，若模型上限为10万个Token，单次回复内容则控制在5万个Token以内。这么做，可以预留空间来让AI有效理解问题本身、保持回应品质，避免「内容过长导致模型失效。」

与AI进行多轮对话时，AI会将过去的对话内容算进上下文窗口（Context window）中。因此，奥丁丁团队将单次MCP查询所回复的内容，控制在模型最大可读的Token总数一半。如此一来，AI才能有效理解问题、确保回应品质。

最后一步则是使用开源工具，如Anthropic释出的MCP工具，来将处理好的OwlPay Harbor技术文件和搜寻API封装成MCP工具并发布，来让其他支援MCP的AI模型安装、使用。

支援MCP不只降低开发门槛，还提供更精准回答

这种MCP支援，还有不少好处。比如对外部开发者来说，可以降低API串接门槛，不必单靠自己阅读API技术文件，而是透过AI问答、辅助撰写程式码完成。

举例来说，串接MCP后，开发者直接以自然语言输入指令，AI代理就会自动将指令转为搜寻关键字，透过MCP工具直接查询技术文件，并自动产出API范例和专案架构，不必依赖外部搜寻引擎。

再来，透过MCP支援，AI搜寻的资料范围更精准，回答也更准确。这是因为，AI工具使用外部搜寻引擎，寻找特定技术文件时，可能会搜寻到其他类似资料，并混在一起回答问题，进而产生幻觉。但透过MCP工具，AI可以存取特定内容并搜寻、产出答案，大幅降低取得错误或过时资讯的可能性。

另一个好处是，AI可透过MCP自主查询整份文件、撰写程式码，不会处理一个段落后，再向使用者索取额外资料才能继续作业。

除此之外，使用MCP还有安全上的好处。就使用者来说，AI工具透过MCP直接存取外部资源，使用者不必另外开网页、复制资料再贴到AI工具中，因此相对安全。

对作为MCP伺服器端的企业来说，因为需根据目的，去设计能让外部AI存取的内容，因此落实最小权限、给予最合适的内容范围，也确保资料安全。

观望者可从目标设定先著手

有了MCP实战经验，奥丁丁AI团队也不藏私分享实作心得建议，供观望者参考。

第一是确认目标，比如要做MCP伺服器端，还是MCP客户端。决定后，才能思考该为AI准备什么能力，并召集相关部门讨论可行方案，开发团队再给出开发方式、规格和时程。

第二个建议是安全性，也就是根据目标和希望给予AI的能力，来决定资料权限和范围，比如奥丁丁决定将自家API技术文件打包成MCP工具，来供外部AI存取，那么资料就得是原本已经公开的文件。

同理，若企业想将内部文件打包成MCP工具、供内部人员使用，也得先划分资料使用权限与范围，才能确保机敏资讯不外泄。

另一个建议是将文件改为AI可读的形式，尤其是建置MCP伺服器来让AI模型存取自家资料时，其资料格式、栏位就得高度语义化，且需保留适度的上下文窗口，才不会影响AI产出的答案。

这次实战经验，也让奥丁丁AI团队思考，未来要打包MCP伺服器来连接内部文件、资源，供内部团队使用。尤其，奥丁丁AI团队已高度运用AI协助开发，若AI能存取更多资料、工具，就能更加速开发流程，提高工作效率。文⊙王若朴