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.
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.
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).
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?
> Logged-in as user project-admin@domain.com, 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.
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.
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)
npx apidog-mcp-server --oas https://petstore.swagger.io/v2/swagger.json or npx apidog-mcp-server --oas ～/data/petstore/swagger.json
So this is about web APIs? I dislike that the broad term "API" has started to be used as shorthand for "HTTP API" (and probably REST-ish HTTP APIs specifically). It wastes people's time trying to figure out if something is of interest to them. Not everyone in tech is building web apps.
For more context, this tool can generate an MCP Server from an OpenAPI/Swagger file that describes a REST API. This does not include SOAP APIs, GraphQL, or other APIs that use the HTTP protocol.
HTTP API is the correct phrase.
So far, I've mostly seen proof-of-concept applications that might qualify as decent game jam entries - contexts where experimental implementation is expected ("jank allowed").
I'm curious about production applications: Has anyone developed robust, maintainable agent systems using this approach that didn't require significant refactoring or rewrites even?
What's been your experience with its viability in real-world environments beyond prototyping?
If agent systems allow teams to spin up and test prototypes faster than they previously could do without the agents, isn’t that a useful and valuable step in the right direction?
Addendum: After rereading my comment I realize it may come off as argumentative when it was intended to offer a perspective of not requiring more from the current state of the tech than it offers. “Early days” and all that :)
For tasks like that I personally use pre- and post-commit scripts to run all of my test validation, coverage, Ruff, etc. and output the results as “Current Code Quality” summary reports that are shared with my agents for context.
Have you personally deployed anything based on agent results (predominantly)? I'm just trying to gauge if the current state ("early days") is actually worth investing time and money in from a professional perspective.
In my experience, hype often precedes actual usefulness by a significant margin.
TL;DR are we there yet?
I put significant effort in constructing the product & project requirements beforehand and have built a number of simple tools as I ran into roadblocks or inefficiencies, so I can attest to there being a large amount of hype. I can also comfortably state that without the use of LLMs, I would not be this far along.
Having a background in software development (UX side) and a deep interest in technology gives me some insight in to which questions to ask and when to “throw a flag” and ask the LLM to explain why it’s doing something. I don’t believe the hype around one-shot enterprise applications, but the current state of AI programming is usable if people take the care they hopefully would with their own output.
(All three of those are terms with very vague definitions, I'm interested in hearing which of those definitions are starting to take root.)
Vibe Coding is an RECREATIONAL activity where a user and an AI collaborate on creation of some artifact AND the user accepts ALL feedback and suggestions from the AI.
We have .d.ts for machines (tsc), we have JSDoc & README.md for humans, can we get those LLMs to actually stick to those sources of truth, without having to do the work a third time (like llms.txt / cursor rules)?
But every-time I've tried to run DevDocs, I've had issues running it. Either the scraper or the MCP server fails to run.
What would be more helpful is an MCP that exposed devdocs.io or similar. Cache selected languages/framework documentation locally. Then expose an MCP server that searched the local files with some combination of vector/BM25 search. Expose that as a tool to the LLM.
MCP Isn’t the USB-C of AI — It’s Just a USB-Claude Dongle
https://dev.to/internationale/mcp-is-not-ai-usb-c-its-usb-cl...
Nonetheless, I think your work is very good and it looks like a very useful dongle
The protocol itself sits on top of JSON-RPC, and the specifications are there for anyone to implement. There's nothing specific to Claude about it.
There are various MCP client and server implementations available that are also unrelated to Anthropic.
- There is no clear explanation of the coupling between the system prompt and the tool call. Even if it mentions the open source Gemma or Deepseek, it would be much better.
The official attitude makes it difficult to trust this project.
The point you made is exactly the cunning part. Anyone can copy it, but without official support, it is simply impossible: this is pure community exploitation
For example, in Roo Code:
``` TOOL USE
You have access to a set of tools that are executed upon the user's approval. You can use one tool per message, and will receive the result of that tool use in the user's response. You use tools step-by-step to accomplish a given task, with each tool use informed by the result of the previous tool use.
# Tool Use Formatting
Tool use is formatted using XML-style tags. The tool name is enclosed in opening and closing tags, and each parameter is similarly enclosed within its own set of tags. Here's the structure:
<tool_name> <parameter1_name>value1</parameter1_name> <parameter2_name>value2</parameter2_name> ... </tool_name>
For example:
<read_file> <path>src/main.js</path> </read_file>
Always adhere to this format for the tool use to ensure proper parsing and execution. ```
let the LLMs read code.
LLMs have a limited context window. It’s can’t hold a full moderately sized project in context, let alone the code of the referenced libraries. Some tools have documentation that exceed the context window.
So I’ve found that adding documentation and adding that to the context helps significantly. I even often let the AI tools generate my documentation where possible (and then manually edit). For me and the tools I use, this has helped significantly.
Ooh, a binary puzzle—fun! Let’s decode it:
01111001 01100101 01110011
In binary, each byte (set of 8 digits) represents an ASCII character. Let's break it down:
01111001 = y
01100101 = e
01110011 = s
So, it spells out "yes"!
Got any more mysteries to solve?