Model Context Protocol (MCP): ThoughtWorks Radar Puts Integration Standard to the Trial

Published on 18.01.2025

Model Context Protocol (MCP): A New Standard for LLM Integration Gets Real-World Scrutiny

TLDR: ThoughtWorks has placed the Model Context Protocol in their Technology Radar's TRIAL phase, recommending teams explore it for connecting LLMs to external data and tools, but with significant caveats around security, architectural maturity, and the need for careful evaluation before production deployment.

Summary:

The Model Context Protocol represents an ambitious attempt to standardize how Large Language Model applications connect to the outside world. Rather than every AI application reinventing how to plug into databases, wikis, or external services, MCP provides a common language. Think of it as the API specification layer that sits between your LLM-powered agent and everything it needs to interact with. On one side, you have MCP servers that expose data sources and tools. On the other, you have MCP clients—the agents, applications, and coding assistants that need to access those resources.

What makes this particularly interesting is the timing and adoption velocity. ThoughtWorks notes that major players like JetBrains and Apple have joined the ecosystem, while new frameworks like FastMCP are emerging to make implementation easier. There's now a preview MCP Registry for discovering both public and proprietary tools, which suggests the ecosystem is maturing beyond the experimental phase. This kind of momentum is significant—when enterprise-grade tooling companies commit resources, it signals confidence in the protocol's longevity.

However, ThoughtWorks' assessment carries important nuances that architects and engineering leaders need to understand. While placing MCP in the TRIAL phase—meaning "worth pursuing" and worthy of enterprise exploration—they're simultaneously raising red flags about architectural decisions. The criticism centers on the protocol's rapid evolution outpacing architectural maturity, with specific concerns that it overlooks established RPC (Remote Procedure Call) best practices that have been refined over decades. This isn't just academic nitpicking; it suggests potential pain points around versioning, backward compatibility, and error handling that teams will encounter as they scale.

The security dimension deserves particular attention. ThoughtWorks explicitly recommends using tools like MCP-Scan to examine "toxic flows"—problematic interaction patterns that could introduce vulnerabilities or unexpected behavior. They also emphasize the need to monitor the draft authorization module closely. This is the kind of warning that should make every security-conscious team pause. When a respected consultancy tells you to apply "additional scrutiny beyond promotional materials," they're diplomatically suggesting that the marketing around MCP may be getting ahead of its production readiness. For teams in regulated industries or handling sensitive data, this means treating MCP integration as a careful architectural experiment rather than a drop-in solution.

The relationship between MCP and complementary technologies adds another layer of complexity. MCP deliberately focuses on context and tool access, leaving agent-to-agent communication to other protocols like A2A. It works alongside frameworks like LangGraph and Pydantic AI, which means teams need to understand how these pieces fit together. This modular approach has merit—it allows each protocol to excel at its specific responsibility—but it also means integration complexity lives at the boundaries between these systems.

For architects and teams considering MCP, the strategic question isn't whether the protocol has potential—it clearly does—but rather how to de-risk its adoption. The ThoughtWorks assessment suggests a phased approach: start with internal experimentation, invest in security scanning early, maintain architectural discipline around RPC patterns even if MCP doesn't enforce them, and stay closely connected to the evolving authorization specifications. Teams should also prepare for breaking changes as the protocol matures, which means building abstraction layers that can insulate application code from protocol evolution.

Key takeaways:

  • MCP provides a standardized way for LLM applications to connect to external data sources and tools, with growing adoption from major companies like JetBrains and Apple
  • ThoughtWorks places MCP in TRIAL phase, recommending exploration but warning about architectural gaps, especially around RPC best practices and security concerns
  • Production deployment requires security scanning with tools like MCP-Scan, close monitoring of authorization modules, and architectural discipline beyond what the protocol itself enforces
  • The protocol's rapid evolution suggests teams should build abstraction layers and prepare for breaking changes while the specification stabilizes

Tradeoffs:

  • Gain standardization and ecosystem momentum but sacrifice architectural maturity and proven RPC patterns
  • Adopt early to influence direction and build expertise but sacrifice production stability and comprehensive security guarantees
  • Use modular protocol design (MCP for context, A2A for agents) but accept increased integration complexity at boundaries

Link: Model Context Protocol (MCP) - ThoughtWorks Technology Radar