People are scurrying to release MCP servers, and there's been a flurry of them put out - but it feels like we've skipped straight to the advanced tooling, on top of a stack that might not have found it's footing (yet).
I understand MCP, the problem it solves, and why it seems a good idea ... but outside of toy applications, are they proving to be useful?
I don't.
Can you ELI5 why it's a good idea for me?
I see what people are doing (1), and I see what the intent is (2), but no one seems to have an explanation of why it helps.
The original MCP documentation has some vague hand waving about (3) about having prompts that would help ... with, something. ...but I don't see it in practice.
?
Is this why people are asking "does this actually work?"
...because, its obviously not any better than the 'tool use' API that everyone was already using. It can't be. It doesn't do anything differently.
I would bet that it actual makes agents less capable when you overload their context with unrelated tools that aren't relevant. Right?
How can it possibly help?
It sounds a lot like it rests on the assumption that adding tools is a zero-cost zero-impact +capability action only, but that can't be true.
(1) - https://github.com/punkpeye/awesome-mcp-servers
(2) - https://modelcontextprotocol.io/quickstart/server#what%E2%80...
Instead of you writing tool use code (which requires you to know how to write code, and to put in the effort), you spin up a server that provides that tool use code for the LLM.
As an example, you could hook up an "email" MCP that connects to your email provider and provides a "get_unread" tool and a "send_email" tool, and then go nuts having a chat with your LLM saying "hey let's work through our unread emails, bring up the first and then come up with a draft response for it, for me to review before sending". Hook it up with the "linear" MCP, and tell the LLM to also raise tickets with all the relevant details in your project management tool.
Of course you could write those tools yourself, and control all of the prompting, etc, but the point of MCP is so you don't have to write anything.
That's the ELI5, I think. "pre-built tools for the tool use API".
I don't think that's true, but even if it's not, there's such a thing as being too early to market, and that a very similar product just launched later is a success when the original isn't. There are some differences; it's like how FTP is different from HTTP but also it isn't.
For example, depending on the model I use in LMStudio - some can use tools, but it doesn't yet seem to support MCP - on the other hand, cursor does - but then either it's servers or via stdio - the setup isn't entirely clear.
Also it seems that giving random access to a LLM, even if local, via an intermediate server is ripe for abuse unless you know what it's doing?
We often help customers set up their "data model". We use Cube (open source semantic layer) for this and need to write many files in a mix of SQL and YAML that defines what tables and columns they'll see in the UI.
This can be pretty tedious, but claude / cursor is very good at it. You feed in the schema (via an MCP) and can provide some questions the user wants to answer. Here's how it might look on one question:
1. The user wants to answer "Which channels from hubspot generate the highest LTV customers? Which channels have the lowest churn?"
2. The agent will search the schema for relevant raw data and start editing the data model. In this example, we might need to add a join between hubspot and stripe.
3. Once it has the raw data and an idea of how they relate, we'll create metrics and dimensions that answer the question.
We'll add these abilities to our built-in agent once we perfect a few things, but I see MCP's as a good testing ground for things you ultimately want to build into your own agent.
That said, I don't really expect the AI itself to come up with docs to read (maybe some day). I want it predominantly so I can manually reference it in my prompt (in e.g. the Zed assistant panel) like `/npmdocs packagename packageversion`.
But even for AI "self-driven" use-cases, I primarily see the value in read-only MCP servers that provide more context, just in an "as-needed" way, instead of me putting it there explicitly.
I feed LLMs documentation in case of obscure languages and it more or less works (with Claude).
I tried a bit with the filesystem-mcp server but claude ended up using it when I didn't really want it to, and even tried to write files instead of simply responding in code fragements that I wanted to wire up myself.
I feel like once your project has any meaningful size no MCP server is going to be able to actually find the relevant context by itself, so you're better of providing it yourself (at least via the @ syntax in cursor)
It also tried to read files when I was putting in the context myself (because I knew it was too specific for a few read files ops to find the context it needed) that's just... not very practical.
> Logged-in as user [email protected], I cannot see the Create Project button on the Project list screen. Use MCP to see if I have the correct permissions. If I do, verify that we are checking for the correct codes in the UI.
Making Cursor/Windsurf data-aware is amazing for data related debugging.
The stuff that's cool works with purpose-built tools like what cursor and claude code do to edit files, run commands etc. Bring your own function hasn't really been useful to me.
That being said I do believe that giving current relevant documentation into the context does help with results. I've just yet seen anyone do that very successfully in an automated fashion.