远程 MCP 开发人员应避免的 3 个问题

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

远程 MCP 服务器才刚刚起步。随着越来越多的平台推出对模型上下文协议 (MCP) 的支持，我们看到开发者的实验活动正在迅速增长——与此同时，我们也看到许多团队在首次构建 MCP 服务器时会遇到的常见陷阱。

在Portia，我们测试了各种各样的远程 MCP 服务器，从 Asana、Atlassian、Intercom 和 Stripe 等主流供应商，到 Fulcra、Globalping 和 Invideo 等新兴集成方案。在此过程中，我们发现了一些反复出现的问题，这些问题导致 MCP 服务器更难使用、部署速度更慢，并且在生产环境中更不稳定。

【简单介绍一下——Portia 是一个框架，它使开发者能够构建安全可靠的 AI 代理。我们非常欢迎您查看我们的 SDK并给它点个赞！ ⭐ 🙏】

以下是我们建议每位 MCP 开发人员避免的 3 个错误。

1. OAuth 重定向仅在本地主机上有效

我们测试的几个 MCP 服务器在本地运行正常，但在实际的测试或生产环境中却出现故障。一个常见的原因是：OAuth 重定向 URI 被硬编码，仅允许特定地址localhost访问。虽然这在初始开发阶段可能很方便，但却会阻碍在任何远程环境中进行测试。

例如，我们无法添加 Atlassian，因为他们在授权流程中拒绝了有效的重定向 URI。这使得集成商几乎不可能在其部署管道中正确测试您的服务器。

✅最佳实践：始终允许 OAuth 客户端使用多个重定向 URI，包括本地和远程环境。理想情况下，应允许每个客户端单独配置此设置。

2. 缺少.well-knownOAuth 元数据或工具发现配置错误

MCP 规范依赖于能够使用.well-known/oauth-authorization-server端点自动发现 OAuth 配置。包括 PostHog、Semgrep 和 Invideo 在内的多个服务器要么无法提供此文件，要么需要令牌才能访问 tools/list 端点，这导致无法发现工具。

没有有效.well-known文件：

• 客户端库无法自动配置 OAuth。
• MCP代理无法轻易发现您的工具。
• 开发者体验受到影响。

✅最佳实践：确保您的.well-known/oauth-authorization-server身份验证可公开访问、符合标准，并返回必要的 OAuth 元数据。

3. 服务器可用性不稳定

MCP 服务器需要处理动态发现、令牌交换和工具调用，这要求服务器具有相当高的可靠性。在我们的测试中，我们遇到了一些服务器因维护而宕机（Asana），一些服务器间歇性不可用（Plaid、Neon），还有一些服务器授权流程失败并返回无用的错误信息（Fulcra）。

在智能体世界中，不可靠性不仅会阻塞单个 API 调用，还可能破坏整个任务链和工作流程。

✅最佳实践：尽早投资于正常运行时间监控、清晰的错误信息和全面的 OAuth 错误处理。MCP 服务器应该能够优雅且可预测地应对故障。

好消息：使用 Portia 进行测试非常简单

如果您正在构建新的远程 MCP 服务器，测试您的实现不必那么麻烦。Portia 让您能够轻松地在代理应用程序中直接集成、验证和试验新的 MCP 服务器——通常只需点击 3 次即可完成。

随着 MCP 生态系统的成熟，我们很高兴能够帮助开发者交付更可靠、更易于代理使用的集成，这些集成可以在测试环境、生产环境以及两者之间的任何环境中正常工作。

关于波西亚的更多内容

Portia AI是一个开源框架，用于构建可预测的、有状态的、经过身份验证的代理工作流。

我们允许开发人员根据自己的意愿对多代理部署进行任意程度的监督，并且我们非常注重生产就绪性。

我们邀请您体验我们的 SDK ，尽情尝试各种功能，并在Discord上告诉我们您的使用感受。