Difference between revisions of "Model Context Protocol"

Revision as of 22:13, 6 September 2025

Full Title or Meme

MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.^[1]

Context

Quantum computers are expected to break traditional cryptographic systems like RSA and ECC. In response,

MCP is a security nightmare!

Don’t get me wrong — at Wexa, we see Model Context Protocol as the HTTP of the GenAI era. It’s the missing link to make AI assistants truly agentic and interoperable.

Problems

MCP doesn’t govern security by default. -> Tool poisoning attacks are a cakewalk if you’re not explicitly validating or sanitizing inputs. Anyone can sneak in malicious instructions through tool descriptions or context — and the model will just obey.

Versioning is a mess. -> There’s no clear standard for how models or tools should handle different MCP versions. That means you risk breaking tools silently — or worse, running outdated logic with no warning.

Persistent context = persistent risk. -> If your AI coworker remembers things across sessions, what happens when the context itself is compromised or manipulated?

We’re bullish on MCP — it’s foundational to how we’re building secure, scalable AI agents inside Wexa.

if you’re using MCP in production today, you’re likely exposed unless you’ve already wrapped it in a tight security layer.

MCP is powerful. But don’t assume it’s safe out of the box.

• The MCP Bandwagon 2025-07-01 Heather Flanagan

Possibilities

Is MCP the new HTML?

While building the Hellō Admin MCP Server, I had a fascinating realization: I wasn't building an app for humans anymore—I was building for AI agents. Instead of designing user interfaces and optimizing for human interaction patterns, I found myself thinking differently:

• Will the agent understand how to help users add Hellō Login to their apps?
• Can it figure out the correct redirect URI configuration?
• Will it know to upload both light and dark mode logos in the right dimensions and formats?

This shift feels monumental. Just like HTML became the universal language for human-computer interfaces on the web, MCP (Model Context Protocol) might be becoming the universal language for agent-computer interfaces.

We're moving from "How do I make this intuitive for a person to click?" to "How do I make this discoverable and actionable for an AI agent?"

The implications are huge:

• MCP servers are designed for agent consumption
• Documentation that teaches agents
• User experiences mediated through intelligent intermediaries
• A new layer of abstraction in how we interact with software

When HTML emerged, it democratized publishing and connected the world through hyperlinks. MCP might be doing something similar—democratizing AI capabilities and connecting agents to every corner of our digital infrastructure. Are we witnessing the birth of a new foundational protocol for the agent era?

hashtag#AI hashtag#MCP hashtag#AgentComputing hashtag#FutureOfWork hashtag#DeveloperTools

Tom Jones * mcp might be a step in the right direction but it needs to be adapted better to human needs before it is widely deployed. I have been disappointed by sub-optimal solutions in networking too often to accept the first iteration.

Steve Nakata While MCP looks promising for enabling AI agents, I’m definitely concerned about maintaining access security. I found this article helpful in understanding the details: https://julsimon.medium.com/why-mcps-disregard-for-40-years-of-rpc-best-practices-will-burn-enterprises-8ef85ce5bc9b

Why MCP’s Disregard for 40 Years of RPC Best Practices Will Burn Enterprises Fool me once, shame on you; fool me twice, shame on me.

OAuth

Dick Hardt = OAuth is not a good fit for MCP - 2025-08-24

After implementing MCP authorization for Hellō and writing thousands of lines of "code in English" (inspired by Andrej Karpathy's Software 3.0 talk), I've learned that OAuth between MCP clients and servers creates more problems than it solves. The core issues:

• OAuth is built for the web. Not all clients are on the web
• Dynamic Client Registration wasn't designed for this - we ended up circumventing it entirely
• Bearer tokens on client devices are a security risk with no DPoP protection
• No confirmation flows for sensitive operations (unlike traditional web UIs)
• Coarse-grained scopes don't match real-world access control needs
• Every client needs to implement complex OAuth flows and token management

My solution: Move authorization management to MCP servers and bind clients and servers with HTTP Message Signatures. This eliminates DCR, keeps tokens server-side, enables fine-grained access control, and lets organizations use their existing authorization systems.

I've drafted a full SEP (Specification Enhancement Proposal) for this approach. What do you think - should we rethink how AI agents authenticate to services?

Also - the Hellō MCP server is now live as a beta - you can create and manage apps directly from VS Code, Cursor, or Claude. Most of the code was written by AI, which is both fascinating and eye-opening

• Admin MCP Server (BETA)
• [SEP-1299: Server-Side Authorization Management with Client Session Binding

Nicola Gallo ZTAuth* => I agree with many of your points. MCP currently uses HTTP, so we are focusing on that first. And yes, we are already hitting the limits of the OAuth model, especially when it comes to token security, lack of DPoP, and the complexity of dynamic client handling.

Your SEP approach with HTTP Message Signatures is a step forward for the HTTP use case. It makes sense to keep tokens server-side and leverage existing authorization systems where possible.

At the same time, I believe the problem is even broader. It needs to be solved across all distributed systems, even when there is no human interaction and no HTTP. In the near future, more and more systems will rely on agents that run in different locations and communicate through messaging, not just over HTTP.

We already saw this trend with microservices. In that context, patterns like Saga emerged, where agents perform steps across different systems. Authorization becomes a serious challenge here too.

Passing tokens in messages is not safe. That’s why I am working on ZTAuth*. If it works there, it will naturally work over HTTP as well.

https://spec.ztauthstar.com/openprotocolspec/2025-04-05/manifest/

Solutions

• 2025-08 SEP-1299: Server-Side Authorization Management with Client Session Binding #1299 Dick Hardt
• See wiki Attention Economy for more on Agent to Agent(A2A) solutions
• 2025-05-23 Security In and Around MCP: Part 2 — MCP in Deployment Maia Iyer, Mariusz Sabath, Alan Cha, Hai Huang, Paolo Dettori, Jarek Cwiklik
• 2025-05-16 AWS Load MCP from the command line with one call Using Amazon Q Developer on the command line
• 2025-05-14 there is another layer here that bears deeper discussion, and that's how the two sides of the MCP proxy relate to each other, and what that means to the overall security posture. Tangled Tokens and Authorized Agents
• 2025-05-12 Why AI agents need a protocol like MCP to reach their potential MCP is “an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools,” Anthropic wrote in a blog post announcing it was open sourcing the protocol.
• 2025-04-11 Enterprise-Grade Security for the Model Context Protocol (MCP): Frameworks and Mitigation Strategies
• 2025-04 Google joins OpenAI in adopting Anthropic's protocol for connecting AI agents - why it matters
• 2024-03-19 Introducing Model Context Protocol (MCP) in Copilot Studio: Simplified Integration with AI Apps and Agents Microsoft
• Xinyi Hou, Yanjie Zhao, Shenao Wang, Haoyu Wang Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions 2025-03-30 https://arxiv.org/abs/2503.23278
• 2024-11-25 Introducing the Model Context Protocol

Enable AI Agent

Difference between RAG & MCP

The difference between RAG (Retrieval-Augmented Generation) and MCP (Model Context Protocol) lies in their approach to data retrieval and usage in AI systems:

• RAG (Retrieval-Augmented Generation):
  • RAG fetches external data in real-time to augment the AI's responses. For example, it might query a database or API to retrieve the latest information before generating an answer or to validate a generated answer.
  • It is highly flexible, allowing AI to access diverse sources for context-specific queries. However, it can be resource-intensive, as each query requires external connections.
• MCP (Model Context Protocol):
  • MCP focuses on maintaining context within the AI itself, enabling it to remember previous interactions and provide personalized responses.
  • It reduces the need for external data retrieval, relying on stored memory and predefined prompts.
  • MCP is more efficient for workflows requiring continuity and real-time data integration.

In essence, RAG is like fetching fresh data for every query, while MCP is about leveraging stored context for smarter, seamless interactions

Authorization

Aaron Parecki

• Let's fix OAuth in MCP

Enterprise

Aaron Parecki

• Enterprise-Ready MCP

References

1. ↑ Get started with the Model Context Protocol (MCP) https://modelcontextprotocol.io/introduction

Other Material