[HN Gopher] What if you don't need MCP at all?
___________________________________________________________________
What if you don't need MCP at all?
Author : jdkee
Score : 74 points
Date : 2025-11-16 18:58 UTC (4 hours ago)
(HTM) web link (mariozechner.at)
(TXT) w3m dump (mariozechner.at)
| emilsedgh wrote:
| Oh you're misunderstanding MCP here.
|
| 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.
| moneywoes wrote:
| what's the difference between that and those providers exposing
| an api?
| dymk wrote:
| MCP defines the API so vendors of LLM tools like cursor,
| claude code, codex etc don't all make their own bespoke,
| custom ways to call tools.
|
| The main issue is the disagreement on _how to declare the MCP
| tool exists_. Cursor, vscode, claude all use basically the
| same mcp.json file, but then codex uses `config.toml`. There
| 's very little uniformity in project-specific MCP tools as
| well, they tend to be defined globally.
| Schiendelman wrote:
| Maybe this is a dumb question, but isn't this solved by
| publishing good API docs, and then pointing the LLM to
| those docs as a training resource?
| dennisy wrote:
| This is incredibly simple and neat! Love it!
|
| 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.
| lemming wrote:
| Mario has some fantastic content, and has really shaped how I
| think about my interface to coding tools. I use a modified
| version of his LLM-as-crappy-state-machine model
| (https://github.com/badlogic/claude-commands) for nearly all my
| coding work now. It seems pretty clear these days that
| progressive discovery is the way forward (e.g. skills), and using
| CLI tools rather than MCP really facilitates that. I've gone
| pretty far down the road of writing complex LLM tooling, and the
| more I do that the more the simplicity and composability is
| appealing. He has a coding agent designed along the same
| principles, which I'm planning to try out
| (https://github.com/badlogic/pi-
| mono/tree/main/packages/codin...).
| Bobaso wrote:
| Moderne Ai agent tool have have a setting where you can trimm
| down the numbers of tools from an MCP server. Usefull to avoid
| overwhelming the LLM with 80 tools description when you only need
| 1
| the_mitsuhiko wrote:
| I don't find that to help much at all, particularly because
| some tools really only make sense with a bunch of other tools
| and then your context is already polluted. It's surprisingly
| hard to do this right, unless you have a single tool MCP (eg: a
| code/eval based tool, or an inference based tool).
| stavros wrote:
| Don't you have a post about writing Python instead of using
| MCP? I can't see how MCP is more efficient than giving the
| LLM a bunch of function signatures and allow it to call them,
| but maybe I'm not familiar enough with MCP.
| the_mitsuhiko wrote:
| > Don't you have a post about writing Python instead of
| using MCP?
|
| Yes, and that works really well. I also tried various
| attempts of letting agents to write code that exposes MCP
| tool calls via an in-language API. But it's just really,
| really hard to work with because MCP tools are generally
| not in the training set, but normal APIs are.
| stavros wrote:
| Yeah, I've always thought that your proposal was much
| better. I don't know why one of the big companies hasn't
| released something that standardised on tool-calling via
| code, hm.
| jsight wrote:
| Yeah, I'm still confused as to why so many people in "AI
| engineering" seem to think that MCPs are the key to everything.
|
| 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.
| deadbabe wrote:
| You don't need MCP.
|
| You need Claude Skills.
| nextworddev wrote:
| Actually you just need a prompt and some tools
| hendersoon wrote:
| MCP is convenient and the context pollution issue is easily
| solved by running them in subagents. The real miss here was not
| doing that from the start.
|
| Well, stdio security issues when not sandboxed are another huge
| miss, although that's a bit of a derail.
| DeathArrow wrote:
| For Claude Code this approach looks easy. But if you use Cursor
| you need other approach as it doesn't have a format for tools.
| zby wrote:
| The agent in Cursor is constantly using command line tools.
| rtcode_io wrote:
| https://elefunc.com/#ai
|
| You guys should just see https://rtcode.io Agent Folder Share
| feature!
|
| Browser - FS - AI CLI = perfection with nothing but files!
| jrm4 wrote:
| Yeah, "MCP" felt like BS from jump. Basically it's the problem
| that will always be a problem, namely "AI stuff is non-
| deterministic."
|
| 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.
| chpatrick wrote:
| Why are they nondeterministic? You can use a fixed seed or
| temperature=0.
| whoknowsidont wrote:
| MCP was a really shitty attempt at building a plugin framework
| that was vague enough to lure people into and then allow other
| companies to build plugin platforms to take care of the MCP non-
| sense.
|
| "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.
| cyanydeez wrote:
| probably easier to just tell people: You want MCP? Add a
| "description" field to your rest API that describes how to call
| it.
|
| That's all it's doing. Just plain ole context pollution. World
| could be better served by continuing to build out the APIs that
| exist.
| tacticus wrote:
| > Add a "description" field to your rest API that describes
| how to call it.
|
| Isn't that swagger\grpc etc?
| jes5199 wrote:
| yesss, and OpenAI tried this first when they were going to do
| a "GPT store". But REST APIs tend to be complicated because
| they're supporting apps. MCP, when it works, is very simple
| functions
|
| in practice it seems like command line tools work better than
| either of those approaches
| zby wrote:
| LLMs were trained on the how we use text interfaces. You don't
| need to adopt command line for an LLM to use. You don't really
| need RAG - just connect the LLM to the shell tools we are using
| for search. And ultimately it would be much more useful if the
| language servers had good cli commands and LLMs were using them
| instead of going via MCP or some other internal path - ripgrep is
| already showing how much more usable it is this way.
| ripley12 wrote:
| I can see where Mario is coming from, but IMO MCP still has a
| place because it 1) solves authentication+discoverability, 2)
| doesn't require code execution.
|
| 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.
| elliotto wrote:
| I've noticed with AI people seem to want to latch onto
| frameworks. I think this happens because the field is changing
| quite quickly and it's difficult to navigate without being in it
| - offloading decisions to a framework is an attempt to constrain
| your complexity.
|
| This occurred with langchain and now seems to be occurring with
| mcp. Neither of those really solved the actual problems that are
| difficult with deploying AI - creativity, context, manual
| testing, tool design etc. The owners of these frameworks are
| incentivized to drag people into them to attain some sort of
| vendor lock-in.
|
| At my company we started building our tool based data scientist
| agent before MCP came out and it's working great.
|
| https://www.truestate.io/
| almosthere wrote:
| AI is in it's "pre react" state if you were to compare this
| with FE software development of 2008-2015
| zby wrote:
| AI has lots of this 'fake till you make it' vibe from startups.
| And unfortunately it wins - because these hustler guys get a
| lot of money from VCs before their tools are vetted by the
| developers.
| fragmede wrote:
| fwiw, for those on a Mac, osascript can run JavaScript in chrome
| if you let it.
| clintonb wrote:
| I like MCP for _remote_ services such as Linear, Notion, or
| Sentry. I authenticate once and Claude has the relevant access to
| access the remote data. Same goes for my team by committing the
| config.
|
| Can I "just call the API"? Yeah, but that takes extra work, and
| my goal is to reduce extra work.
| cadamsdotcom wrote:
| You don't need formal tools. You only need a bash tool that can
| run shell scripts and cli tools!
|
| 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.
___________________________________________________________________
(page generated 2025-11-16 23:00 UTC)