Everything Wrong with MCP

Summary

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 problemsThere 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.MCP serves as a way to connect third-party tools to your existing LLM-based agents and assistants. Say you want to tell Claude Desktop, “Look up my research paper on drive and check for citations I missed on perplexity, then turn my lamp green when complete.” — you can do this by attaching three different MCP servers.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 ...