Theo (@theo), CEO of T3 Chat and T3 Code and a well-known developer YouTuber, posted on November 8 that LLMs are "still SO bad at building tools for agents": every time he asks Opus to set up an MCP authentication path, it "makes horrible assumptions and builds something that straight up doesn't work." About two hours later he added that he is writing an "MCP the right way" guide for his own agents; when he had them draft a first version, they proposed rendering the MCP URL as a clickable link for users, and he warned people not to trust "ANYTHING" agents say about MCP, connection strategies and agent "best practices." At writing time the first post had about 880 likes, 136 replies and 65,000 views.

Key Takeaways

  • ✓Original post (@theo, November 8): when he asks Opus to set up an MCP authentication path it "makes horrible assumptions" and builds something that "straight up doesn't work"
  • ✓Follow-up (@theo): an agent-drafted "MCP the right way" guide proposed rendering the MCP URL as a clickable link, and Theo called agents "CLUELESS" about MCP and connection strategies
  • ✓Engagement (public X data at writing time): about 880 likes, 136 replies, 138 bookmarks and roughly 65,000 views on the first post; about 344 likes, 51 replies and 164 bookmarks on the follow-up
  • ✓Context: MCP authorization builds on OAuth 2.1, requires clients to implement PKCE and references several standards including Protected Resource Metadata (RFC 9728) and Dynamic Client Registration (RFC 7591), while stdio transports skip it (MCP spec)
  • ✓Replies: some say MCP auth changed several times within a year so training data lags; others suggest giving the model the exact spec plus one working request, and defaulting to the device authorization grant (RFC 8628) on headless servers
X Discussion: Theo Says LLMs Are "Still So Bad" at Building Tools for Agents, Opus Keeps Botching MCP Authentication, and Warns Not to Trust Agents on MCP "Best Practices"
🖼️Official Media
Click to view high-res
🧭

Turn your technical choice into a development budget

Compare 40 dev plans & simulate token costs vs $20/mo subscriptions

🔬

In-Depth Technical Analysis

Core Background & Industry Pain Points

MCP (Model Context Protocol) has become the de facto way agents connect to external tools, but authorization for remote MCP servers remains a common headache. On November 8, Theo, CEO of T3 Chat and T3 Code, posted that LLMs are "still SO bad at building tools for agents" and that Opus keeps getting MCP authentication wrong. With about 880 likes, 136 replies and 65,000 views, the post struck a nerve: models write application code well but stumble on agent infrastructure. This is one developer's experience, not a systematic evaluation.

Architecture Highlights & Internals

Why is auth so hard? Under the official MCP specification, an HTTP-based MCP server is an OAuth 2.1 resource server, clients must implement PKCE, and the flow involves authorization server discovery, Protected Resource Metadata (RFC 9728), client registration (pre-registration, Client ID Metadata Documents or dynamic registration) and the resource parameter. stdio transports skip all of this and read credentials from the environment. With many moving parts and a fast-changing spec, models tend to fall back on assumptions from generic OAuth tutorials. In Theo's follow-up screenshot, an agent-drafted guide renders the MCP endpoint as a clickable link for users, a plausible-looking but wrong design choice.

Authoritative Benchmarks & Measured Scores

There is no public benchmark for how well models implement MCP authentication, and no official scores have been published. Theo gave no success rates either. This item covers an X discussion; engagement figures are public X counts. Replies were mixed: some said he was not using a high enough reasoning setting, while others blamed the MCP auth spec changing several times in a year, leaving training data behind.

Developer Hands-on Guide

If you want an agent to build MCP auth: 1) put the current MCP authorization spec in context instead of relying on model memory; 2) get one real request working by hand and give it as an example; 3) for remote or headless servers, consider the OAuth device authorization grant (RFC 8628), as some replies suggested; 4) write tests for expired tokens, denied permissions and interrupted sign-in before calling it done; 5) treat agent-suggested "best practices" with skepticism and defer to the official docs.

Action HubReady to adopt this in production?

Benchmark side-by-side against alternatives, or calculate monthly token cost vs subscription break-even.

Up NextMCP TypeScript SDK 2.2.0: M2M OAuth expectedIssuer, auto-paging list*, CJS jose types + Client.listen hang fixes
Read Now→