←back to thread

What if you don't need MCP at all?

(mariozechner.at)
237 points jdkee | 9 comments | 16 Nov 25 18:58 UTC | HN request time: 0.706s | source | bottom
1. nestorD ◴[16 Nov 25 23:16 UTC] No.45949335[source]▶
So far I have seen two genuinely good arguments for the use of MCPs:

* 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.

replies(6): >>45949460 #>>45949551 #>>45949927 #>>45949984 #>>45950485 #>>45957820 #
2. the_mitsuhiko ◴[16 Nov 25 23:44 UTC] No.45949551[source]▶
> * Contrary to APIs, they can change their interface whenever they want and with little consequences.

I already made this argument before, but that's not entirely right. I understand that this is how everybody is doing it right now, but that in itself cause issues for more advanced harnesses. I have one that exposes MCP tools as function calls in code, and it encourages the agent to materialize composed MCP calls into scripts on the file system.

If the MCP server decides to change the tools, those scripts break. That is is also similar issue for stuff like Vercel is advocating for [1].

[1]: https://vercel.com/blog/generate-static-ai-sdk-tools-from-mc...

replies(1): >>45954874 #
3. tptacek ◴[17 Nov 25 00:50 UTC] No.45949927[source]▶
What's the alternative design where the model has access to API credentials?
replies(1): >>45950018 #
4. moneywoes ◴[17 Nov 25 01:02 UTC] No.45949984[source]▶
what about things like rate limiting, how are those implemented, any Goodreads
5. baby_souffle ◴[17 Nov 25 01:11 UTC] No.45950018[source]▶
> What's the alternative design where the model has access to API credentials?

All sorts of ways this can happen but it usually boils down to leaving them on disk or in an environment variable in the repo/dir(s) where the agent is operating in.

6. rsanheim ◴[17 Nov 25 02:56 UTC] No.45950485[source]▶
But …you have to give the MCP the creds somehow. Maybe it’s via a file on disk (bad), maybe via an env var (less bad). Maybe you do it via your password CLI that you biometricly auth to, which involves a timeout of some sort for security, but that often means you can’t leave an agent unattended.

In any case, how is any of this better than a CLI? CLIs have the same access models and tradeoffs, and a persistent agent will plumb the depths of your file system and environment to find a token to do a thing if your prompt was “do a thing, use tool/mcp/cli”.

So where is this encapsulation benefit?

replies(1): >>45950654 #
7. tuananh ◴[17 Nov 25 03:37 UTC] No.45950654[source]▶
mcp is easy to self-host. model? a little less so.
8. lsaferite ◴[17 Nov 25 16:09 UTC] No.45954874[source]▶
Wouldn't the answer to this be to have the agent generate a new materialized workflow though? You already presumably have automated the agent's ability to create these workflows based off some prompting and a set of MCP Servers.
9. cstrahan ◴[17 Nov 25 20:21 UTC] No.45957820[source]▶
You're not wrong, but I figured I'd point out the cons / alternatives:

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

An alternative to MCP, which would still provide this: code (as suggested in https://www.anthropic.com/engineering/code-execution-with-mc... and https://blog.cloudflare.com/code-mode/).

Put the creds in a file, or secret manager of some sort, and let the LLM write code to read and use the creds. The downside is that you'd need to review the code to make sure that it isn't printing (or otherwise moving) the credentials, but then again you should probably be reviewing what the LLM is doing anyway.

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

The upside is as stated, but the downside is that you're always polluting the context window with MCP tool descriptions.