I’m not sure about some of this — I still think there is some value to MCP as a gateway to private resources when API access doesn’t exist.

But please don’t try to redefine the Accept-Language header. These things are well defined for a reason and redefining things isn’t helpful. Trying to figure out protocols on the fly for LLMs is how we got into the current mess. For all of the cruft that W3C has, I think that working with standards committees could help the AI vendors here.

It would seem that curl + jq represents most of the solution these days. I recently learned that jq programs can be used in the other direction to effectively patch a json document too.

Putting both of these things together, I am running out of problems to solve as a human developer in the space of AI agent integration.

Assuming all your systems speak JSON right now, you are already 100% there with frontier models. You don't need to write a single line of code. Even if your json documents are monstrous in size. Put a size limit around the jq output and the agent will iterate with various filters until it finds a concise view of the problem. None of this behavior needs to be prompted or orchestrated anymore. Give the agent the tools and set reasoning level > 0.

Wow, this couldn't have been written at a worse time. OP absolutely doesn't know what he's talking about.

I don't get excited about the directories listing all the MCPs that do all these random things. However, I used claude to create an MCP that is a gateway to our system and it's enabled some pretty helpful functionality for us. I use claude cowork to create email designs using data and content from our CMS, it can push accepted work straight into our system, evaluate content, and analyze results. All of that used to be a manual tiring process. This removed a lot of drudgery and improved the quality as well.

When I first looked at MCP protocol, I did not like it. Then I realized, I don't have to care about the protocol. Claude can implement that for me and it did.

I don't think MCP is a bad idea, but using them incorrectly is.

CLI tools are great if you always use the same environment. But try using them from your iPhone, and they simply won't work; a remote MCP will work seamlessly.

HTTP APIs solve a different problem. APIs are designed to be predictable and consistent, so the client always knows the response shape in advance. The MCPs are designed to be dynamically discovered. This lets agents connect to new and unknown ones.

Trying to give APIs extra responsibilities so they can replace MCPs would just create more confusion. It's like creating an MCP server but calling it an API.

MCP is like anything else - it has its uses. Use it where it makes sense. Where it doesn't, don't. For my part, I probably rarely want my Agent to waste time writing its own adapter for a particular API that needs to be called, when I can just point it at an existing MCP server. And while context bloat can be a problem if you're using many many MCP tools, not every use case needs that many tools. Making that a non-issue in many cases.

For my part, I wrote an MCP server this weekend for Bugzilla, connected it to ChatGPT and now ChatGPT can help me manage my queue of bugs (and non-bugs - I use Bugzilla as sort of a generic work-item tracker, TBH). Simple, works and gives me a nice natural language interface to the tool. And if I want more than the generic API surface, I can add tools (or modify the existing ones) to add any additional business logic I want.

Can you "get there from here" other ways? Sure, absolutely. But this works quite well for my use case and I'm not anticipating "delete my MCP server" anytime soon. In fact, I plan to deploy one for interacting with my Mediawiki instance as well. I also even have plans to implement MCP for interfacing with all of my LXI/SCPI enabled test equipment!

If I get to the point where context bloat becomes an issue, I'll cross that bridge when I get to it.

MCP Apps[1] also look like a really cool addition to the stack. I've only built toy examples / demos to date but I'm pretty excited about what this brings to the table as well.

[1]: https://modelcontextprotocol.io/extensions/apps/overview

MCP is a solid, obvious idea. The problem is the implementation and roll out. It was shotgunned from the start and made an otherwise simple thing far too complicated. IME, a shoddy foundation always leads to shoddy construction on top.

When done properly, MCP can be really useful as an API bridge. MCP is (or can be), after all, just a JSON-RPC endpoint that returns a standardized response format. "Tools" are just function calls w/ definitions that are LLM-consumable.

But, imo, it's foolish to dismiss MCP outright.

MCPs are indeed useless, they're very limited in functionality and frequently struggle with large requests or get wedged in bad states.

There is no reason not to use the native API directly.

Article is focusing too much on tool use over HTTP. One of the good things about MCP is that it's the same protocol whether the tool is implemented with HTTP or using stdin over a local process. And it doesn't make sense to talk about HTTP headers with stdin.

> There are still some issues, like CLIs returning machine-readable responses (JSON/XML, etc.), which tend to be very verbose and heavy on token usage, but we have ways to fix this.

This problem is also solved by MCP.

Anyway, when building a new tool, I personally try a CLI based tool first, then I'll fall back on MCP if the CLI is not working.

One big reason I see for needing to switch from a CLI to MCP, is if the agent needs to send a lot of data to the tool, and it has to pack and format all that input data as CLI params, and you can start seeing problems with the Bash command syntax being improperly escaped. That problem is solved by MCP thanks to using JSON-RPC over stdin.

Summary.. you shouldn't use MCP for everything, but there is a time and a place for it. Which is what the experienced devs have been saying about MCP for over a year now.

> Recently, a Vercel engineer called on harnesses to send the programming language the client prefers, so documentation sites can serve more specific examples. For example, adding Python could prioritize docs for the Python SDK instead of sending something generic.

I know this is pedantic, but IMO that should just be in the URL if the resource is going to be totally different. Accept-Language is already a bit weird for the same reason in my mind, but I think the intention behind it is the resource itself is attempting to communicate the exact same resource. Obviously, two different languages from two different cultures are going to have different interpretations of the same direct translation, but the intention is the service has at least tried to avoid that as much as possible.

Adding programming language into that same concept just makes it seems like you're serving both /docs/typescript/vx/... and /docs/python/vx/... from /docs/vx/... despite them (in theory) having many more differences in between implementations/context than that would imply.

Agents should read sitemaps. Does anyone's harness do specifically that when looking up documentation?