X 热议：Theo 称大模型「仍然很不擅长给 Agent 造工具」，让 Opus 搭 MCP 认证流程屡屡出错，提醒别轻信 Agent 给的 MCP「最佳实践」

核心背景与行业痛点

MCP（Model Context Protocol）已成为 Agent 接入外部工具的事实标准，但一旦涉及远程 MCP 服务器的登录授权，开发者普遍头疼。T3 Chat / T3 Code CEO Theo 11 月 8 日发帖吐槽：大模型「仍然很不擅长给 Agent 造工具」，每次让 Opus 搭 MCP 认证路径都会出错。这条帖子约 880 赞、136 条回复、6.5 万次浏览，说明「模型写业务代码很强、写 Agent 基础设施却不靠谱」是不少人的共同感受。需要说明的是，这是个人使用体验，并非系统评测。

架构亮点与底层机制

为什么认证特别难？按 MCP 官方规范，基于 HTTP 的 MCP 服务器是 OAuth 2.1 资源服务器，客户端必须实现 PKCE，还要处理授权服务器发现、受保护资源元数据（RFC 9728）、客户端注册（预注册、Client ID 元数据文档或动态注册）以及 resource 参数等环节；而 stdio 传输不走这套流程，直接从环境变量取凭据。环节多、版本迭代快，模型容易套用常见 OAuth 教程里的假设。Theo 的追帖截图里，Agent 起草的指南把 MCP 地址写成给用户点击的链接，正是这种「看似合理、实际不对」的典型。

权威 Benchmark 与实测跑分对比

目前没有专门衡量「模型实现 MCP 认证」能力的公开 Benchmark，官方未公布相关跑分；Theo 也没有给出成功率等量化数据。本条仅为 X 上的讨论，热度数据来自 X 公开计数。回帖中也有不同声音：有人认为他用的推理档位不够高，也有人认为问题在于 MCP 认证规范一年内改过几版、训练数据跟不上。

开发者实战落地与开箱指南

如果你也要让 Agent 写 MCP 认证：1）把当前版本的 MCP 授权规范原文放进上下文，而不是让模型凭记忆；2）先手工跑通一次真实请求，把它作为示例；3）远程或无头服务器场景，可考虑设备码授权（RFC 8628），回帖里也有人这样建议；4）给过期令牌、权限被拒、登录中断等情况写测试，再判断「做完了」；5）对 Agent 给出的「最佳实践」保持怀疑，以官方文档为准。