From checking our bank balances to planning our workout routines, APIs facilitate the interactions we take for granted. We're witnessing a new layer of interaction emerging with Model Context Protocol (MCP), a fascinating shift worth architectural examination.

"Yet another protocol?" I thought. But as I dug deeper, I realized we're looking at an intriguing evolution in how we interact with digital services. Let's dive into the architecture, constraints, and some honest assessments of what MCP brings to the table.

Applying Fielding's Method

When Roy Fielding introduced REST in his 2000 dissertation, he outlined a methodology for defining architectural styles:

  1. Start with a null architecture (no constraints)
  2. Determine desired properties of the system
  3. Apply architectural constraints to achieve those properties
  4. Document necessary trade-offs that come from applying constraints

This approach helps us understand why certain architectural decisions were made, not just what they are. Let's apply this methodology to MCP.

The Null Architecture

In the null style, there are no constraints. Components can interact in any way, with no distinguished boundaries between them. It's architectural anarchy, freedom but chaos.

For MCP, this would mean AI assistants and tools interact without any standardized pattern. Each assistant would need custom integration with each tool, resulting in the "MN problem": M assistants needing N distinct tool integrations, creating MN integration points.

Desired Properties

If I were architecting MCP from scratch, I'd identify these desired properties:

  1. Interface uniformity: AI assistants should interact with tools through a consistent interface
  2. Tool discovery: Assistants should dynamically discover available tools
  3. Content flexibility: The protocol should handle various data types and formats
  4. Local and remote operation: Tools should function both locally and over networks
  5. Stateful context: Assistants should maintain context across interactions
  6. Security and consent: Users should control which tools assistants can use