"What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!"

LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.

Not only do you not need MCP, but you should actively avoid using it.

Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.

1. Claude Code is aware of what MCPs it has access to at all times.

2. Adding an MCP is like adding to the agent's actuators/vocabulary/tools because unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available and "hey you have access to X" and "hey make an MCP for X" take the same level of effort on the part of the user.

3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.

4. You can almost trivially create an MCP that does X by asking the agent to create an MCP that does X. This saves you from having to constantly remind an agent it can do X.

NOTE: I cannot stress enough that this property of MCPs is COMPLETELY ORTHOGONAL to the nutty way they are implemented, and I am IN NO WAY defending the implementation. But currently we are talking past the primary value prop.

I would personally prefer some other method but having a way to make agents extensible is extremely useful.

EXAMPLE:

"Make a bash script that does X."

<test manually to make sure it works>

"Now make an MCP called Xtool that uses X."

<restart claude>

<claude is now aware it can do Xtool>

* They can encapsulate (API) credentials, keeping those out of reach of the model,

* Contrary to APIs, they can change their interface whenever they want and with little consequences.

They are great if you have a UI that you want and it needs a plugin system, obviously.

But the benefits become much more marginal for a developer of enterprise AI systems with predefined tool selections. They are actually getting overused in this space, if anything, sometimes with security as a primary casualty.

Can I “just call the API”? Yeah, but that takes extra work, and my goal is to reduce extra work.

Overwhelmed by Sentry errors recently I remembered sentry-cli. I asked the agent to use it to query for unresolved Sentry errors and make a plan that addresses all of them at once. Zeroed out my Sentry inbox in one Claude Code plan. All up it took about an hour.

The agent was capable of sussing out sentry-cli, even running it with --help to understand how to use it.

The same goes for gh, the github cli tool.

So rather than MCPs or function style tools, I highly recommend building custom cli tools (ie. shell scripts), and adding a 10-20 word description of each one in your initial prompt. Add --help capabilities for your agent to use if it gets confused or curious.

> When I start a session where the agent needs to interact with a browser, I just tell it to read that file in full and that's all it needs to be effective. Let's walk through their implementations to see how little code this actually is.

Cool, now you want to package that so others can use it? What next?

Put it behind an MCP is an easy approach. Then I can just install that MCP and by choosing it I have all the capabilities mentioned here.

Or in this particular case, a Claude Skill could likely do as well.

But I mean, that's MCP. I don't even really understand the people discussing that MCP is bad or whatever, it's a plug and play protocol so I can package tools for others to use in their preferred agent client.

CLI access also has the issue that if you want to integrate it in an application, well how do you bundle bash in a secure way so your agent can use it? And would you allow users custom tool call, now they can run arbitrary bash commands?

MCP shines when you want to add external functionality to an agent quickly, and in situations where it's not practical to let an agent go wild with code execution and network access.

Feels like we're in the "backlash to the early hype" part of the hype cycle. MCP is one way to give agents access to tools; it's OK that it doesn't work for every possible use case.

MCP was created so llm companies can have a plugin system. So instead of them being the API provider, they can become the platform that we build apps/plugins for, and they become the user interface to end consumers.

We've been developing this in case folks are interested: https://github.com/stanford-mast/a1

The agent should look at my README.md, not a custom human-like text that is meant to be read by machines only.

It also should look at `Makefile`, my bash aliases and so on, and just use that.

In fact, many agents are quite good at this (Code Fast 1, Sonnet).

Issue is, we have a LONG debt around those. READMEs often suck, and build files often suck. We just need to make them better.

I see agents as an opportunity for making friendlier repos. The agent is a free usability tester in some sense. If it can't figure out by reading the human docs, then either the agent is not good enough or your docs aren't good enough.

"Instead of a bloated API, an MCP should be a simple, secure gateway... MCP’s job isn’t to abstract reality for the agent; its job is to manage the auth, networking, and security boundaries and then get out of the way."

You still need some standard to hook up data to agents esp when the agents are not running on your local dev machine. I don't think e.g. REST/etc are nearly specific enough to do this without a more constrained standard for requests.

[1] https://blog.sshh.io/p/how-i-use-every-claude-code-feature

MCP is just an API with docs.

The problem isn’t MCP itself. It’s that each MCP “server” has to expose every tool and docs which consumes context.

I think the tools should use progressive reveal and only give a short summary like the skill does. Then agent can get full API of the tool on request.

Right now loading GitHub MCP takes something like 50k tokens.

MCP is aimed at the opposite scenario: distributing tools to many users without relying on their environments. It provides automatic tool discovery, a server boundary that isolates credentials, and strict control over exposed capabilities. Its heavier JSON-schema definitions exist because they’re machine-readable contracts that behave consistently across clients, whereas CLI tools vary drastically across systems. So while MCP adds context overhead, it solves portability and distribution problems that scripts simply can’t.

I add MCP tools to tighten the feedback loop. I want my Agent to be able to act autonomously but with a tight set of capabilities that don't often align with off-the-shelf tools. I don't want to YOLO but I also don't want to babysit it for non-value-added, risk-free prompts.

So, when I'm developing in go, I create `cmd/mcp` and configure a `go run ./cmd/mcp` MCP server for the Agent.

It helps that I'm quite invested in MCP and built github.com/ggoodman/mcp-server-go, which is one of the few (only?) MCP SDKs that let you scale horizontally over https while still supporting advanced features like elicitation and sampling. But for local tools, I can use the familiar and ergonomic stdio driver and have my Agent pump out the tools for me.

a) I have agents in production for enterprise companies that did what they were supposed to (automate a human process, alter the point of the whole division, lower cost, increase revenue)

b) the whole industry seems to be failing at doing a) to the point they think its all hype

c) the whole industry thinks they need MCP servers and I don’t

Then MCP comes out and AI explodes, sucking all the air out of the room for non-AI tools.

Now it seems like AI can work with CLIs better than MCP, so I’m tempted to slap AI integration all over the project to better convey the idea.

It’s crazy how quickly MCP has run it’s course and watching an entire ecosystem rediscover things from first principals.

Will have a think about how this can extended to other types of uses.

I have personally been trying to replace all tools/MCPs with a single “write code” tool which is a bit harder to get to work reliably in large projects.

Though it is more about debugging CSS, I think we are on the same way: let agents use tool by scripting.

We give a copy/pasteable MCP url that you can use with your favorite agent/chatbot/site and give those providers browser context and allow them to do browser actions.

So compared to Playwright MCP and others that require you to run npx and can only be connected to local clients, with ours you just paste a url and can use with any client.

Checkout our recent posts: https://news.ycombinator.com/item?id=45898043 https://www.youtube.com/watch?v=B4BTWNTuE-s

You need Claude Skills.

MCP and A2A are JSONRPC schemas people follow to build abstraction around their tools. Agents can use MCP to discover tools, invoke and more. OpenAPI Schemas are good alternatives to MCP servers today. In comparison to OpenAPI Schemas, MCP servers are pretty new.

my fav protocol is TCP, which I am a proud user of nc localhost 9999.

but not everyone have same taste of building software.

https://github.com/cagataycali/devduck

Yes, APIs should be self-documenting. Yes, response data should follow defined schemas that are understandable without deep knowledge of the backend. No, you don't need MCP for this.

I wish Google would have realized, or acknowledged, that XML and proper REST APIs solve both of these use cases rather than killing off XSLT support and presumably helping to coerce the other browsers and WhatWG to do the same.

Well, stdio security issues when not sandboxed are another huge miss, although that's a bit of a derail.

If there was some certainty MCP could add to this equation that would perhaps be theoretically nice, but otherwise it's just .. parsing, a perhaps not "solved" problem, but one for which there's already ample solutions.

You can throw all that away by rejecting MCP completely or by boiling tool-use down to just generating and running unstructured shell commands. But setting aside security issues or why you'd want to embrace more opportunities for hallucination instead of less.. shelling out for everything is perfect faith in the model's ability to generate correct bash for an infinite space of CLI surfaces. You've lost the ability to ever pivot to smaller/cheaper/local models, and now you're more addicted to external vendors/SOTA models.

Consider the following workflow with a large CLI surface that's a candidate for a dedicated LLM tool, maybe ffmpeg. Convert the man page to a JSON schema. Convert the JSON schema to a tool. Add the tool to a MCP server, alongside similar wizards for imagemagick/blender. The first steps can use SOTA models if necessary, but the later steps can all feasibly work for free, as a stand-alone app that has no cloud footprint and no subscription fee. This still works if ffmpeg/blender/imagemagick were private custom tools instead of well-known tools that are decades old. You can test the tools in offline isolation too. And since things like fastmcp support server composition you can push and pop that particular stack of wizards in or out of LLM capabilities.

Good luck getting real composition with markdown files and tweaking prompts for tone by adding a "Please" preamble. Good luck engineering real systems with vague beliefs about magic, no concrete specifications for any part of any step, constantly changing external dependencies, and perfect faith in vendors.

When MCP itself works it's great. For example, we organize units of work into "detective cases" for framing and the corresponding tool is wanderland__get_detective_case. Spawn a Claude Code session, speak "get up to speed on our current case" and we have instant context loading in a sub-agent session, useful when the Jira ticket requires input from another repository (or two). They're all writing back through the same wanderland__add_detective_case_note call and that routes everything through the central attractor to the active case.

Most of the time, the case we're working on was just a "read DVOPS-XXXXX in Jira and create a case for me". That's wanderland_get_jira_ticket (a thin wrapper on the jira cli) and wanderland__create_detecive_case in turn.

The secret to mcp is that it breaks a lot, or they forget about it because their context is polluted (or you broke it because you're working on it). But it's just a thin wrapper over your API anyways, so just ensure you've got a good /docs endpoint hanging off that and a built in fetch (or typically a fallback to bash with curl -s for some reason) and you're back up and running until you can offload that context. At least you should be if you've designed it properly. Throw in a CLI wrapper for your API as well, they love those :) Three interfaces to the same tool.

The MCP just offers the lowest friction, the context on how to use it injected automatically at a level low enough to pick it up in those natural language emissions and map it to the appropriate calls.

And, if you're building your own stack anyways, you can do naughty things to the protocol like like inject reminders from your agenda with weighted probabilities (gets more nagging the more you're overdue) or inject user-guides from the computational markdown graph the platform is built on when their tools are first used (we call that the helpful, yet somewhat forceful barrista pattern, no choice but to accept the paper and a summary of the morning news with your coffee in the morning). Or restrict the tools available based on previous responses (the more frustrated you get, the more we're likely to suggest you read a book Claude). Or when your knowledge graph is spatially oriented, you can do fun things like make sure we go east or west once in a while (variations on related items) rather than purely north south (into and out of specific knowledge veriticals) with simple vector math.

MCP isn't strictly necessary for all of this, that could be (and in some cases rightly is) implemented at the API layer, but the MCP layer does give us a simple place to reason about agentic behaviour and keeps it away from the tools itself. In other words, modeling error rates as frustration and restricting tool use / injecting help guides make sense in one layer and injecting reminders into a response from the same system that's processing the underlying tool calls makes sense in another, if the protocol you've designed for such things allows for such two way context passing. Absent any other layer in the current stack (and no real desire to implement the agentic loop on my own at the moment), the MCP protocol seems perfectly suited for these types of shennanigans - view it like something like Apigee or (...) API Gateway, adding a bit of intelligence and remixability on top of your tools for better UX with your agents