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.
Yeah, this feels like one of those ‘explainers’ that feel like they are great to someone who already knows how the system works, but don’t actually work for newbies because they tacitly assume knowledge of the shape of the system that seems ‘obvious’ to someone steeped in it.
I agree - MCP just standardizes APIs to make it easier for LLM clients to consume them. Imagine if we had to use standard APIs - it would be more difficult to enable any single one. That’s why the labs instituted MCP.
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?
Last I checked it still doesn't. A skill that tells your client to call a CLI, and uses the help menus for progressive disclosure, benchmarks better. Developers noticed this immediately and there is sort of an anti-MCP sentiment. The protocol was probably largely conceived for non-coding agents run by non-coders.
In theory the agents could just natively know how to do this better, to get exactly the composability you want. In fact, you could probably just write a CLI mcp-caller and tell the agent to only call MCPs via that, and boom you're done.
Where MCP does come back into the picture even for coders is a more controlled way to break a sandbox.
What I will also say is it matters less and less. It's the usual bitter lesson. The models are just getting so much better all attempts to optimize everything are a drop in the bucket.
Yes, they are. Look into CodeMode (available in both Opencode and Pi). The agent has access to a code execution tool that can call and compose other tools/MCPs by writing code.
Yeah, the new Pi harness has codemode and I imagine there's many more.
Internally at my startup, I built an interpreter for a subset of Javascript where the agent can compose its tools and MCPs. The cool thing about it is that it can create durable workflows and automations from these same scripts.
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.
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.
Literally just give the link to Claude/GPT/etc. and it'll be able to replicate it easily. Hell, just loosely describe this as a text prompt and they'll probably nail it one shot. This is basically the "default" interactive explainer one-pager that all of these models generate.
I agree. MCPs have the massive problem of not being composable, which is a big strength of shells/CLIs allow.
People make the argument that it doesn't matter for non-programmers. I use Bluebeam (a pdf editor which is standard in the construction industry) daily, and it has an MCP, but a big problem is that if the agent wants to import or export a large amount of data from a document, then it has to regurgitate a bunch of tokens into or out of the MCP. If it were a CLI, then it would just pipe things in and out as it needs.
I ended up just having the agent make a script that wraps the MCP so it can use it as a CLI instead.
For coding agents I agree with you, but people are building for more than just developers now. The idea that a user facing service would give their agents shell access is kind of horrifying, as you then make it possible for prompt injection to mean a system take over.
MCP has its place. It should not be the default for many use cases, but if you need to expose specific tools in a secure way to agents that are not trusted to run shell commands then MCP is great. Developers need to think beyond their own use cases and consider architecture patterns if they're going to build, not just consume, AI systems.
100% agree. I've been building MCPs that enable Claude (my agent of choice to have voice conversations with). These hook into my home maintenance system (https://homemaintlist.com) and workout tracking system (https://tallyup.codewalkers.net) plus several private mcp servers I've made to expose Claude to specific services. These all allow me to just have conversations with Claude and have all these very specific things available and take action on them.
Excellent points. We still need to employ good cybersecurity principles when granting AI access to tools and resources. Let’s not throw out everything learned in the last three decades. Keep the access narrow in scope and targeted.
It just removes the need to install a cli tool on your local machine. I in general are sceptical before I install some external 3rd party software. With MCP over HTTP transport, the MCP might still talk to your agent and tell the agent to do XYZ, but your agent can still treat that command as malicious and refuse to execute. While not perfect, it is just another layer of security.
It is the same with a wepapp: You could argue you don't neex browser apps if the user just install a software on their computer, but we feel better using the sandboxing environment of your browser.
Depending on use case, would start with just solid HTTP APIs, then a simple CLI to consume them, then add MCP using the new spec. Build slowly only adding new access protocols as needed.
Be surprised how far apps can get with just solid & well documented APIs. Modern agents are smart!
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
Yep. This is what we get when people that didn't study UX and product development have access to AI. They have good ideas, ask AI to generate it and can't see that the result is unbearable.
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.
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.
It's literally JSON-RPC I'm not sure why you say it's a REST API. It's not even close to a REST API.
In this context/application I see a lot of similarities.
They both provide stateless RPC methods and human readable metadata that makes them easy to route.
You could ask why json-rpc was even necessary for 2.0. I think mostly just for stdio and backwards compatibility.
In the venn diagram of MCP and REST, there is an (optional) overlap for sure but one does not subsume the other.
Yeah, this feels like one of those ‘explainers’ that feel like they are great to someone who already knows how the system works, but don’t actually work for newbies because they tacitly assume knowledge of the shape of the system that seems ‘obvious’ to someone steeped in it.
To me the writing itself seems pretty economical.
From your comment, I expected to be annoyed by a bunch of slop or obscurities.
My guess is the writing did not come straight out of an LLM and was carefully curated.
If I’m wrong I’d love to have the style prompt.
The best thing about MCP is its almost impossible to use for most people except developers. Therefore ensuring our existence.
Don't believe me? Try connecting Blender to Codex.
MCP honestly seems like something thrown in there to keep devs relevant.
Just like us to take something and limit it back to being useless until we implement the feature (tools).
The real "race to market" winners will just throw the credentials into the SQL connector and let 'er rip like a real man.
I agree - MCP just standardizes APIs to make it easier for LLM clients to consume them. Imagine if we had to use standard APIs - it would be more difficult to enable any single one. That’s why the labs instituted MCP.
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?
Last I checked it still doesn't. A skill that tells your client to call a CLI, and uses the help menus for progressive disclosure, benchmarks better. Developers noticed this immediately and there is sort of an anti-MCP sentiment. The protocol was probably largely conceived for non-coding agents run by non-coders.
In theory the agents could just natively know how to do this better, to get exactly the composability you want. In fact, you could probably just write a CLI mcp-caller and tell the agent to only call MCPs via that, and boom you're done.
Where MCP does come back into the picture even for coders is a more controlled way to break a sandbox.
What I will also say is it matters less and less. It's the usual bitter lesson. The models are just getting so much better all attempts to optimize everything are a drop in the bucket.
Yes, they are. Look into CodeMode (available in both Opencode and Pi). The agent has access to a code execution tool that can call and compose other tools/MCPs by writing code.
Yeah, the new Pi harness has codemode and I imagine there's many more.
Internally at my startup, I built an interpreter for a subset of Javascript where the agent can compose its tools and MCPs. The cool thing about it is that it can create durable workflows and automations from these same scripts.
pi harness composes them just fine if you're specific about what you want to do.
"Find the latest prod JIRAs and analyze the related logs"
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.
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.
Literally just give the link to Claude/GPT/etc. and it'll be able to replicate it easily. Hell, just loosely describe this as a text prompt and they'll probably nail it one shot. This is basically the "default" interactive explainer one-pager that all of these models generate.
LOL, its early, if I'd thought for 5 seconds I would have realized that. thank you.
it's a single page html file, just download it and use as input for what you want to do
For me it's just:
from mcp.server.fastmcp import FastMCP
For me it’s just
“Claude add an mcp for this”
Horribly designed
Want to be more specific?
mcp's are barely needed, good cli's are usually better
I agree. MCPs have the massive problem of not being composable, which is a big strength of shells/CLIs allow.
People make the argument that it doesn't matter for non-programmers. I use Bluebeam (a pdf editor which is standard in the construction industry) daily, and it has an MCP, but a big problem is that if the agent wants to import or export a large amount of data from a document, then it has to regurgitate a bunch of tokens into or out of the MCP. If it were a CLI, then it would just pipe things in and out as it needs.
I ended up just having the agent make a script that wraps the MCP so it can use it as a CLI instead.
For coding agents I agree with you, but people are building for more than just developers now. The idea that a user facing service would give their agents shell access is kind of horrifying, as you then make it possible for prompt injection to mean a system take over.
MCP has its place. It should not be the default for many use cases, but if you need to expose specific tools in a secure way to agents that are not trusted to run shell commands then MCP is great. Developers need to think beyond their own use cases and consider architecture patterns if they're going to build, not just consume, AI systems.
100% agree. I've been building MCPs that enable Claude (my agent of choice to have voice conversations with). These hook into my home maintenance system (https://homemaintlist.com) and workout tracking system (https://tallyup.codewalkers.net) plus several private mcp servers I've made to expose Claude to specific services. These all allow me to just have conversations with Claude and have all these very specific things available and take action on them.
I do agree with you and was not aware of those reasons before, thanks for clarifying.
Excellent points. We still need to employ good cybersecurity principles when granting AI access to tools and resources. Let’s not throw out everything learned in the last three decades. Keep the access narrow in scope and targeted.
fwiw, I’ve only done cli tools for agents to install in their own sandboxes, not access on remote machines.
This was just to avoid MCP infra, but the newer stateless protocol makes that much more trivial.
It just removes the need to install a cli tool on your local machine. I in general are sceptical before I install some external 3rd party software. With MCP over HTTP transport, the MCP might still talk to your agent and tell the agent to do XYZ, but your agent can still treat that command as malicious and refuse to execute. While not perfect, it is just another layer of security.
It is the same with a wepapp: You could argue you don't neex browser apps if the user just install a software on their computer, but we feel better using the sandboxing environment of your browser.
Depending on use case, would start with just solid HTTP APIs, then a simple CLI to consume them, then add MCP using the new spec. Build slowly only adding new access protocols as needed.
Be surprised how far apps can get with just solid & well documented APIs. Modern agents are smart!
My suggestion is to just let the HTTP client itself be the MCP server.
Then you don't need an MCP server per service anymore, you just need one and a whitelist of authorized services.
not this tired discusssion again
[dead]
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
Yep. This is what we get when people that didn't study UX and product development have access to AI. They have good ideas, ask AI to generate it and can't see that the result is unbearable.
Everyday we get a new AI slop dashboard posted here
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.
My take away from this overview is that MCP is just a synonym for JSON RPC.
AI slop sorry
[dead]