In just the past few weeks, the Model Context Protocol (MCP) has rapidly grown into the de-facto standard for integrating third-party data and tools with LLM-powered chats and agents. While the internet is full of some very cool things you can do with it, there are also a lot of nuanced vulnerabilities and limitations.

In this post and as an MCP-fan, I’ll enumerate some of these issues and some important considerations for the future of the standard, developers, and users. Some of these may not even be completely MCP-specific but I’ll focus on it, since it’s how many people will first encounter these problems

There are a bajillion other more SEO-optimized blogs answering this question but in case it’s useful, here’s my go at it: MCP allows third-party tools and data sources to build plugins that you can add to your assistants (i.e. Claude, ChatGPT, Cursor, etc). These assistants (nice UIs built on text-based large language models) operate on “tools” for performing non-text actions. MCP allows a user to bring-your-own-tools (BYOT, if you will) to plug in.

As a clear standard, it lets assistant companies focus on building better products and interfaces while letting these third-party tools build into the assistant-agnostic protocol on their own.

For the assistants I use and the data I have, the core usefulness of MCP is this streamlined ability to provide context (rather than copy-paste, it can search and fetch private context as it needs to) and agent-autonomy (it can function more end-to-end, don’t just write my LinkedIn post but actually go and post it). Specifically in Cursor, I use MCP to provide more debugging autonomy beyond what the IDE provides out of the box (i.e. screenshot_url, get_browser_logs, get_job_logs).

• ChatGPT Plugins – Very similar and I think OpenAI had the right idea first but poor execution. The SDK was a bit harder to use, tool-calling wasn’t well-supported by many models at the time and felt specific to ChatGPT.

• Tool-Calling – If you’re like me, when you first saw MCP you were wondering “isn’t that just tool-calling?”. And it sort of is, just with MCP also being explicit on the exact networking aspects of connecting apps to tool servers. Clearly the designers wanted it to be trivial for agent developers to hook into and designed it to look very similar.

• Alexa/Google Assistant SDKs – There are a lot of (good and bad) similarities to assistant IoT APIs. MCP focuses on an LLM-friendly and assistant agnostic text-based interface (name, description, json-schema) vs these more complex assistant-specific APIs.

• SOAP/REST/GraphQL – These are a bit lower level (MCP is built on JSON-RPC and SSE) and MCP dictates a specific set of endpoints and schemas that must be used to be compatible.

I’ll start with a skim of the more obvious issues and work my way into the more nuanced ones. First, we’ll start with non-AI related issues with security in the protocol.

Authentication is tricky and so it was very fair that the designers chose not to include it in the first version of the protocol. This meant each MCP server doing its own take on “authentication” which ranged from high friction to non-existing authorization mechanisms for sensitive data access. Naturally, folks said auth was a pretty important thing to define, they implemented it, and things… got complicated.

Read more in Christian Posta’s blog and the on-going RFC to try to fix things.

The spec supports running the MCP “server” over stdio making it frictionless to use local servers without having to actually run an HTTP server anywhere. This has meant a number of integrations instruct users to download and run code in order to use them. Obviously getting hacked from downloading and running third-party code isn’t a novel vulnerability but the protocol has effectively created a low-friction path for less technical users to get exploited on their local machines.

Again, not really that novel, but it seems pretty common for server implementations to effectively “exec” input code. I don’t completely blame server authors, as it’s a tricky mindset shift from traditional security models. In some sense MCP actions are completely user defined and user controlled — so is it really a vulnerability if the user wants to run arbitrary commands on their own machine? It gets murky and problematic when you add the LLM intention-translator in between.

The protocol has a very LLM-friendly interface, but not always a human friendly one.

A user may be chatting with an assistant with a large variety of MCP-connected tools, including: read_daily_journal(…), book_flights(…), delete_files(…). While their choice of integrations saves them a non-trivial amount of time, this amount of agent-autonomy is pretty dangerous. While some tools are harmless, some costly, and others critically irreversible — the agent or application itself might not weigh this. Despite the MCP spec suggesting applications implement confirm actions, it’s easy to see why a user might fall into a pattern of auto-confirmation (or ‘YOLO-mode’) when most of their tools are harmless. The next thing you know, you’ve accidentally deleted all your vacation photos and the agent has kindly decided to rebook that trip for you.

Traditional protocols don’t really care that much about the size of packets. Sure, you’ll want you app to be mobile-data friendly but a few MBs of data isn’t a big deal. However, in the LLM world bandwidth is costly with 1MB of output being around $1 per request containing that data (meaning you are billed not just once, but in every follow-up message that includes that tool result). Agent developers (see Cursor complaints) are starting to feel the heat for this since now as a user’s service costs can be heavily dependent on the MCP integrations and their token-efficiency.

I could see the protocol setting a max result length to force MCP developers to be more mindful and efficient of this.

LLMs prefer human-readable outputs rather than your traditional convoluted protobufs. This meant MCP tool responses are defined to only be sync text-blobs, images, or audio snippets rather than enforcing any additional structure, which breaks down when certain actions warrant a richer interface, async updates, and visual guarantees that are tricky to define over th