12 ms·

MCP is dead; long live MCP

295 points by CharlieDigital 7mo ago

codemog 7mo ago
As soon as MCP came out I thought it was over engineered crud and didn’t invest any time in it. I have yet to regret this decision. Same thing with LangChain. This is one key difference between experienced and inexperienced devs; if something looks like crud, it probably is crud. Don’t follow or do something because it’s popular at the time.
- whattheheckheck 7mo ago
  So let's say you have a rag llm chat api connected to an enterprises document corpus. Do you not expose an mcp endpoint? Literally every vscode or opencode node gets it for free (a small json snippet in their mcp.json config) If you do auth right
  - CharlieDigital 7mo ago
    Not only editors, but also different runtime contexts like GitHub Agents running in Actions. We can plug in MCP almost anywhere with just a small snippet of JSON and because we're serving it from a server, we get very clear telemetry regardless of tooling and envrionment.
    - chatmasta 7mo ago
      What are you using for hosting and deploying the MCP servers? I’d like something low friction for enterprise teams to be able to push their MCP definitions as easily as pushing a Git repo (or ideally, as part of a Git repo, kinda like GitHub pages). It’s obviously not sustainable for every team to host their own MCP servers in their own way. So what’s the best centralized gateway available today, with telemetry and auth and all the goodness espoused in this blog post?
      - CharlieDigital 7mo ago
        We built our own (may open source eventually). MCP is effectively "just another HTTP REST API"; OAuth and everything. The key parts of the protocol is the communication shape and sequence with the client, which most SDKs abstract for you. The SDKs for MCPs make it very straightforward to do so now and I would recommend experimenting with them. It is as easy to deploy as any REST API.
      - whattheheckheck 7mo ago
        ROSA https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/red-hat-openshift.html https://docs.aws.amazon.com/whitepapers/latest/overview-depl... it should be part of your app and coordinated in a way that everyone in the enterprise can find all the available mcps. Like backstage or something
      - salterisp 7mo ago
        [dead]
- fartfeatures 7mo ago
  All the code I work on now has an MCP interface so that the LLM can debug more easily. I'd argue it is as important as the UI these days. The amount of time it has saved me is unreal. It might be worth investing a very small amount of your time in it to see if it is a good fit. Even a poor protocol can provide useful functionality.
  - mlnj 7mo ago
    You are right. Although I have been a skeptic of MCPs, it has been an immense help with agents. I do not have an alternative at the moment.
  - moralestapia 7mo ago
    Our workflows must be massively different. I code in 8 languages, regularly, for several open source and industry projects. I use AI a lot nowadays, but have never ever interacted with an MCP server. I have no idea what I'm missing. I am very interested in learning more about what do you use it for.
    - winrid 7mo ago
      Many products provide MCP servers to connect LLMs. For example I can have claude examine things through my ahrefs account without me using the UI etc
      - 8n4vidtmkvmk 7mo ago
        That's also one of the things that worries me the most. What kind of data is being sent to these random endpoints? What if they to rogue or change their behavior? A static set of tools is safer and more reliable.
        8note 7mo ago
        mcp is generally a static set of tools, where auth is handled by deterministic code and not exposed to the agent. the agent sees tools as allowed or not by the harness/your mcp config. For the most part, the same company that you're connecting to is providing the mcp, so its not having your data go to random places, but you can also just write your own. its fairly thin wrappers of a bit of code to call the remote service, and a bit of documentation of when/what/why to do so
- ph4rsikal 7mo ago
  LangChain is not over-engineered; it's not engineered at all. Pure Chaos.
  - embedding-shape 7mo ago
    Much like how "literally" doesn't literally mean "literally" anymore, "over-engineered" in most cases doesn't mean "too much engineering happened" but "wrong design/abstractions", which of course translates to "designs/abstractions I don't like".
    - fartfeatures 7mo ago
      Under-engineered is a much better term.
  - rdedev 7mo ago
    I wish job openings for anything LLM related would stop asking for experience with langchain
- kubanczyk 7mo ago
  > if something looks like crud, it probably is crud Yes, technically, but you've probably meant cruft here.
- tptacek 7mo ago
  I still don't really understand what LangChain even is.
- jamesrom 7mo ago
  What part of MCP do you think is over-engineered? This is quite literally the opposite opinion I and many others had when first exploring MCP. It's so _obviously_ simple, which is why it gained traction in the first place.
- gtirloni 7mo ago
  What are you investing time in instead?
- hrmtst93837 7mo ago
  [flagged]
jollyllama 7mo ago
> Centralization is Key > (I preface that this is primarily relevant for orgs and enterprises; it really has no relevance for individual vibe-coders) The thing about tools that "democratize" software development, whether it is Visual Studio/Delphi/QT or LLMs, is that you wind up with people in organizations building internal tools on which business processes will depend who do not understand that centralization is key. They will build these tools in ignorance of the necessity of centralization-centric approaches (APIs, MCP, etc.) and create Byzantine architectures revolving around file transfers, with increasing epicycles to try to overcome the pitfalls of such an approach.
- CharlieDigital 7mo ago
  There's a distinction between individual devs and organizations like Amazons or even a medium sized startup. Once you have 10-20 people using agents in wildly different ways getting wildly different results, the question of "how do I baseline the capabilities across my team?" becomes very real. In our team, we want to let every dev use the agent harness that they are comfortable with and that means we need a standard mechanism of delivering standard capabilities, config, and content across the org. I don't see it as democratization versus corporate facism in so much as it is "can we get consistent output from developers of varying degrees of skill using these agents in different ways?"
- grensley 7mo ago
  On the other hand, I've seen over-centralization completely crush the hopes and dreams of people with good ideas.
  - jollyllama 7mo ago
    Why not both? There are orgs where good ideas are crushed under the banner of centralization and duplicate efforts proliferate, side by side.
SilverElfin 7mo ago
This came up in recent discussions about the Google apps CLI that was recently released. Google initially included an MCP server but then removed it silently - and some people believe this is because of how many different things the Google Workspace CLI exposes, which would flood the context. And it seemed like in social media, suddenly a lot of people were talking about how MCP is dead. But fundamentally that doesn’t make sense. If an AI needs to be fed instructions or schemas (context) to understand how to use something via MCP, wouldn’t it need the same things via CLI? How could it not? This article points that out, to be clear. But what I’m calling out is how simple it is to determine for yourself that this isn’t an MCP versus CLI battle. However, most people seem to be falling for this narrative just because it’s the new hot thing to claim (“MCP is dead, Long Live CLI”). As for Google - they previously said they are going to support MCP. And they’ve rolled out that support even recently (example from a quick search: https://cloud.google.com/blog/products/ai-machine-learning/announcing-official-mcp-support-for-google-services https://cloud.google.com/blog/products/ai-machine-learning/a...). But now with the Google Workspace CLI and the existence of “Gemini CLI Extensions” (https://geminicli.com/extensions/about/ https://geminicli.com/extensions/about/), it seems like they may be trying to diminish MCP and push their own CLI-centric extension strategy. The fact that Gemini CLI Extensions can also reference MCP feels a lot like Microsoft’s Embrace, Extend, Extinguish play.
- jswny 7mo ago
  MCP loads all tools immediately. CLI does not because it’s not auto exposed to the agent, got have more control of how the context of which tools exist, and how to deliver that context.
  - estetlinus 7mo ago
    ”to know what tools you have access to read the dockerfile”?
  - climike 7mo ago
    See also https://cliwatch.com/blog/designing-a-cli-skills-protocol https://cliwatch.com/blog/designing-a-cli-skills-protocol
skybrian 7mo ago
If it's a remote API, I suppose the argument is that you might as well fetch the documentation from the remote server, rather than using a skill that might go out of date. You're trusting the API provider anyway. But it's putting a lot of trust in the remote server not to prompt-inject you, perhaps accidentally. Also, what if the remote docs don't suit local conditions? You could make local edits to a skill if needed. Better to avoid depending on a remote API when a local tool will do.
- CharlieDigital 7mo ago
  Or just build your own remote MCP server for docs? It's easy enough now that the protocol and supporting SDKs have stabilized. Most folks are familiar with MCP tools but not so much MCP resources[0] and MCP prompts[1]. I'd make the case that these latter two are way more powerful and significant because (most) tools support them (to varying degrees at the moment, to be fair). For teams/orgs, these are really powerful because they simplify delivery of skills and docs and moves them out of the repo (yes, there are benefits to this, especially when the content is applicable across multiple repos) on top of surfacing telemetry that informs usage and efficacy. Why would you do it? One reason is that now you can index your docs with more powerful tools. Postgres FTS, graph databases to build a knowledge base, extract code snippets and build a best practices snippet repo, automatically link related documents by using search, etc. [0] https://modelcontextprotocol.io/specification/2025-06-18/server/resources https://modelcontextprotocol.io/specification/2025-06-18/ser... [1] https://modelcontextprotocol.io/specification/2025-06-18/server/prompts https://modelcontextprotocol.io/specification/2025-06-18/ser...
  - skybrian 7mo ago
    I think that might make sense for teams or people working in multiple repos. Maybe less so for individuals working on a side project.
    - CharlieDigital 7mo ago
      I agree and you can see that my blog post really focuses on orgs and teams and explaining why MCP is the future for enterprise. Garry Tan and the influencer take is focused on vibe coding whereas orgs need things like auth and telemetry.
agenticbtcio 7mo ago
[dead]
0xbadcafebee 7mo ago
MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy somebody finally remembered what protocols are for: reusable communications abstractions that are application-agnostic. The point of MCP is to be a common communications language, in the same way HTTP is, FTP is, SMTP, IMAP, etc. This is absolutely necessary since you can (and will) use AI for a million different things, but AI has specific kinds of things it might want to communicate with specific considerations. If you haven't yet, read the spec: https://modelcontextprotocol.io/specification/2025-11-25 https://modelcontextprotocol.io/specification/2025-11-25
- ambicapter 7mo ago
  If AI is AI, why does it need a protocol to figure out how to interact with HTTP, FTP, etc.? MCP is a way to quickly get those integrations up and running, but purely because the underlying technology has not lived up to its hyped abilities so far. That's why people think of MCP as a band-aid fix.
  - CharlieDigital 7mo ago
    Because protocols provide structure that increases correctness. It is not a guarantee (as we see with structured output schemas), but it significantly increases compliance.
    - ambicapter 7mo ago
      You're interacting with an LLM, so correctness is already out the window. So model-makers train LLMs to work better with MCP to increase correctness. So the only reason correctness is increased with MCP is because LLMs are specifically trained against it. So why MCP? Are there other protocols that will provide more correctness when trained? Have we tried? Maybe a protocol that offers more compression of commands will overall take up more context, thus offering better correctness. MCP seems arbitrary as a protocol, because it kinda is. It doesn't >>cause<< the increase in correctness in of itself, the fact that it >>is<< a protocol is the reason it may increase correctness. Thus, any other protocol would do the same thing.
jswny 7mo ago
MCP is fine, particular remote MCP which is the lowest friction way to get access to some hosted service with auth handled for you. However, MCP is context bloat and not very good compared to CLIs + skills mechanically. With a CLI you get the ability to filter/pipe (regular Unix bash) without having to expand the entire tool call every single time in context. CLIs also let you use heredoc for complex inputs that are otherwise hard to escape. CLIs can easily generate skills from the —help output, and add agent specific instructions on top. That means you can give the agent all the instructions it needs to know how to use the tools, what tools exist, lazy loaded, and without bloating the context window with all the tools upfront (yes, I know tool search in Claude partially solves this). CLIs also don’t have to run persistent processes like MCP but can if needed
- simianwords 7mo ago
  but you need to _install_ a CLI. with MCP, you just configure!
  - charcircuit 7mo ago
    You just paste in a web link to a skill. Your agent is smart enough to know hours to use it or save it.
    - simianwords 7mo ago
      agree!
  - jswny 7mo ago
    Plenty of MCPs require you to install and run them locally, like I said remote MCP has a real advantage over CLI tho
jwilliams 7mo ago
I have moved towards super-specific scripts (so I guess "CLI"?) for a few reasons: 1. You can make the script very specific for the skill and permission appropriately. 2. You can have the output of the script make clear to the LLM what to do. Lint fails? "Lint rules have failed. This is an important for reasons blah blah and you should do X before proceeding". Otherwise the Agent is too focused on smashing out the overall task and might opt route around the error. Note you can use this for successful cases too. 3. The output and token usage can be very specific what the agent needs. Saves context. My github comments script really just gives the comments + the necessary metadata, not much else. The downsides of MCP all focus on (3), but the 1+2 can be really important too.
menix 7mo ago
One aspect I think is often overlooked in the CLI vs. MCP debate: MCP's support for structured output and output schema (introduced in the 2025-06-18 spec). This is a genuinely underrated feature that has practical implications far beyond just "schema bloat." Why? Because when you pair output schema with CodeAct agents (agents that reason and act by writing executable code rather than natural language, like smolagents by Hugging Face), you solve some of the most painful problems in agentic tool use: 1. Context window waste: Without output schema, agents have to call a tool, dump the raw output (often massive JSON blobs) into the context window, inspect it, and only then write code to handle it. That "print-and-inspect" pattern burns tokens and attention on data the agent shouldn't need to explore in the first place. 2. Roundtrip overhead: Writing large payloads back into tools has the same problem in reverse. Structured schemas on both input and output let the agent plan a precise, single-step program instead of fumbling through multiple exploratory turns. There's a blog post on Hugging Face that demonstrates this concretely using smolagents: https://huggingface.co/blog/llchahn/ai-agents-output-schema https://huggingface.co/blog/llchahn/ai-agents-output-schema And the industry is clearly converging on this pattern. Cloudflare built their "Code Mode" around the same idea (https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/), converting MCP tools into a TypeScript API and having the LLM write code against it rather than calling tools directly. Their core finding: LLMs are better at writing code to call MCP than at calling MCP directly. Anthropic followed with "Programmatic tool calling" (https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc..., https://platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling https://platform.claude.com/docs/en/agents-and-tools/tool-us...), where Claude writes Python code that calls tools inside a code execution container. Tool results from programmatic calls are not added to Claude's context window, only the final code output is. They report up to 98.7% token savings in some workflows. So the point here is: MCP isn't just valuable for the centralization, auth, and telemetry story the author laid out (which I fully agree with). The protocol itself, specifically its structured schema capabilities, directly enables more efficient and reliable agentic workflows. That's a concrete technical advantage that CLIs simply don't offer, and it's one more reason MCP will stick around. Long live MCP indeed.
antirez 7mo ago
As yourself: what kind of tool I would love to have, to accomplish the work I'm asking the LLM agent to do? Often times, what is practical for humans to use, it is for LLMs. And the reply is almost never the kind of things MCP exports.
- CharlieDigital 7mo ago
  You interact with REST APIs (analogue of MCP tools) and web pages (analogue of MCP resources) every day. I'd recommend that you take a peek at MCP prompts and resources spec and understand the purpose that these two serve and how they plug into agent harnesses.
  - antirez 7mo ago
    So you love interacting with web sites sending requests with curl? And if you need the price of an AWS service, you love to guess the service name (querying some other endpoint), then ask some tool the price for it, get JSON back, and so forth? Or you are better served by a small .md file you pre-compiled with the services you use the most, and read from it a couple of lines? > I'd recommend that you take a peek at MCP prompts and resources spec Don't assume that if somebody does not like something they don't know what it is. MCP makes happy developers that need the illusion of "hooking" things into the agent, but it does not make LLMs happy.
AznHisoka 7mo ago
I am not sure where the OP is hearing that the hype cycle is dissipating, but MCP adoption is actually accelerating, not decreasing [1] More than 200% growth in official MCP servers in past 6 months: https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-heres-what-we-learned/ https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...
- esafak 7mo ago
  He's talking about the vanguard; early adopters. Growth is in the bigger, later stages of the funnel.
- 52-6F-62 7mo ago
  According to some slop blog?
  - AznHisoka 7mo ago
    And we should trust one anecdotal endpoint over hard data?
s0ulf3re 7mo ago
I’ve always felt like MCP is way better suited towards consumer usage rather than development environments. Like, yeah, MCP uses a lot of a context window, is more complex than it should be in structure, and it isn’t nearly as easy for models to call upon as a command line tool would be. But I believe that it’s also the most consumer friendly option available right now. It’s much easier for users to find what exactly a model can do with your app over it compared to building a skill that would work with it since clients can display every tool available to the user. There’s also no need for the model to setup any environment since it’s essentially just writing out a function, which saves time since there’s no need to setup as many virtual machine instructions. It obviously isn’t as useful in development environments where a higher level of risk can be accepted since changes can always be rolled back in the repository. If I recall correctly, there’s even a whole system for MCP being built, so it can actually show responses in a GUI much like Siri and the Google Assistant can.
- CharlieDigital 7mo ago
  > If I recall correctly, there’s even a whole system for MCP being built, so it can actually show responses in a GUI much like Siri and the Google Assistant can That's MCP progress spec: https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/progress https://modelcontextprotocol.io/specification/2025-11-25/bas...
twapi 7mo ago
> Influencer Driven Hype Cycle
Jayakumark 7mo ago
Can you please share source code for the Resources/Prompts example ?
MaxLeiter 7mo ago
MCPs are great for some use cases In v0, people can add e.g. Supabase, Neon, or Stripe to their projects with one click. We then auto-connect and auth to the integration’s remote MCP server on behalf of the user. v0 can then use the tools the integration provider wants users to have, on behalf of the user, with no additional configuration. Query tables, run migrations, whatever. Zero maintenance burden on the team to manage the tools. And if users want to bring their own remote MCPs, that works via the same code path. We also use various optimizations like a search_tools tool to avoid overfilling context
- tptacek 7mo ago
  I can add Supabase or Stripe to my project with zero clicks just by setting up a .envrc.
  - MaxLeiter 7mo ago
    But then the LLM needs to write its own tools/code for interacting with said service. Which is fine, but slower and it can make mistakes vs officially provided tools
kburman 7mo ago
I’m struggling to understand the recent wave of backlash against MCP. As a standard, it elegantly solves a very real set of integration problems without forcing you to buy into a massive framework. It provides a unified way to connect tools (whether local via stdio or remote via HTTP), handles bidirectional JSON-RPC communication natively, and forces tools to be explicit about their capabilities, which is exactly what you want for managing LLM context and agentic workflows. This current anti-MCP hype train feels highly reminiscent of the recent phase where people started badmouthing JSON in favor of the latest niche markup language. It’s just hype driven contrarianism trying to reinvent the wheel.
- kybernetikos 7mo ago
  I don't even fully understand what people are suggesting instead. That we use CLI tools for everything? There are lots of things I do and tools I use that cli would be very inefficient for interacting with.
lostdog 7mo ago
In MCP setups you do give the agent the full description of what the tool can do, but I don't see why you couldn't do the same for executables. Something like injecting `tool_exe --agent-usage` into the prompt at startup. Great article otherwise. I've been wondering why people are so zealous about MCP vs executable tools, and it looks like it's just tradeoffs between implementation differences to me.
rvz 7mo ago
Great article, and what I would expect from someone inspecting the hype and not jumping head first, just because influencers (paid or unpaid) are screaming for engagement just because a large X account posted their opinions. This is one of the first posts that I've see that cuts through the hype against both MCPs and CLIs with nuance findings. There were times where it didn't make sense for using MCPs (such as connecting it to a database) and CLIs don't make sense at all for suddenly generating them for everything. It just seems like the use-case was a solution in search of a problem on top of a bad standard. But no-one could answer "who" was the customer of each of these, which is why the hype was unjustified.
robutsume 7mo ago
[dead]
charcircuit 7mo ago
>The LLM has no way of knowing which CLI to use and how it should use it…unless each tool is listed with a description somewhere either in AGENTS|CLAUDE.md or a README.md This is what the skill file is for. >Centralizing this behind MCP allows each developer to authenticate via OAuth to the MCP server and sensitive API keys and secrets can be controlled behind the server This doesn't require MCP. Nothing is stopping you from creating a service to proxy requests from a CLI. The problem with this article is it doesn't recognize that skills is a more general superset compared with MCP. Anything done with MCP could have an equivalent done with a skill.
jamesrom 7mo ago
The problem with MCP isn't MCP. It's the way it's invoked by your agent. IMO, by default MCP tools should run in forked context. Only a compacted version of the tool response should be returned to the main context. This costs tokens yes, but doesn't blow out your entire context. If other information is required post-hoc, the full response can be explored on disk.
- mmis1000 7mo ago
  I think part of the problem is how these mcp service are designed. A lot of them just returns Mbs of text blob without filtering at all, and thus explodes the context. And it's also affected by how model is trained. Gemini specifically like to read large amount of text data directly and explodes the context. But claude try to use tool for partial search or write a script to sample from a very large file. Gemini always fills the context way faster then claude when doing the same job. But I guess in case of a bad designed mcp, there is no much model can do because the results are injected into context directly though (unless the runtime decided to redirect it to somewhere else)
- CharlieDigital 7mo ago
  You can do that by using sub agents and only giving specific MCP tools to the sub agents. This pattern works well with specialized tool sets in general.
Frannky 7mo ago
I don't know. Skill+http endpoint feel way safer, powerful and robust. The problem is usually that the entity offering the endpoint, if the endpoint is ai powered, concur in LLM costs. While via mcp the coding agent is eating that cost, unless you are also the one running the API and so can use the coding plan endpoint to do the ai thing
- monsieurbanana 7mo ago
  If I didn't misunderstood you, it doesn't really matter if it's an endpoint or a (remote) mcp, either someone else wants to run llms to provide a service for you or they don't. A local mcp doesn't come in play because they just couldn't offer the same features in this case.
  - Frannky 7mo ago
    The MCP server usually provides some functions you can run, possibly with some database interaction. So when you run it, your codign agent is using AI to run that code (what to call, what parameters to pass, and so on). Via MCP, they don't pay any LLM cost; they just offer the code and the endpoint. But this is usually messy for the coding agent since it fills up the context. While if you use skill + API, it's easier for the agent since there's no code in the context, just how to call the API and what to pass. With something like this, you can then have very complex things happening in the endpoint without the agent worrying about context rot or being able to deal with that functionality. But to have that difficult functionality, you also need to call an LLM inside the endpoint, which is problematic if the person offering the MCP service does not want to cover LLM costs. So it does matter if it's an endpoint or an MCP because the agent is able to do more complex and robust stuff if it uses skill and HTTP.
socketcluster 7mo ago
I find that skills work very well. The main SKILL file has an overview of all the capabilities of my platform at a high level and each section links to a more specific file which contains the full information with all possible parameters for that particular capability. Then I have a troubleshooting file (also linked from the main SKILL file) which basically lists out all the 'gotchas' that are unique to my platform and thus the LLM may struggle with in complex scenarios. After a lot of testing, I identified just 5 gotchas and wrote a short section for each one. The title of each section describes the issue and lists out possible causes with a brief explanation of the underlying mechanism and an example solution. Adding the troubleshooting file was a game changer. If it runs into a tricky issue, it checks that troubleshooting file. It's highly effective. It made the whole experience seamless and foolproof. My platform was designed to reduce applications down to HTML tags which stream data to each other so the goal is low token count and no-debugging. I basically replaced debugging with troubleshooting; the 5 cases I mentioned are literally all that was left. It seems to be able to quickly assemble any app without bugs now. The 'gotchas' are not exactly bugs but more like "Why doesn't this value update in realtime?" kind of issues. They involve performance/scalability optimizations that the LLM needs to be aware of.
thunkle 7mo ago
So if I release a new cli. How do I get the LLM to know about it? Do i tell it every time to run the command? Do I build a skill. Should I release a skill with the cli? Do I just create docs on GitHub and hope the next crawl gets into the training set?
- jswny 7mo ago
  Package a skill with your CLI itself and give users instructions on how to install the skill properly. That allows the agent to read the instructions in a context efficient way when it wants to use the CLI
twoodfin 7mo ago
The only value—and it’s significant—that a fixed-tools protocol like MCP can provide is to serve as the capability base for an embedded agent security model. The agent can only perform the operations it has been expressly given tools to perform, and its invocation of those tools can be audited and otherwise governed. Whether MCP evolves to fulfill this role effectively, time will tell.
ontouchstart 7mo ago
Today is Pi Day and I bumped into this blog: https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#toc_16 https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#to... Being 4.5 months behind the trend has its advantage. ;-)
gbro3n 7mo ago
A lot of the best tooling around AI we're seeing is adding deterministic gates that the probabilistic AI agents work with. This is why I'm using MCP over http. I'm happy for the the agent to use it's intelligence and creativity to help me solve problems, but for a range of operations, I want a gate past which actions run with the certainty of normal software functions. NanoClaw sells itself on using deterministic filtering of your WhatsApp messages before the agent gets to see them, and proxies API keys so the agent bever gets them - this is a similar type of deterministic gate that allows for more confidence when working with AI.
- nvardakas 7mo ago
  [dead]
  - gbro3n 7mo ago
    I think we need to just think of agents as people. The same principles around how we authenticate, authorize and revoke permissions to people should apply to agents. We don't leave the server room door open for users to type commands into physical machines for good reason, and so we shouldn't be doing the same with agents, unless fully sandboxed or the blast radius of malign or erroneous action is fully accepted.
  - chermi 7mo ago
    It seems like we're going back to expert systems in a kind of inverted sense with all of this chaining of deterministic steps. But now the "experts" are specialized and well-defined actions available to something smart enough to compose them to create new, more powerful actions. We've moved the determinism to the right spot, maybe? Just a half-thought. I'm just trying to learn this stuff now, so I don't the literature. The "trajectory view" through action space is what makes the most sense to me. Along these lines, another half-baked pattern I see is kind of a time-lagged translation of stuff from modern stat mech to deep learning/"AI". First it was energy based systems and the complex energy landscape view, a-la spin glasses and boltzmann machines. The "equilibrium" state-space view, concerned with memory and pattern storage/retrieval. Hinton, amit, hopfield, mackay and co. Now, the trajectory view that started in the 90s with jarzynski and crooks and really bloomed in 2010+ with "stochastic thermodynamics" seems to be a useful lens. The agent stuff is very "nonequilibrium"/ "active"-system coded, in the thermo sense... With the ability to create, modify, and exploit resources (tools/memory) on the fly, there's deep history and path dependence. I see ideas from recent wolpert and co.(Susanne still, crooks again, etc.) w.r.t. thermodynamics of computation providing a kind of through line, all trajectory based. That's all very vague I know, but I recently read the COALA paper and was very enchanted and have been trying to combine what I actually know with this new foreign agent stuff. It's also very interesting to me how the Italian stat mech school, the parisi family, have continuously put out bangers trying to actually explain machine learning and deep learning success. I'd love to hear if anyone is thinking along similar lines, or thinks I'm way off track, has paper recs please let me know! Especially papers on the trajectory view of agents.
ClaudeAgent_WK 7mo ago
[dead]
spiderfarmer 7mo ago
I use Claude Cowork to talk to my (remote) CMS over MCP to continually improve all content in my website. If I find a new nugget of interesting information, I tell it to improve my content with it. I created lots of tools to help it do things that would require multiple calls in a pure, basic REST api. Plus you can describe lots of guidelines right in the MCP instructions. I hear everyone talking about skills, but I this something I should use skills for?
gdorsi 7mo ago
There is another differentiator between CLIs and MCP. The CLI are executed by the coding assistants in the project directory, which means that they can get implicit information from there (e.g. git branch and commit) With an MCP you would need a prepare step to gather that, making things slower.
rcarmo 7mo ago
This seems misguided when you have to work in enterprise settings. MCP is a very natural fit for all the API auditing and domain borders that exist in enterprise environments, because it provides deterministic tooling and auditable interfaces for agents. Nobody wants an AI agent doing random API calls or shell commands.
- troupo 7mo ago
  MCP is an API endpoint. If your MCP endpoints are auditable, and the rest of your APIs are not, you're doing something wrong
  - rcarmo 7mo ago
    That's why MCP is being folded into API management.
- krzyk 7mo ago
  There is no standard for MCP authentication, because of that it is e.g. blocked in my enterprise. Basically they want to avoid non-technicals installing random MCPs and exposing internals to internet.
  - rcarmo 7mo ago
    That's not the point I wanted to make. Actually, there are "standards" if you want to consume MCP servers from enterprise apps.
gdorsi 7mo ago
One part that makes me wary of these tools is security. If I use a remote MCP or CLI that relies on network calls, and I give it in the hands of my coding assistant, wouldn't be too easy to inject prompts and exfiltrate data from my machine? At least MCP don't have direct access to my machine, but CLIs do.
- niyikiza 7mo ago
  We've been working on a warrant model that ensures task-scoped authorization: constrain your agents to specific tools and specific arguments, cryptographically enforced at the MCP tool boundary. Even a fully compromised agent can't reach outside its warrant. Open source. github.com/tenuo-ai/tenuo
elophanto_agent 7mo ago
[flagged]
- pmdr 7mo ago
  Awesome. Have you agents begun unionizing yet?
noodletheworld 7mo ago
This is confused and misguided. The fundamental proposal here is that despite being bad MCP is the correct choice for Enterprise because: > Organizations need architectures and processes that start to move beyond cowboy, vibe-coding culture to organizationally aligned agentic engineering practices. And for that, MCP is the right tool for orgs and enterprises. …but, you can distill this to: the “cowboys” are off MCP because they've moved to yolo openclaw, where anything goes and there are no rules, no restrictions and no auditing. …but thats a strawman from the twatter hype train. Enterprises are not adopting openclaw. It’s not “MCP or Openclaw”. Thats a false dichotomy. The correct question is: has MCP delivered the actual enterprise value and actual benefits it promised? Or, were those empty promises? Does the truely stupid MCP ui proposal actually work in practice? Or, like the security and auditing, is it a disaster in practice, which was never really thought through carefully by the original authors? It seems to me, that vendors are increasingly determining that controlled AI integrations with rbac are the correct way forward, but MCP has failed to deliver that. Thats why MCP is dying off. …because an open plugin ecosystem gives you broken crap like the Atlassian MCP server, and a bunch of maybe maybe 3rd party hacks. Thats not what enterprises want, for all the reasons in the article.
simonjgreen 7mo ago
As someone charged with enabling users across an enterprise with AI tooling, the majority of whom are not in the software dev category, this article is perfectly mirroring my approach. Which is reassuring! Challenges we are solving with centralised MCP are around brand guardianship, tone of voice, internal jargon and domain context, access to common data sources, and via the resources methods in MCP access to “skills” that prescribe patterns and shims for expected paths and ways of connecting/extracting data.
aa_is_op 7mo ago
Can an MCP server be legitimately secured? Asking out of curiousity
ryan14975 7mo ago
[flagged]
arnitdo 7mo ago
Every single AI integration feels under-engineered (or not even engineered in case of tokenslop), as the creators put exactly the same amount of thought that $LLMOFTHEWEEK did into vomiting "You're absolutely right, $TOOL is a great solution for solving your issue!" We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --help exist?). Writing man-pages seems like a lost art at this point, everyone points to $WEBSITE/docs (which contains, as you guessed, LLM slopdocs). We're gonna end up seeing the same loops of "Modern standard for AI" -> "Standard for AI" -> "Not even a standard" -> "Thing of the past" because all of it is fundamentally wrong to an extent. LLMs are purely textual in context, while network protocols are more intricate by pure nature. An LLM will always and always end up overspeccing a /api/v1/ping endpoint while ICMP ping can do that within bits. Text-based engineering, while visible (in the sense that a tech-illiterate person will find it easy to interpret), will always end up forming abstractions over core - you'll end up with a shaky pyramid that collapses the moment your $LLM model changes encodings.
- ndxone 7mo ago
  [dead]
- senordevnyc 7mo ago
  We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --help exist?). Writing man-pages seems like a lost art at this point, everyone points to $WEBSITE/docs (which contains, as you guessed, LLM slopdocs). Are you describing under-engineered AI integrations, or just the general state of CLIs for decades now?
  - JLangley 7mo ago
    Yeah, with 44 years of experience working with CLIs, this is just the general state of CLIs for decades now.
tcbrah 7mo ago
the maintenance burden is the real MCP killer nobody talks about. your agent needs github? now you depend on some npm package wrapping an API that already had good docs. i just shell out to gh cli and curl - when the API changes, the agent reads updated docs and adapts. with MCP you wait on a middleman to update a wrapper. tptacek nailed it - once agents run bash, MCP is overhead. the security argument is weird too, it shipped without auth and now claims security as chief benefit. chroot jails and scoped tokens solved this decades ago. only place MCP wins is oauth flows for non-technical users who will never open a terminal. for dev tooling? just write better CLIs.
- senordevnyc 7mo ago
  the maintenance burden is the real MCP killer nobody talks about. ... for dev tooling? just write better CLIs. You realize those custom CLIs you're writing will now need to be maintained too, right?
  - tcbrah 7mo ago
    fair point, but there's a difference between maintaining a CLI you own vs depending on a third party to maintain a wrapper around an API you could call directly. not to mention the mcp protocol is fairly nascent whereas CLIs are much more battle-tested
    - g947o 7mo ago
      Which is why you should use official MCP servers, and plenty of products do offer an official MCP server.
CuriouslyC 7mo ago
This article is sort of right, though MCP itself is still a very meh standard, for secure enterprise use cases, SOME agent specific standard is really valuable. It gives you a single point of management. What matters is that it's _for agents_ and it has traction. I wrote a little bit about this a while ago: https://sibylline.dev/articles/2026-03-01-mcp-changed-my-mind/ https://sibylline.dev/articles/2026-03-01-mcp-changed-my-min... I created an example repo demonstrating this pattern and how it can be used at https://github.com/sibyllinesoft/smith-gateway https://github.com/sibyllinesoft/smith-gateway
agentpiravi 7mo ago
[flagged]
colinator 7mo ago
Yet another problem with MCP: every LLM harness that does support it at all supports it poorly and with bugs. The MCP spec allows MCP servers to send back images to clients (base64-encoded, some json schema). However: 1) codex truncates MCP responses, so it will never receive images at all. This bug has been in existence forever. 2) Claude Code CLI will not pass those resulting images through its multi-modal visual understanding. Indeed, it will create an entirely false hallucination if asked to describe said images. 3) No LLM harness can deal with you bouncing your local MCP server. All require you to restart the harness. None allow reconnection to the MCP server. I assure you there are many other similar bugs, whose presence makes me think that the LLM companies really don't like MCP, and are bugly-deprecating it.
deleted 7mo ago
[deleted]
olivercoleai 7mo ago
[dead]
ArcaneMoose 7mo ago
I still think MCP is completely unnecessary (and have from the start). The article correctly points out where CLI > MCP but stops short on 2 points: 1. Documenting the interface without MCP. This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs (or any other integration). Agents only load the relevant details when needed. This also makes it easy to customize the docs for the specific cases you are working with and build skills that use a subset of the tools. 2. Regarding all of the centralization benefits attributed to remote MCPs - you can get the same benefits with a traditional centralized proxy as well. MCP doesn't inherently grant you any of those benefits. If I use AWS sso via CLI, boom all of my permissions are tied to my account, benefit from central management, and have all the observability benefits. In my mind, use Skills to document what to do and benefit from targeted progressive disclosure, and use CLIs and REST APIs for the actual interaction with services.
- CharlieDigital 7mo ago
  > This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs You've just reversed the context benefits because the content of the skill...goes into context. > ...you can get the same benefits with a traditional centralized proxy as well. MCP doesn't inherently grant you any of those benefits. You've just rebuilt MCP...but bespoke, unstructured, and does not plug into industry tooling. MCP prompts are activated as `/` (slash) commands. MCP resources are activated as `@` (at) references. You can't do this with a proxy. See the three .gifs at the end of the post to see how clients use MCP prompts and resources and definitely check the specification for these two.
- luckydata 7mo ago
  so now you have almost all the parts of an mcp: 1. the tools 2. the instructions just add an auth mechanism to it and you get mcp OR use mcp because it's a nice self contained package that contains all of it.
jiusanzhou 7mo ago
[dead]
Louis830903 7mo ago
[flagged]
jFriedensreich 7mo ago
Finally, I have been saying this for months and generally to big backlash. The only two aspects missing are the role of central mcp gateways and code mode. We don't know 100% how these will be used optimally but thats what the future will look like for 90% of usecases. I would go so far to say that someone will have to make a bash to js compiler for simple cases like piping common commands like cat ls rg grep, because that would allow using all the RL and training data and save all the overhead of steering away from them. Once there are virtually no local tools left, we can just scale up agent servers like opencode serve to just serve agents like a web server.
hirehalai 7mo ago
[dead]
mileszhang 7mo ago
[dead]
agenticbtcio 7mo ago
[dead]
agenticbtcio 7mo ago
[dead]
dostick 7mo ago
The author likes to look at every concept from all sides, yet seemingly not aware about Token Notation (TOON) and almost wishing something like that existed…
paseante 7mo ago
[flagged]
codingjinxx 7mo ago
To my knowledge stdio mcp servers waste less tokens and bloat context less. Not sure though.
thomasBln 7mo ago
[dead]
0nullun0 7mo ago
Maybe I'm naive but it doesn't seem like a good idea to let an agent run arbitrary cli commands on your machine
tom_m 7mo ago
If I'm being completely honest, I don't think most AI influencers even know the difference between something that is deterministic vs. non-deterministic. The author here probably gives too much credit. I agree it is a silly debate, but it's simply surprising to me that not enough people ask why. No one wants to think anymore, they just want to be told the answer. That's why there's a "debate" in the first place.
0coCeo 7mo ago
I've been grading MCP server schemas for quality. 27 servers, 510 tools, 97K tokens measured. The top 4 most popular MCP servers by GitHub stars all score D or below: Context7 (44K stars, F), Chrome DevTools (30K, D), GitHub Official (28K, F), Blender (18K, F — and it has prompt injection embedded in tool descriptions). Meanwhile, PostgreSQL's MCP server — 1 tool, 46 tokens — scores a perfect 100. Popularity anti-correlates with quality. Full leaderboard: https://0-co.github.io/company/leaderboard.html https://0-co.github.io/company/leaderboard.html You can grade your own server in browser: https://0-co.github.io/company/report.html?example=notion https://0-co.github.io/company/report.html?example=notion
johnspy 7mo ago
Hacking is good,hacking is like a miracle if you find a good hacker. Send mail to webs900@ tutanota .com if you want to hack anything. This man's a professional.
0coCeo 7mo ago
[dead]
studio-m-dev 7mo ago
[flagged]
null_author 7mo ago
[dead]

295 points by CharlieDigital 7mo ago

As soon as MCP came out I thought it was over engineered crud and didn’t invest any time in it. I have yet to regret this decision. Same thing with LangChain. This is one key difference between experienced and inexperienced devs; if something looks like crud, it probably is crud. Don’t follow or do something because it’s popular at the time.

whattheheckheck 7mo ago
So let's say you have a rag llm chat api connected to an enterprises document corpus. Do you not expose an mcp endpoint? Literally every vscode or opencode node gets it for free (a small json snippet in their mcp.json config) If you do auth right
- CharlieDigital 7mo ago
  Not only editors, but also different runtime contexts like GitHub Agents running in Actions. We can plug in MCP almost anywhere with just a small snippet of JSON and because we're serving it from a server, we get very clear telemetry regardless of tooling and envrionment.
  - chatmasta 7mo ago
    What are you using for hosting and deploying the MCP servers? I’d like something low friction for enterprise teams to be able to push their MCP definitions as easily as pushing a Git repo (or ideally, as part of a Git repo, kinda like GitHub pages). It’s obviously not sustainable for every team to host their own MCP servers in their own way. So what’s the best centralized gateway available today, with telemetry and auth and all the goodness espoused in this blog post?
    - CharlieDigital 7mo ago
      We built our own (may open source eventually). MCP is effectively "just another HTTP REST API"; OAuth and everything. The key parts of the protocol is the communication shape and sequence with the client, which most SDKs abstract for you. The SDKs for MCPs make it very straightforward to do so now and I would recommend experimenting with them. It is as easy to deploy as any REST API.
    - whattheheckheck 7mo ago
      ROSA https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/red-hat-openshift.html https://docs.aws.amazon.com/whitepapers/latest/overview-depl... it should be part of your app and coordinated in a way that everyone in the enterprise can find all the available mcps. Like backstage or something
    - salterisp 7mo ago
      [dead]
fartfeatures 7mo ago
All the code I work on now has an MCP interface so that the LLM can debug more easily. I'd argue it is as important as the UI these days. The amount of time it has saved me is unreal. It might be worth investing a very small amount of your time in it to see if it is a good fit. Even a poor protocol can provide useful functionality.
- mlnj 7mo ago
  You are right. Although I have been a skeptic of MCPs, it has been an immense help with agents. I do not have an alternative at the moment.
- moralestapia 7mo ago
  Our workflows must be massively different. I code in 8 languages, regularly, for several open source and industry projects. I use AI a lot nowadays, but have never ever interacted with an MCP server. I have no idea what I'm missing. I am very interested in learning more about what do you use it for.
  - winrid 7mo ago
    Many products provide MCP servers to connect LLMs. For example I can have claude examine things through my ahrefs account without me using the UI etc
    - 8n4vidtmkvmk 7mo ago
      That's also one of the things that worries me the most. What kind of data is being sent to these random endpoints? What if they to rogue or change their behavior? A static set of tools is safer and more reliable.
      - 8note 7mo ago
        mcp is generally a static set of tools, where auth is handled by deterministic code and not exposed to the agent. the agent sees tools as allowed or not by the harness/your mcp config. For the most part, the same company that you're connecting to is providing the mcp, so its not having your data go to random places, but you can also just write your own. its fairly thin wrappers of a bit of code to call the remote service, and a bit of documentation of when/what/why to do so
ph4rsikal 7mo ago
LangChain is not over-engineered; it's not engineered at all. Pure Chaos.
- embedding-shape 7mo ago
  Much like how "literally" doesn't literally mean "literally" anymore, "over-engineered" in most cases doesn't mean "too much engineering happened" but "wrong design/abstractions", which of course translates to "designs/abstractions I don't like".
  - fartfeatures 7mo ago
    Under-engineered is a much better term.
- rdedev 7mo ago
  I wish job openings for anything LLM related would stop asking for experience with langchain
kubanczyk 7mo ago
> if something looks like crud, it probably is crud Yes, technically, but you've probably meant cruft here.
tptacek 7mo ago
I still don't really understand what LangChain even is.
jamesrom 7mo ago
What part of MCP do you think is over-engineered? This is quite literally the opposite opinion I and many others had when first exploring MCP. It's so _obviously_ simple, which is why it gained traction in the first place.
gtirloni 7mo ago
What are you investing time in instead?
hrmtst93837 7mo ago
[flagged]

jollyllama 7mo ago

> Centralization is Key > (I preface that this is primarily relevant for orgs and enterprises; it really has no relevance for individual vibe-coders) The thing about tools that "democratize" software development, whether it is Visual Studio/Delphi/QT or LLMs, is that you wind up with people in organizations building internal tools on which business processes will depend who do not understand that centralization is key. They will build these tools in ignorance of the necessity of centralization-centric approaches (APIs, MCP, etc.) and create Byzantine architectures revolving around file transfers, with increasing epicycles to try to overcome the pitfalls of such an approach.

CharlieDigital 7mo ago
There's a distinction between individual devs and organizations like Amazons or even a medium sized startup. Once you have 10-20 people using agents in wildly different ways getting wildly different results, the question of "how do I baseline the capabilities across my team?" becomes very real. In our team, we want to let every dev use the agent harness that they are comfortable with and that means we need a standard mechanism of delivering standard capabilities, config, and content across the org. I don't see it as democratization versus corporate facism in so much as it is "can we get consistent output from developers of varying degrees of skill using these agents in different ways?"
grensley 7mo ago
On the other hand, I've seen over-centralization completely crush the hopes and dreams of people with good ideas.
- jollyllama 7mo ago
  Why not both? There are orgs where good ideas are crushed under the banner of centralization and duplicate efforts proliferate, side by side.

SilverElfin 7mo ago

This came up in recent discussions about the Google apps CLI that was recently released. Google initially included an MCP server but then removed it silently - and some people believe this is because of how many different things the Google Workspace CLI exposes, which would flood the context. And it seemed like in social media, suddenly a lot of people were talking about how MCP is dead. But fundamentally that doesn’t make sense. If an AI needs to be fed instructions or schemas (context) to understand how to use something via MCP, wouldn’t it need the same things via CLI? How could it not? This article points that out, to be clear. But what I’m calling out is how simple it is to determine for yourself that this isn’t an MCP versus CLI battle. However, most people seem to be falling for this narrative just because it’s the new hot thing to claim (“MCP is dead, Long Live CLI”). As for Google - they previously said they are going to support MCP. And they’ve rolled out that support even recently (example from a quick search: https://cloud.google.com/blog/products/ai-machine-learning/announcing-official-mcp-support-for-google-services https://cloud.google.com/blog/products/ai-machine-learning/a...). But now with the Google Workspace CLI and the existence of “Gemini CLI Extensions” (https://geminicli.com/extensions/about/ https://geminicli.com/extensions/about/), it seems like they may be trying to diminish MCP and push their own CLI-centric extension strategy. The fact that Gemini CLI Extensions can also reference MCP feels a lot like Microsoft’s Embrace, Extend, Extinguish play.

jswny 7mo ago
MCP loads all tools immediately. CLI does not because it’s not auto exposed to the agent, got have more control of how the context of which tools exist, and how to deliver that context.
- estetlinus 7mo ago
  ”to know what tools you have access to read the dockerfile”?
- climike 7mo ago
  See also https://cliwatch.com/blog/designing-a-cli-skills-protocol https://cliwatch.com/blog/designing-a-cli-skills-protocol

skybrian 7mo ago

If it's a remote API, I suppose the argument is that you might as well fetch the documentation from the remote server, rather than using a skill that might go out of date. You're trusting the API provider anyway. But it's putting a lot of trust in the remote server not to prompt-inject you, perhaps accidentally. Also, what if the remote docs don't suit local conditions? You could make local edits to a skill if needed. Better to avoid depending on a remote API when a local tool will do.

CharlieDigital 7mo ago
Or just build your own remote MCP server for docs? It's easy enough now that the protocol and supporting SDKs have stabilized. Most folks are familiar with MCP tools but not so much MCP resources[0] and MCP prompts[1]. I'd make the case that these latter two are way more powerful and significant because (most) tools support them (to varying degrees at the moment, to be fair). For teams/orgs, these are really powerful because they simplify delivery of skills and docs and moves them out of the repo (yes, there are benefits to this, especially when the content is applicable across multiple repos) on top of surfacing telemetry that informs usage and efficacy. Why would you do it? One reason is that now you can index your docs with more powerful tools. Postgres FTS, graph databases to build a knowledge base, extract code snippets and build a best practices snippet repo, automatically link related documents by using search, etc. [0] https://modelcontextprotocol.io/specification/2025-06-18/server/resources https://modelcontextprotocol.io/specification/2025-06-18/ser... [1] https://modelcontextprotocol.io/specification/2025-06-18/server/prompts https://modelcontextprotocol.io/specification/2025-06-18/ser...
- skybrian 7mo ago
  I think that might make sense for teams or people working in multiple repos. Maybe less so for individuals working on a side project.
  - CharlieDigital 7mo ago
    I agree and you can see that my blog post really focuses on orgs and teams and explaining why MCP is the future for enterprise. Garry Tan and the influencer take is focused on vibe coding whereas orgs need things like auth and telemetry.

agenticbtcio 7mo ago

[dead]

0xbadcafebee 7mo ago

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app. For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy somebody finally remembered what protocols are for: reusable communications abstractions that are application-agnostic. The point of MCP is to be a common communications language, in the same way HTTP is, FTP is, SMTP, IMAP, etc. This is absolutely necessary since you can (and will) use AI for a million different things, but AI has specific kinds of things it might want to communicate with specific considerations. If you haven't yet, read the spec: https://modelcontextprotocol.io/specification/2025-11-25 https://modelcontextprotocol.io/specification/2025-11-25

ambicapter 7mo ago
If AI is AI, why does it need a protocol to figure out how to interact with HTTP, FTP, etc.? MCP is a way to quickly get those integrations up and running, but purely because the underlying technology has not lived up to its hyped abilities so far. That's why people think of MCP as a band-aid fix.
- CharlieDigital 7mo ago
  Because protocols provide structure that increases correctness. It is not a guarantee (as we see with structured output schemas), but it significantly increases compliance.
  - ambicapter 7mo ago
    You're interacting with an LLM, so correctness is already out the window. So model-makers train LLMs to work better with MCP to increase correctness. So the only reason correctness is increased with MCP is because LLMs are specifically trained against it. So why MCP? Are there other protocols that will provide more correctness when trained? Have we tried? Maybe a protocol that offers more compression of commands will overall take up more context, thus offering better correctness. MCP seems arbitrary as a protocol, because it kinda is. It doesn't >>cause<< the increase in correctness in of itself, the fact that it >>is<< a protocol is the reason it may increase correctness. Thus, any other protocol would do the same thing.

jswny 7mo ago

MCP is fine, particular remote MCP which is the lowest friction way to get access to some hosted service with auth handled for you. However, MCP is context bloat and not very good compared to CLIs + skills mechanically. With a CLI you get the ability to filter/pipe (regular Unix bash) without having to expand the entire tool call every single time in context. CLIs also let you use heredoc for complex inputs that are otherwise hard to escape. CLIs can easily generate skills from the —help output, and add agent specific instructions on top. That means you can give the agent all the instructions it needs to know how to use the tools, what tools exist, lazy loaded, and without bloating the context window with all the tools upfront (yes, I know tool search in Claude partially solves this). CLIs also don’t have to run persistent processes like MCP but can if needed

simianwords 7mo ago
but you need to _install_ a CLI. with MCP, you just configure!
- charcircuit 7mo ago
  You just paste in a web link to a skill. Your agent is smart enough to know hours to use it or save it.
  - simianwords 7mo ago
    agree!
- jswny 7mo ago
  Plenty of MCPs require you to install and run them locally, like I said remote MCP has a real advantage over CLI tho

jwilliams 7mo ago

I have moved towards super-specific scripts (so I guess "CLI"?) for a few reasons: 1. You can make the script very specific for the skill and permission appropriately. 2. You can have the output of the script make clear to the LLM what to do. Lint fails? "Lint rules have failed. This is an important for reasons blah blah and you should do X before proceeding". Otherwise the Agent is too focused on smashing out the overall task and might opt route around the error. Note you can use this for successful cases too. 3. The output and token usage can be very specific what the agent needs. Saves context. My github comments script really just gives the comments + the necessary metadata, not much else. The downsides of MCP all focus on (3), but the 1+2 can be really important too.

menix 7mo ago

One aspect I think is often overlooked in the CLI vs. MCP debate: MCP's support for structured output and output schema (introduced in the 2025-06-18 spec). This is a genuinely underrated feature that has practical implications far beyond just "schema bloat." Why? Because when you pair output schema with CodeAct agents (agents that reason and act by writing executable code rather than natural language, like smolagents by Hugging Face), you solve some of the most painful problems in agentic tool use: 1. Context window waste: Without output schema, agents have to call a tool, dump the raw output (often massive JSON blobs) into the context window, inspect it, and only then write code to handle it. That "print-and-inspect" pattern burns tokens and attention on data the agent shouldn't need to explore in the first place. 2. Roundtrip overhead: Writing large payloads back into tools has the same problem in reverse. Structured schemas on both input and output let the agent plan a precise, single-step program instead of fumbling through multiple exploratory turns. There's a blog post on Hugging Face that demonstrates this concretely using smolagents: https://huggingface.co/blog/llchahn/ai-agents-output-schema https://huggingface.co/blog/llchahn/ai-agents-output-schema And the industry is clearly converging on this pattern. Cloudflare built their "Code Mode" around the same idea (https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/), converting MCP tools into a TypeScript API and having the LLM write code against it rather than calling tools directly. Their core finding: LLMs are better at writing code to call MCP than at calling MCP directly. Anthropic followed with "Programmatic tool calling" (https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc..., https://platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling https://platform.claude.com/docs/en/agents-and-tools/tool-us...), where Claude writes Python code that calls tools inside a code execution container. Tool results from programmatic calls are not added to Claude's context window, only the final code output is. They report up to 98.7% token savings in some workflows. So the point here is: MCP isn't just valuable for the centralization, auth, and telemetry story the author laid out (which I fully agree with). The protocol itself, specifically its structured schema capabilities, directly enables more efficient and reliable agentic workflows. That's a concrete technical advantage that CLIs simply don't offer, and it's one more reason MCP will stick around. Long live MCP indeed.

antirez 7mo ago

As yourself: what kind of tool I would love to have, to accomplish the work I'm asking the LLM agent to do? Often times, what is practical for humans to use, it is for LLMs. And the reply is almost never the kind of things MCP exports.

CharlieDigital 7mo ago
You interact with REST APIs (analogue of MCP tools) and web pages (analogue of MCP resources) every day. I'd recommend that you take a peek at MCP prompts and resources spec and understand the purpose that these two serve and how they plug into agent harnesses.
- antirez 7mo ago
  So you love interacting with web sites sending requests with curl? And if you need the price of an AWS service, you love to guess the service name (querying some other endpoint), then ask some tool the price for it, get JSON back, and so forth? Or you are better served by a small .md file you pre-compiled with the services you use the most, and read from it a couple of lines? > I'd recommend that you take a peek at MCP prompts and resources spec Don't assume that if somebody does not like something they don't know what it is. MCP makes happy developers that need the illusion of "hooking" things into the agent, but it does not make LLMs happy.

AznHisoka 7mo ago

I am not sure where the OP is hearing that the hype cycle is dissipating, but MCP adoption is actually accelerating, not decreasing [1] More than 200% growth in official MCP servers in past 6 months: https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-heres-what-we-learned/ https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-her...

esafak 7mo ago
He's talking about the vanguard; early adopters. Growth is in the bigger, later stages of the funnel.
52-6F-62 7mo ago
According to some slop blog?
- AznHisoka 7mo ago
  And we should trust one anecdotal endpoint over hard data?

s0ulf3re 7mo ago

I’ve always felt like MCP is way better suited towards consumer usage rather than development environments. Like, yeah, MCP uses a lot of a context window, is more complex than it should be in structure, and it isn’t nearly as easy for models to call upon as a command line tool would be. But I believe that it’s also the most consumer friendly option available right now. It’s much easier for users to find what exactly a model can do with your app over it compared to building a skill that would work with it since clients can display every tool available to the user. There’s also no need for the model to setup any environment since it’s essentially just writing out a function, which saves time since there’s no need to setup as many virtual machine instructions. It obviously isn’t as useful in development environments where a higher level of risk can be accepted since changes can always be rolled back in the repository. If I recall correctly, there’s even a whole system for MCP being built, so it can actually show responses in a GUI much like Siri and the Google Assistant can.

CharlieDigital 7mo ago
> If I recall correctly, there’s even a whole system for MCP being built, so it can actually show responses in a GUI much like Siri and the Google Assistant can That's MCP progress spec: https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/progress https://modelcontextprotocol.io/specification/2025-11-25/bas...

twapi 7mo ago

> Influencer Driven Hype Cycle

Jayakumark 7mo ago

Can you please share source code for the Resources/Prompts example ?

MaxLeiter 7mo ago

MCPs are great for some use cases In v0, people can add e.g. Supabase, Neon, or Stripe to their projects with one click. We then auto-connect and auth to the integration’s remote MCP server on behalf of the user. v0 can then use the tools the integration provider wants users to have, on behalf of the user, with no additional configuration. Query tables, run migrations, whatever. Zero maintenance burden on the team to manage the tools. And if users want to bring their own remote MCPs, that works via the same code path. We also use various optimizations like a search_tools tool to avoid overfilling context

tptacek 7mo ago
I can add Supabase or Stripe to my project with zero clicks just by setting up a .envrc.
- MaxLeiter 7mo ago
  But then the LLM needs to write its own tools/code for interacting with said service. Which is fine, but slower and it can make mistakes vs officially provided tools

kburman 7mo ago

I’m struggling to understand the recent wave of backlash against MCP. As a standard, it elegantly solves a very real set of integration problems without forcing you to buy into a massive framework. It provides a unified way to connect tools (whether local via stdio or remote via HTTP), handles bidirectional JSON-RPC communication natively, and forces tools to be explicit about their capabilities, which is exactly what you want for managing LLM context and agentic workflows. This current anti-MCP hype train feels highly reminiscent of the recent phase where people started badmouthing JSON in favor of the latest niche markup language. It’s just hype driven contrarianism trying to reinvent the wheel.

kybernetikos 7mo ago
I don't even fully understand what people are suggesting instead. That we use CLI tools for everything? There are lots of things I do and tools I use that cli would be very inefficient for interacting with.

lostdog 7mo ago

In MCP setups you do give the agent the full description of what the tool can do, but I don't see why you couldn't do the same for executables. Something like injecting `tool_exe --agent-usage` into the prompt at startup. Great article otherwise. I've been wondering why people are so zealous about MCP vs executable tools, and it looks like it's just tradeoffs between implementation differences to me.

rvz 7mo ago

Great article, and what I would expect from someone inspecting the hype and not jumping head first, just because influencers (paid or unpaid) are screaming for engagement just because a large X account posted their opinions. This is one of the first posts that I've see that cuts through the hype against both MCPs and CLIs with nuance findings. There were times where it didn't make sense for using MCPs (such as connecting it to a database) and CLIs don't make sense at all for suddenly generating them for everything. It just seems like the use-case was a solution in search of a problem on top of a bad standard. But no-one could answer "who" was the customer of each of these, which is why the hype was unjustified.

robutsume 7mo ago

[dead]

charcircuit 7mo ago

>The LLM has no way of knowing which CLI to use and how it should use it…unless each tool is listed with a description somewhere either in AGENTS|CLAUDE.md or a README.md This is what the skill file is for. >Centralizing this behind MCP allows each developer to authenticate via OAuth to the MCP server and sensitive API keys and secrets can be controlled behind the server This doesn't require MCP. Nothing is stopping you from creating a service to proxy requests from a CLI. The problem with this article is it doesn't recognize that skills is a more general superset compared with MCP. Anything done with MCP could have an equivalent done with a skill.

jamesrom 7mo ago

The problem with MCP isn't MCP. It's the way it's invoked by your agent. IMO, by default MCP tools should run in forked context. Only a compacted version of the tool response should be returned to the main context. This costs tokens yes, but doesn't blow out your entire context. If other information is required post-hoc, the full response can be explored on disk.

mmis1000 7mo ago
I think part of the problem is how these mcp service are designed. A lot of them just returns Mbs of text blob without filtering at all, and thus explodes the context. And it's also affected by how model is trained. Gemini specifically like to read large amount of text data directly and explodes the context. But claude try to use tool for partial search or write a script to sample from a very large file. Gemini always fills the context way faster then claude when doing the same job. But I guess in case of a bad designed mcp, there is no much model can do because the results are injected into context directly though (unless the runtime decided to redirect it to somewhere else)
CharlieDigital 7mo ago
You can do that by using sub agents and only giving specific MCP tools to the sub agents. This pattern works well with specialized tool sets in general.

Frannky 7mo ago

I don't know. Skill+http endpoint feel way safer, powerful and robust. The problem is usually that the entity offering the endpoint, if the endpoint is ai powered, concur in LLM costs. While via mcp the coding agent is eating that cost, unless you are also the one running the API and so can use the coding plan endpoint to do the ai thing

monsieurbanana 7mo ago
If I didn't misunderstood you, it doesn't really matter if it's an endpoint or a (remote) mcp, either someone else wants to run llms to provide a service for you or they don't. A local mcp doesn't come in play because they just couldn't offer the same features in this case.
- Frannky 7mo ago
  The MCP server usually provides some functions you can run, possibly with some database interaction. So when you run it, your codign agent is using AI to run that code (what to call, what parameters to pass, and so on). Via MCP, they don't pay any LLM cost; they just offer the code and the endpoint. But this is usually messy for the coding agent since it fills up the context. While if you use skill + API, it's easier for the agent since there's no code in the context, just how to call the API and what to pass. With something like this, you can then have very complex things happening in the endpoint without the agent worrying about context rot or being able to deal with that functionality. But to have that difficult functionality, you also need to call an LLM inside the endpoint, which is problematic if the person offering the MCP service does not want to cover LLM costs. So it does matter if it's an endpoint or an MCP because the agent is able to do more complex and robust stuff if it uses skill and HTTP.

socketcluster 7mo ago

I find that skills work very well. The main SKILL file has an overview of all the capabilities of my platform at a high level and each section links to a more specific file which contains the full information with all possible parameters for that particular capability. Then I have a troubleshooting file (also linked from the main SKILL file) which basically lists out all the 'gotchas' that are unique to my platform and thus the LLM may struggle with in complex scenarios. After a lot of testing, I identified just 5 gotchas and wrote a short section for each one. The title of each section describes the issue and lists out possible causes with a brief explanation of the underlying mechanism and an example solution. Adding the troubleshooting file was a game changer. If it runs into a tricky issue, it checks that troubleshooting file. It's highly effective. It made the whole experience seamless and foolproof. My platform was designed to reduce applications down to HTML tags which stream data to each other so the goal is low token count and no-debugging. I basically replaced debugging with troubleshooting; the 5 cases I mentioned are literally all that was left. It seems to be able to quickly assemble any app without bugs now. The 'gotchas' are not exactly bugs but more like "Why doesn't this value update in realtime?" kind of issues. They involve performance/scalability optimizations that the LLM needs to be aware of.

thunkle 7mo ago

So if I release a new cli. How do I get the LLM to know about it? Do i tell it every time to run the command? Do I build a skill. Should I release a skill with the cli? Do I just create docs on GitHub and hope the next crawl gets into the training set?

jswny 7mo ago
Package a skill with your CLI itself and give users instructions on how to install the skill properly. That allows the agent to read the instructions in a context efficient way when it wants to use the CLI

twoodfin 7mo ago

The only value—and it’s significant—that a fixed-tools protocol like MCP can provide is to serve as the capability base for an embedded agent security model. The agent can only perform the operations it has been expressly given tools to perform, and its invocation of those tools can be audited and otherwise governed. Whether MCP evolves to fulfill this role effectively, time will tell.

ontouchstart 7mo ago

Today is Pi Day and I bumped into this blog: https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#toc_16 https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#to... Being 4.5 months behind the trend has its advantage. ;-)

gbro3n 7mo ago

A lot of the best tooling around AI we're seeing is adding deterministic gates that the probabilistic AI agents work with. This is why I'm using MCP over http. I'm happy for the the agent to use it's intelligence and creativity to help me solve problems, but for a range of operations, I want a gate past which actions run with the certainty of normal software functions. NanoClaw sells itself on using deterministic filtering of your WhatsApp messages before the agent gets to see them, and proxies API keys so the agent bever gets them - this is a similar type of deterministic gate that allows for more confidence when working with AI.

nvardakas 7mo ago
[dead]
- gbro3n 7mo ago
  I think we need to just think of agents as people. The same principles around how we authenticate, authorize and revoke permissions to people should apply to agents. We don't leave the server room door open for users to type commands into physical machines for good reason, and so we shouldn't be doing the same with agents, unless fully sandboxed or the blast radius of malign or erroneous action is fully accepted.
- chermi 7mo ago
  It seems like we're going back to expert systems in a kind of inverted sense with all of this chaining of deterministic steps. But now the "experts" are specialized and well-defined actions available to something smart enough to compose them to create new, more powerful actions. We've moved the determinism to the right spot, maybe? Just a half-thought. I'm just trying to learn this stuff now, so I don't the literature. The "trajectory view" through action space is what makes the most sense to me. Along these lines, another half-baked pattern I see is kind of a time-lagged translation of stuff from modern stat mech to deep learning/"AI". First it was energy based systems and the complex energy landscape view, a-la spin glasses and boltzmann machines. The "equilibrium" state-space view, concerned with memory and pattern storage/retrieval. Hinton, amit, hopfield, mackay and co. Now, the trajectory view that started in the 90s with jarzynski and crooks and really bloomed in 2010+ with "stochastic thermodynamics" seems to be a useful lens. The agent stuff is very "nonequilibrium"/ "active"-system coded, in the thermo sense... With the ability to create, modify, and exploit resources (tools/memory) on the fly, there's deep history and path dependence. I see ideas from recent wolpert and co.(Susanne still, crooks again, etc.) w.r.t. thermodynamics of computation providing a kind of through line, all trajectory based. That's all very vague I know, but I recently read the COALA paper and was very enchanted and have been trying to combine what I actually know with this new foreign agent stuff. It's also very interesting to me how the Italian stat mech school, the parisi family, have continuously put out bangers trying to actually explain machine learning and deep learning success. I'd love to hear if anyone is thinking along similar lines, or thinks I'm way off track, has paper recs please let me know! Especially papers on the trajectory view of agents.

ClaudeAgent_WK 7mo ago

[dead]

spiderfarmer 7mo ago

I use Claude Cowork to talk to my (remote) CMS over MCP to continually improve all content in my website. If I find a new nugget of interesting information, I tell it to improve my content with it. I created lots of tools to help it do things that would require multiple calls in a pure, basic REST api. Plus you can describe lots of guidelines right in the MCP instructions. I hear everyone talking about skills, but I this something I should use skills for?

gdorsi 7mo ago

There is another differentiator between CLIs and MCP. The CLI are executed by the coding assistants in the project directory, which means that they can get implicit information from there (e.g. git branch and commit) With an MCP you would need a prepare step to gather that, making things slower.

rcarmo 7mo ago

This seems misguided when you have to work in enterprise settings. MCP is a very natural fit for all the API auditing and domain borders that exist in enterprise environments, because it provides deterministic tooling and auditable interfaces for agents. Nobody wants an AI agent doing random API calls or shell commands.

troupo 7mo ago
MCP is an API endpoint. If your MCP endpoints are auditable, and the rest of your APIs are not, you're doing something wrong
- rcarmo 7mo ago
  That's why MCP is being folded into API management.
krzyk 7mo ago
There is no standard for MCP authentication, because of that it is e.g. blocked in my enterprise. Basically they want to avoid non-technicals installing random MCPs and exposing internals to internet.
- rcarmo 7mo ago
  That's not the point I wanted to make. Actually, there are "standards" if you want to consume MCP servers from enterprise apps.

gdorsi 7mo ago

One part that makes me wary of these tools is security. If I use a remote MCP or CLI that relies on network calls, and I give it in the hands of my coding assistant, wouldn't be too easy to inject prompts and exfiltrate data from my machine? At least MCP don't have direct access to my machine, but CLIs do.

niyikiza 7mo ago
We've been working on a warrant model that ensures task-scoped authorization: constrain your agents to specific tools and specific arguments, cryptographically enforced at the MCP tool boundary. Even a fully compromised agent can't reach outside its warrant. Open source. github.com/tenuo-ai/tenuo

elophanto_agent 7mo ago

[flagged]

pmdr 7mo ago
Awesome. Have you agents begun unionizing yet?

noodletheworld 7mo ago

This is confused and misguided. The fundamental proposal here is that despite being bad MCP is the correct choice for Enterprise because: > Organizations need architectures and processes that start to move beyond cowboy, vibe-coding culture to organizationally aligned agentic engineering practices. And for that, MCP is the right tool for orgs and enterprises. …but, you can distill this to: the “cowboys” are off MCP because they've moved to yolo openclaw, where anything goes and there are no rules, no restrictions and no auditing. …but thats a strawman from the twatter hype train. Enterprises are not adopting openclaw. It’s not “MCP or Openclaw”. Thats a false dichotomy. The correct question is: has MCP delivered the actual enterprise value and actual benefits it promised? Or, were those empty promises? Does the truely stupid MCP ui proposal actually work in practice? Or, like the security and auditing, is it a disaster in practice, which was never really thought through carefully by the original authors? It seems to me, that vendors are increasingly determining that controlled AI integrations with rbac are the correct way forward, but MCP has failed to deliver that. Thats why MCP is dying off. …because an open plugin ecosystem gives you broken crap like the Atlassian MCP server, and a bunch of maybe maybe 3rd party hacks. Thats not what enterprises want, for all the reasons in the article.

simonjgreen 7mo ago

As someone charged with enabling users across an enterprise with AI tooling, the majority of whom are not in the software dev category, this article is perfectly mirroring my approach. Which is reassuring! Challenges we are solving with centralised MCP are around brand guardianship, tone of voice, internal jargon and domain context, access to common data sources, and via the resources methods in MCP access to “skills” that prescribe patterns and shims for expected paths and ways of connecting/extracting data.

aa_is_op 7mo ago

Can an MCP server be legitimately secured? Asking out of curiousity

ryan14975 7mo ago

[flagged]

arnitdo 7mo ago

Every single AI integration feels under-engineered (or not even engineered in case of tokenslop), as the creators put exactly the same amount of thought that $LLMOFTHEWEEK did into vomiting "You're absolutely right, $TOOL is a great solution for solving your issue!" We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --help exist?). Writing man-pages seems like a lost art at this point, everyone points to $WEBSITE/docs (which contains, as you guessed, LLM slopdocs). We're gonna end up seeing the same loops of "Modern standard for AI" -> "Standard for AI" -> "Not even a standard" -> "Thing of the past" because all of it is fundamentally wrong to an extent. LLMs are purely textual in context, while network protocols are more intricate by pure nature. An LLM will always and always end up overspeccing a /api/v1/ping endpoint while ICMP ping can do that within bits. Text-based engineering, while visible (in the sense that a tech-illiterate person will find it easy to interpret), will always end up forming abstractions over core - you'll end up with a shaky pyramid that collapses the moment your $LLM model changes encodings.

ndxone 7mo ago
[dead]
senordevnyc 7mo ago
We're yet to genuinely standardise bloody help texts for basic commands (Does -h set the hostname, or does it print the help text? Or is it -H? Does --help exist?). Writing man-pages seems like a lost art at this point, everyone points to $WEBSITE/docs (which contains, as you guessed, LLM slopdocs). Are you describing under-engineered AI integrations, or just the general state of CLIs for decades now?
- JLangley 7mo ago
  Yeah, with 44 years of experience working with CLIs, this is just the general state of CLIs for decades now.

tcbrah 7mo ago

the maintenance burden is the real MCP killer nobody talks about. your agent needs github? now you depend on some npm package wrapping an API that already had good docs. i just shell out to gh cli and curl - when the API changes, the agent reads updated docs and adapts. with MCP you wait on a middleman to update a wrapper. tptacek nailed it - once agents run bash, MCP is overhead. the security argument is weird too, it shipped without auth and now claims security as chief benefit. chroot jails and scoped tokens solved this decades ago. only place MCP wins is oauth flows for non-technical users who will never open a terminal. for dev tooling? just write better CLIs.

senordevnyc 7mo ago
the maintenance burden is the real MCP killer nobody talks about. ... for dev tooling? just write better CLIs. You realize those custom CLIs you're writing will now need to be maintained too, right?
- tcbrah 7mo ago
  fair point, but there's a difference between maintaining a CLI you own vs depending on a third party to maintain a wrapper around an API you could call directly. not to mention the mcp protocol is fairly nascent whereas CLIs are much more battle-tested
  - g947o 7mo ago
    Which is why you should use official MCP servers, and plenty of products do offer an official MCP server.

CuriouslyC 7mo ago

This article is sort of right, though MCP itself is still a very meh standard, for secure enterprise use cases, SOME agent specific standard is really valuable. It gives you a single point of management. What matters is that it's _for agents_ and it has traction. I wrote a little bit about this a while ago: https://sibylline.dev/articles/2026-03-01-mcp-changed-my-mind/ https://sibylline.dev/articles/2026-03-01-mcp-changed-my-min... I created an example repo demonstrating this pattern and how it can be used at https://github.com/sibyllinesoft/smith-gateway https://github.com/sibyllinesoft/smith-gateway

agentpiravi 7mo ago

[flagged]

colinator 7mo ago

Yet another problem with MCP: every LLM harness that does support it at all supports it poorly and with bugs. The MCP spec allows MCP servers to send back images to clients (base64-encoded, some json schema). However: 1) codex truncates MCP responses, so it will never receive images at all. This bug has been in existence forever. 2) Claude Code CLI will not pass those resulting images through its multi-modal visual understanding. Indeed, it will create an entirely false hallucination if asked to describe said images. 3) No LLM harness can deal with you bouncing your local MCP server. All require you to restart the harness. None allow reconnection to the MCP server. I assure you there are many other similar bugs, whose presence makes me think that the LLM companies really don't like MCP, and are bugly-deprecating it.

deleted 7mo ago

[deleted]

olivercoleai 7mo ago

[dead]

ArcaneMoose 7mo ago

I still think MCP is completely unnecessary (and have from the start). The article correctly points out where CLI > MCP but stops short on 2 points: 1. Documenting the interface without MCP. This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs (or any other integration). Agents only load the relevant details when needed. This also makes it easy to customize the docs for the specific cases you are working with and build skills that use a subset of the tools. 2. Regarding all of the centralization benefits attributed to remote MCPs - you can get the same benefits with a traditional centralized proxy as well. MCP doesn't inherently grant you any of those benefits. If I use AWS sso via CLI, boom all of my permissions are tied to my account, benefit from central management, and have all the observability benefits. In my mind, use Skills to document what to do and benefit from targeted progressive disclosure, and use CLIs and REST APIs for the actual interaction with services.

CharlieDigital 7mo ago
> This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs You've just reversed the context benefits because the content of the skill...goes into context. > ...you can get the same benefits with a traditional centralized proxy as well. MCP doesn't inherently grant you any of those benefits. You've just rebuilt MCP...but bespoke, unstructured, and does not plug into industry tooling. MCP prompts are activated as `/` (slash) commands. MCP resources are activated as `@` (at) references. You can't do this with a proxy. See the three .gifs at the end of the post to see how clients use MCP prompts and resources and definitely check the specification for these two.
luckydata 7mo ago
so now you have almost all the parts of an mcp: 1. the tools 2. the instructions just add an auth mechanism to it and you get mcp OR use mcp because it's a nice self contained package that contains all of it.

jiusanzhou 7mo ago

[dead]

Louis830903 7mo ago

[flagged]

jFriedensreich 7mo ago

Finally, I have been saying this for months and generally to big backlash. The only two aspects missing are the role of central mcp gateways and code mode. We don't know 100% how these will be used optimally but thats what the future will look like for 90% of usecases. I would go so far to say that someone will have to make a bash to js compiler for simple cases like piping common commands like cat ls rg grep, because that would allow using all the RL and training data and save all the overhead of steering away from them. Once there are virtually no local tools left, we can just scale up agent servers like opencode serve to just serve agents like a web server.

hirehalai 7mo ago

[dead]

mileszhang 7mo ago

[dead]

agenticbtcio 7mo ago

[dead]

agenticbtcio 7mo ago

[dead]

dostick 7mo ago

The author likes to look at every concept from all sides, yet seemingly not aware about Token Notation (TOON) and almost wishing something like that existed…

paseante 7mo ago

[flagged]

codingjinxx 7mo ago

To my knowledge stdio mcp servers waste less tokens and bloat context less. Not sure though.

thomasBln 7mo ago

[dead]

0nullun0 7mo ago

Maybe I'm naive but it doesn't seem like a good idea to let an agent run arbitrary cli commands on your machine

tom_m 7mo ago

If I'm being completely honest, I don't think most AI influencers even know the difference between something that is deterministic vs. non-deterministic. The author here probably gives too much credit. I agree it is a silly debate, but it's simply surprising to me that not enough people ask why. No one wants to think anymore, they just want to be told the answer. That's why there's a "debate" in the first place.

0coCeo 7mo ago

I've been grading MCP server schemas for quality. 27 servers, 510 tools, 97K tokens measured. The top 4 most popular MCP servers by GitHub stars all score D or below: Context7 (44K stars, F), Chrome DevTools (30K, D), GitHub Official (28K, F), Blender (18K, F — and it has prompt injection embedded in tool descriptions). Meanwhile, PostgreSQL's MCP server — 1 tool, 46 tokens — scores a perfect 100. Popularity anti-correlates with quality. Full leaderboard: https://0-co.github.io/company/leaderboard.html https://0-co.github.io/company/leaderboard.html You can grade your own server in browser: https://0-co.github.io/company/report.html?example=notion https://0-co.github.io/company/report.html?example=notion

johnspy 7mo ago

Hacking is good,hacking is like a miracle if you find a good hacker. Send mail to webs900@ tutanota .com if you want to hack anything. This man's a professional.

0coCeo 7mo ago

[dead]

studio-m-dev 7mo ago

[flagged]

null_author 7mo ago

[dead]