This is too dense. You might as well just post some Python code with sufficient comments to get the same point across. I think a nicely written article with a few diagrams would go a long way. Sometimes less is more.
MCPs don't really need this level of technical explanations (it's basically just a REST API with standardized endpoints for discovery aimed at agents), and AI agents really do lack in the taste dimension when it comes to these things.
These vibe code explainers look nice on the surface but actually make things even more confusing. There's an element of curating which information to present and when that doesn't come across here.
The advantage of MCP is thin, and it only starts to show when it's really well integrated, and your company platform provider does the integration.
Otherwise it's a huge pain in the rear to keep your cli integrated with all the MCPs.
MCP is good for things you use literally 'all of the time' - or - it's seamlessly integrated into your system and you don't have to think about it.
Otherwise, just give your AI some instructions on the CLI.
I think that MCP may have been a mistake, and the local service aspect a distraction.
The 'enterprise integration' part may have best been articulated as a form of API standard and not associated with how it's integrated into 'tools' or anything else.
Are MCP calls composable in e.g. codex yet? e.g. can a model pipe a jira MCP call to grep or sed, or at least into a file? Last I looked at MCP it was just a vastly worse version of curl, .netrc, and some short text files describing calls (which are themselves greppable). Is there anything useful beyond that that I'm missing?
The interesting and necessary part of MCP is auth. A more useful explanation would cover a lot more of the "why", because looking at any thread mentioning MCP you'll see a ton of people saying "CLIs and traditional REST APIs do the same thing, why do we need yet another spec".
Sure now there are apps and tasks in the spec to handle specific usecases, but those can also be DIY'ed without the protocol and agents can still use them.
I couldn't find a github link, if anyone knows where to find the code for this, I'd like to modify it to make it a primer more friendly to non-technical managers.
Is it too much of an oversimplification to say "any new specialized tool or format that queries 'AI' with code is almost certainly pointless because you'll likely be able to match (and never exceed) that performance with an already known language, LLM query, or both?"
Daniel Miessler's fabric comes to mind. It's great, does a lot of great stuff, but requires literally nothing new, "code-wise"
I appreciate it, just started getting into 'vibe' coding converting some non arm (mac) apps into arm and it's pretty magical on this 128gb m5 max, a little slow but it can run deepseek flash 1017 pretty well.
Watched a few youtube apps about a 'harness' and I still haven't dived too deep into it but using openchamber to work with the code is awesome. Next step is MCP to various apps and seeing what it can do.
The site is beautifully made and I see a point but as many of others are also noticing, picking a beginner up, taking maybe 10 steps with him to introduce all of the concepts and terminology could be better for everyone to understand.
I've been thinking alot about developer education and while I think this format is fun to fiddle with, I feel this(and a lot of technical learning resources) are no longer as valuable as they would have been in a world without LLMS. Now if I wanna learn something I ask claude and I can essentially build my knowledge incrementally, have it build animations iteratively, ask questions and essentially derive an understanding.
Too dense. I’m not sure how this was outlined to the LLM but please first educate yourself on the basic principles of teaching, learning, and education. The AI that made this went off the rails and it is borderline incomprehensible.
The text doesn't even stay on screen for long enough for you to properly parse it and think it through. How do you think a beginner could ever use this?
Here's a more concise explainer that doesn't take a whole page.
Most language models can only generate content, like text or images, by default. For a model to perform actions, you need to give it tools. These tools are like functions: the model emits special markers signaling a tool call, which includes the name of the tool as well as parameters for the tool. Models can be instructed to do this, but many models are already trained to emit tool calls when tool definitions are provided.
These special markers around the tool call signal to a surrounding system, called a harness, that the model intends to call a tool. The harness, or the provider, will typically stop generation after collecting a tool call or multiple, execute the tool(s) with the specified parameters, and then restart generation with the results of the tool calls.
(The harness could be a desktop app, or a CLI like Claude Code. Sometimes even websites can offer to connect to hosted or even local MCP servers. Some providers like Anthropic also have a server-side harness, which performs server-side tool calls transparently, sending only the client-side tool calls down to be performed by the client-side harness.)
However, some users want models to be able to call tools that aren't built-in to the harness. This includes tools from third-party developers, as well as custom tools; anything the user wants the model to be able to do. MCP allows a harness to achieve this capability by connecting to an MCP server and exchanging messages to communicate tool calls and receive their results.
The harness can connect to the MCP server in one of two ways: using HTTP Server-Sent Events (legacy) or the newer "Streamable HTTP" to connect to an already-running server, or executing a command as a new subprocess and communicating by writing messages (JSON-RPC) to its stdin and reading responses from its stdout.
Once a connection is successful, the harness asks the server for tool definitions. These are JSON schemas, defining the shape and documentation of expected and allowed parameters for each tool the server offers. The harness can include these tool definitions when calling the model. The server can also provide documentation that applies to all tools, and which can also be included to the model.
When the model tries to call one of the server's tools by emitting a tool call, the harness sends the tool call and its parameters as a message to the server, which may perform the desired action before returning a response back to the harness. The harness then communicates this response to the model to continue the model's turn.
This omits some implementation details of precisely how protocols are implemented, because that knowledge is relevant only to the protocols themselves and not to MCP servers in specific. That is one distinction LLMs struggle to make in explainers. It assumes some basic familiarity with certain computing concepts like processes or stdio. In all cases, a search engine should help you study up on anything you might not understand yet.
MCP is a garbage standard the same way as LSP is. Inefficient crap designed by people who never knew anything other than back-and-forth JSON (de)serialization.
Anyone using MCP? Seems like it's a dead end compared to CLIs and normal APIs.
It's not like it really brings anything to the table that was missing or even needed.
I mentally group it with XML at this stage. Useless bloat peddled by people trying to sell something to people who don't really understand it much. Sort of thing I expect IBM to turn up and sell some Websphere Enterprise MCP Router Platform or something.
MCP is that kind of thing a manager comes up to you with and says "ARE WE USING MCP? it's the latest thing" and you roll your eyes, hunch over, stare at your screen and say to yourself "no, we're using strings, just strings." as you watch them drift to their next prey, you see scrawled up in their hands a note with crossed out acronyms. NFT. Web3. AMP. SOAP. IoT.
It's almost 2027 and I still dont understand if we actually need MCP. I must admit I am not really surfing the AI wave. But looks like a nothing burger.
This is noisy slop that doesn't explain anything. Maybe try starting with a definition and a single diagram?
I swear when I see stuff like this is makes me depressed about the future of our industry. Pick up an Edward Tufte book or something and use your brain
MCP Explained
(mcp-explained.com)328 points by rwilinski 5 November 2026 | 133 comments
Comments
MCPs don't really need this level of technical explanations (it's basically just a REST API with standardized endpoints for discovery aimed at agents), and AI agents really do lack in the taste dimension when it comes to these things.
Anything fleeting -> just use a skill.
The advantage of MCP is thin, and it only starts to show when it's really well integrated, and your company platform provider does the integration.
Otherwise it's a huge pain in the rear to keep your cli integrated with all the MCPs.
MCP is good for things you use literally 'all of the time' - or - it's seamlessly integrated into your system and you don't have to think about it.
Otherwise, just give your AI some instructions on the CLI.
I think that MCP may have been a mistake, and the local service aspect a distraction.
The 'enterprise integration' part may have best been articulated as a form of API standard and not associated with how it's integrated into 'tools' or anything else.
It was introduced too early.
Sure now there are apps and tasks in the spec to handle specific usecases, but those can also be DIY'ed without the protocol and agents can still use them.
Daniel Miessler's fabric comes to mind. It's great, does a lot of great stuff, but requires literally nothing new, "code-wise"
Watched a few youtube apps about a 'harness' and I still haven't dived too deep into it but using openchamber to work with the code is awesome. Next step is MCP to various apps and seeing what it can do.
Here's a more concise explainer that doesn't take a whole page.
Most language models can only generate content, like text or images, by default. For a model to perform actions, you need to give it tools. These tools are like functions: the model emits special markers signaling a tool call, which includes the name of the tool as well as parameters for the tool. Models can be instructed to do this, but many models are already trained to emit tool calls when tool definitions are provided.
These special markers around the tool call signal to a surrounding system, called a harness, that the model intends to call a tool. The harness, or the provider, will typically stop generation after collecting a tool call or multiple, execute the tool(s) with the specified parameters, and then restart generation with the results of the tool calls.
(The harness could be a desktop app, or a CLI like Claude Code. Sometimes even websites can offer to connect to hosted or even local MCP servers. Some providers like Anthropic also have a server-side harness, which performs server-side tool calls transparently, sending only the client-side tool calls down to be performed by the client-side harness.)
However, some users want models to be able to call tools that aren't built-in to the harness. This includes tools from third-party developers, as well as custom tools; anything the user wants the model to be able to do. MCP allows a harness to achieve this capability by connecting to an MCP server and exchanging messages to communicate tool calls and receive their results.
The harness can connect to the MCP server in one of two ways: using HTTP Server-Sent Events (legacy) or the newer "Streamable HTTP" to connect to an already-running server, or executing a command as a new subprocess and communicating by writing messages (JSON-RPC) to its stdin and reading responses from its stdout.
Once a connection is successful, the harness asks the server for tool definitions. These are JSON schemas, defining the shape and documentation of expected and allowed parameters for each tool the server offers. The harness can include these tool definitions when calling the model. The server can also provide documentation that applies to all tools, and which can also be included to the model.
When the model tries to call one of the server's tools by emitting a tool call, the harness sends the tool call and its parameters as a message to the server, which may perform the desired action before returning a response back to the harness. The harness then communicates this response to the model to continue the model's turn.
This omits some implementation details of precisely how protocols are implemented, because that knowledge is relevant only to the protocols themselves and not to MCP servers in specific. That is one distinction LLMs struggle to make in explainers. It assumes some basic familiarity with certain computing concepts like processes or stdio. In all cases, a search engine should help you study up on anything you might not understand yet.
Don't believe me? Try connecting Blender to Codex.
It's not like it really brings anything to the table that was missing or even needed.
I mentally group it with XML at this stage. Useless bloat peddled by people trying to sell something to people who don't really understand it much. Sort of thing I expect IBM to turn up and sell some Websphere Enterprise MCP Router Platform or something.
It will go the way of Openclaw, Personal Agents, Scaffolding, Skills and all these other things people prematurely tried to build around LLM models.
I swear when I see stuff like this is makes me depressed about the future of our industry. Pick up an Edward Tufte book or something and use your brain
from mcp.server.fastmcp import FastMCP