7 ms·

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 want

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 8mo 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 8mo 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 8mo 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.
    - fartfeatures 8mo ago
      > You're interacting with an LLM, so correctness is already out the window. With all due respect if you are prompting correctly and following approaches such as TDD / extensive testing then correctness is not out the window. That is a misunderstanding likely caused by older versions of these models. Correctness can be as complete as any other new code, I've used the AI to port algorithms from Python to Rust which I've then tested against math oracles and published examples. Not only can I check my code mathematically but in several instances I've found and fixed subtle bugs upstream. Even in well reviewed code that has been around for many years and is well used. It is simply a tool.
    - CharlieDigital 8mo ago
      > So why MCP? ... MCP seems arbitrary as a protocol You're right, it is an arbitrary protocol, but it's one that is supported by the industry. See the screencaps at the end of the post that show why this protocol. Maybe one day, we will get a better protocol. But that day is not today; today we have MCP.
- nonethewiser 8mo ago
  If AI is AI why does it need me to prompt it?
- 8note 8mo ago
  Why the desire to reinvent the wheel every time? Agents can do it accurately, but you have to wait for them to figure it out every time, and waste tokens on non-differentiated work The agents are writing the mcps, so they can figure out those http and ftp calls. MCP makes it so they dont have to every time they want to do something. I wouldnt hire a new person to read a manual and then make a bespoke json to call an http server, every single time i want to make a call, and thats not a knock on the person's intelligence. Its just a waste of time doing the same work over and over again. I want the results of calling the API, not to spend all my time figuring out how to call the API
  - theptip 8mo ago
    It’s simply about making standard, centralized plugins available. Right now Claude benefits from a “link GitHub Connector” button with a clear manifest of actions. Obviously if the self-modifying, Clawd-native development thing catches on, any old API will work. (Preferably documented but that’s not a hard requirement.) For now though, Anthropic doesn’t host a clawd for you, so there isn’t yet a good way for it to persist customs integrations.
- avereveard 8mo ago
  C each ai need context management per conversation this is something that would be very clunky to replicate on top of http or ftp (as in requiring side channel information due session and conversation management) Everyone looks at api and sure mcp seem redundant there but look at agent driving a browser the get dom method depends on all the action performed from when the window opened and it needs to be per agent per conversation Can you do that as rest sure sneak a session and conversation in a parameter or cookie but then the protocol is not really just http is it it's all this clunky coupling that comes with a side of unknowns like when is a conversation finished did the client terminate or were just between messages and as you go and solve these for the hundredth time you'd start itching for standardization
  - superturkey650 8mo ago
    All MCP adds is a session token. How is that not already a solved problem?
    - avereveard 8mo ago
      P It makes it part of the protocol so the llm doesn't have to handle it, which is brittle And look at the patent post I've replied to choice of protocol, I'd like to see a session token over ftp where you need to track the current folder per conversation.
      - superturkey650 8mo ago
        But the agent harness is still handling the session token for you either way. MCP might be an easy way for agent harness creators to abstract the issue away, but I don’t want to lose all REST conventions just to make it a little easier for them to write an agent harness. It makes it harder for the LLM to understand what’s going on, not easier.
        avereveard 8mo ago
        again, not all services are rest or with nice api, if they were, you'd just have the agent write scripts.
- re-thc 8mo ago
  > If AI is AI That "AI" got renamed to "AGI"
- 0xbadcafebee 8mo ago
  You mean, why not ask the AI to "find a way to use FTP", including either using a tool, or writing its own code? Besides the security issues? One simple reason is "determinism". If you ask the AI to "just figure it out", it will do that in different ways and you won't have a reliable experience. The protocol provides AI a way to do this without guessing or working in different ways, because the server does all the work, deterministically. But the second reason is, all the other reasons. There is a lot in the specification, that the AI literally cannot figure out, because it would require custom integration with every application and system. MCP is also a client/server distributed system, which "calling a tool" is not, so it does stuff that is impossible to do on your existing system, without setting up a whole other system... a system like MCP. And all this applies to both the clients, and the servers. Here's another way to think of it. The AI is a psychopath in prison. You want the psycho to pick up your laundry. Do you hand the psycho the keys to your car? Or do you hand him a phone, where he can call someone who is in charge of your car? Now the psycho doesn't need to know how to drive a car, and he can't drive it off a bridge. All he can do is talk to your driver and tell him where to go. And your driver will definitely not drive off a bridge or stab anyone. And this works for planes, trains, boats, etc, just by adding a phone in between.
simianwords 8mo ago
> This is absolutely necessary since you can (and will) use AI for a million different things the point is, is it necessary to create a new protocol?
- hannasanarion 8mo ago
  Exactly this. I've made some MCP servers and attached tons of other people's MCP servers to my llms and I still don't understand why we can't just use OpenAPI. Why did we have to invent an entire new transport protocol for this, when the only stated purpose is documentation?
- CharlieDigital 8mo ago
  By and large, it is a very simple protocol and if you build something with it, you will see that it is just a series of defined flows and message patterns. When running over streamable HTTP, it is more or less just a simple REST API over HTTP with JSON RPC payload format and known schema. Even the auth is just OAuth.
- paulddraper 8mo ago
  It’s not a new protocol. It’s JSON-RPC plus OAuth. (Plus a couple bits around managing a local server lifecycle.)
  - drdaeman 8mo ago
    World would be surely a saner place if instead of “MCP vs CLI” people would talk about “JSON-RPC vs execlp(3)”. Not accurate, but at least makes on think of the underlying semantics. Because, really, what matters is some DSL to discover and describe action invocations.
tptacek 8mo ago
Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is a clear problem that you'd like an "automatic" solution for, but it's not "we don't have a standard protocol that captures every possible API shape", it's "we need a good way to simulate what a CLI does for agents that can't run bash".
- isbvhodnvemrwvn 8mo ago
  It's significantly more difficult to secure random clis than those apis. All llm tools today bypass their ignore files by running commands their harness can't control.
  - tptacek 8mo ago
    I'm fuzzy when we're talking about what makes an LLM work best because I'm not really an expert. But, on this question of securing/constraining CLIs and APIs? No. It is not easier to secure an MCP than it is a CLI. Constraining a CLI is a very old problem, one security teams have been solving for at least 2 decades. Securing MCPs is an open problem. I'll take the CLI every time.
    - brabel 8mo ago
      You should read the article, it explains very well why that is completely wrong. cLIs don’t have a good story about security, are you serious?? They either use a secret , in which case the LLM will have the exact same permission as you as a user, which is bonkers (not to mention the LLM can leak your secret now to anyone by making a simple curl request) and prevents AI auditing since it’s not the AI that seems to use the secret, it’s just you! And the other alternative is to run OAuth flows by making you authorize in the browser :). That at least allows some sort of auditing since the agent can use a specific OAuth client to authorize you. But now you have no ability to run the agent unattended, you will need to log in to every possible CLI service before you let the agent work, which means your agent is just sitting there with all your access. Ignorance about best security practices really makes this industry a joke. We need zero standing trust. Auditability. Minimum access required for a task. By letting your agent use your CLIs as if it was you, you throw away all of that.
ekropotin 8mo ago
I mean, CLI tool is also “reusable communication abstraction”, innit?
- mmis1000 8mo ago
  Tell me how many ways that print help message for a command you have seen and say "reusable" again. Mcp is exactly exists to solve this. The rest is just json rpc with simple key value pairs. You can probably let llm guess the help flag and try to parse help message. But the success rate is totally depends on model you are using.
  - krzyk 8mo ago
    Most CLIs use `--help`, any other are just plain hostile to the users. `-h` is also popular, but there is also possible issue of that shorthand, hence `--help`.
    - mmis1000 8mo ago
      some come with only very short description but most part are only discoverable by 'man'. and windows mostly use \? and also \h, java user single - for long argument because it don't have short one. I doubt it is ever close to reusable. And even allowed position of parameters (or even meaning of arguments in case of ffmpeg) are program dependent. Some allow anywhere as long as it is started with a dash, some only allow before first input
troupo 8mo ago
MCP is literally "define a bespoke API using this vibe-coded protocol over JSON-RPC". There's nothing more standard or reusable or application-agnostic about it than using an API over any of the existing protocols.
- 0xbadcafebee 8mo ago
  No, this misunderstands what MCP is for and how it works. Let's say you use Claude's chat interface. How can you make Claude connect to, say, the lights in your house? Without MCP, you would need Anthropic the company to add support to Claude the web interface to connect over a network to your home, use some custom routing software (that you don't have) to communicate over whatever lightbulb-specific IoT protocol your bulbs use, to be able to control them. Claude needs to support your specific lightbulb stack, and some kind of routing software would need to be added in your home to connect the external network to the internal devices. But with MCP, Claude only has to support MCP. They don't have to know anything about your lightbulbs or have some custom routing thing for your home. You just need to run an MCP server that talks to the lightbulbs... which the lightbulb company should make and publish, so you don't have to do anything but download the lightbulb MCP server and run it. Now Claude can talk to your lightbulbs, and neither you nor Claude had to do any extra work. In addition to the communication, there is also asynchronous task control features, AI-specific features, security features, etc that are all necessary for AI work. All this is baked into MCP. This is the power of standardized communications abstractions. It's why everyone uses HTTP and doesn't have their own custom application-specific tcp-server-language. The world wide web would just be 10 websites.
  - losvedir 8mo ago
    No, that's not MCP. That's a pleasant idea that MCP has been shoehorned into trying to solve. But MCP the spec is far more complicated than it needs to be to support that story. Streamable HTTP transport makes it much more workable, and I imagine was designed by real people rather than the version prior to that, but it's still much more than it needs. Ultimately, 90% of use cases would be solved by a dramatically simpler spec which was simply an API discovery mechanism, maybe an OpenAPI spec at a .well-known location, and a simple public-client based OAuth approach for authentication and authorization. The full-on DCR approach and stateful connections specified in the spec is dramatically harder to implement.

ambicapter 8mo 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 8mo 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 8mo 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.
  - fartfeatures 8mo ago
    > You're interacting with an LLM, so correctness is already out the window. With all due respect if you are prompting correctly and following approaches such as TDD / extensive testing then correctness is not out the window. That is a misunderstanding likely caused by older versions of these models. Correctness can be as complete as any other new code, I've used the AI to port algorithms from Python to Rust which I've then tested against math oracles and published examples. Not only can I check my code mathematically but in several instances I've found and fixed subtle bugs upstream. Even in well reviewed code that has been around for many years and is well used. It is simply a tool.
  - CharlieDigital 8mo ago
    > So why MCP? ... MCP seems arbitrary as a protocol You're right, it is an arbitrary protocol, but it's one that is supported by the industry. See the screencaps at the end of the post that show why this protocol. Maybe one day, we will get a better protocol. But that day is not today; today we have MCP.
nonethewiser 8mo ago
If AI is AI why does it need me to prompt it?
8note 8mo ago
Why the desire to reinvent the wheel every time? Agents can do it accurately, but you have to wait for them to figure it out every time, and waste tokens on non-differentiated work The agents are writing the mcps, so they can figure out those http and ftp calls. MCP makes it so they dont have to every time they want to do something. I wouldnt hire a new person to read a manual and then make a bespoke json to call an http server, every single time i want to make a call, and thats not a knock on the person's intelligence. Its just a waste of time doing the same work over and over again. I want the results of calling the API, not to spend all my time figuring out how to call the API
- theptip 8mo ago
  It’s simply about making standard, centralized plugins available. Right now Claude benefits from a “link GitHub Connector” button with a clear manifest of actions. Obviously if the self-modifying, Clawd-native development thing catches on, any old API will work. (Preferably documented but that’s not a hard requirement.) For now though, Anthropic doesn’t host a clawd for you, so there isn’t yet a good way for it to persist customs integrations.
avereveard 8mo ago
C each ai need context management per conversation this is something that would be very clunky to replicate on top of http or ftp (as in requiring side channel information due session and conversation management) Everyone looks at api and sure mcp seem redundant there but look at agent driving a browser the get dom method depends on all the action performed from when the window opened and it needs to be per agent per conversation Can you do that as rest sure sneak a session and conversation in a parameter or cookie but then the protocol is not really just http is it it's all this clunky coupling that comes with a side of unknowns like when is a conversation finished did the client terminate or were just between messages and as you go and solve these for the hundredth time you'd start itching for standardization
- superturkey650 8mo ago
  All MCP adds is a session token. How is that not already a solved problem?
  - avereveard 8mo ago
    P It makes it part of the protocol so the llm doesn't have to handle it, which is brittle And look at the patent post I've replied to choice of protocol, I'd like to see a session token over ftp where you need to track the current folder per conversation.
    - superturkey650 8mo ago
      But the agent harness is still handling the session token for you either way. MCP might be an easy way for agent harness creators to abstract the issue away, but I don’t want to lose all REST conventions just to make it a little easier for them to write an agent harness. It makes it harder for the LLM to understand what’s going on, not easier.
      - avereveard 8mo ago
        again, not all services are rest or with nice api, if they were, you'd just have the agent write scripts.
re-thc 8mo ago
> If AI is AI That "AI" got renamed to "AGI"
0xbadcafebee 8mo ago
You mean, why not ask the AI to "find a way to use FTP", including either using a tool, or writing its own code? Besides the security issues? One simple reason is "determinism". If you ask the AI to "just figure it out", it will do that in different ways and you won't have a reliable experience. The protocol provides AI a way to do this without guessing or working in different ways, because the server does all the work, deterministically. But the second reason is, all the other reasons. There is a lot in the specification, that the AI literally cannot figure out, because it would require custom integration with every application and system. MCP is also a client/server distributed system, which "calling a tool" is not, so it does stuff that is impossible to do on your existing system, without setting up a whole other system... a system like MCP. And all this applies to both the clients, and the servers. Here's another way to think of it. The AI is a psychopath in prison. You want the psycho to pick up your laundry. Do you hand the psycho the keys to your car? Or do you hand him a phone, where he can call someone who is in charge of your car? Now the psycho doesn't need to know how to drive a car, and he can't drive it off a bridge. All he can do is talk to your driver and tell him where to go. And your driver will definitely not drive off a bridge or stab anyone. And this works for planes, trains, boats, etc, just by adding a phone in between.

simianwords 8mo ago

> This is absolutely necessary since you can (and will) use AI for a million different things the point is, is it necessary to create a new protocol?

hannasanarion 8mo ago
Exactly this. I've made some MCP servers and attached tons of other people's MCP servers to my llms and I still don't understand why we can't just use OpenAPI. Why did we have to invent an entire new transport protocol for this, when the only stated purpose is documentation?
CharlieDigital 8mo ago
By and large, it is a very simple protocol and if you build something with it, you will see that it is just a series of defined flows and message patterns. When running over streamable HTTP, it is more or less just a simple REST API over HTTP with JSON RPC payload format and known schema. Even the auth is just OAuth.
paulddraper 8mo ago
It’s not a new protocol. It’s JSON-RPC plus OAuth. (Plus a couple bits around managing a local server lifecycle.)
- drdaeman 8mo ago
  World would be surely a saner place if instead of “MCP vs CLI” people would talk about “JSON-RPC vs execlp(3)”. Not accurate, but at least makes on think of the underlying semantics. Because, really, what matters is some DSL to discover and describe action invocations.

tptacek 8mo ago

Why is this the right way to go? It's not solving the problem it looks like it's solving. If your challenge is that you need to communicate with a foreign API, the obvious solution to that is a progressively discoverable CLI or API specification --- the normal tool developers use. The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. There is a clear problem that you'd like an "automatic" solution for, but it's not "we don't have a standard protocol that captures every possible API shape", it's "we need a good way to simulate what a CLI does for agents that can't run bash".

isbvhodnvemrwvn 8mo ago
It's significantly more difficult to secure random clis than those apis. All llm tools today bypass their ignore files by running commands their harness can't control.
- tptacek 8mo ago
  I'm fuzzy when we're talking about what makes an LLM work best because I'm not really an expert. But, on this question of securing/constraining CLIs and APIs? No. It is not easier to secure an MCP than it is a CLI. Constraining a CLI is a very old problem, one security teams have been solving for at least 2 decades. Securing MCPs is an open problem. I'll take the CLI every time.
  - brabel 8mo ago
    You should read the article, it explains very well why that is completely wrong. cLIs don’t have a good story about security, are you serious?? They either use a secret , in which case the LLM will have the exact same permission as you as a user, which is bonkers (not to mention the LLM can leak your secret now to anyone by making a simple curl request) and prevents AI auditing since it’s not the AI that seems to use the secret, it’s just you! And the other alternative is to run OAuth flows by making you authorize in the browser :). That at least allows some sort of auditing since the agent can use a specific OAuth client to authorize you. But now you have no ability to run the agent unattended, you will need to log in to every possible CLI service before you let the agent work, which means your agent is just sitting there with all your access. Ignorance about best security practices really makes this industry a joke. We need zero standing trust. Auditability. Minimum access required for a task. By letting your agent use your CLIs as if it was you, you throw away all of that.

ekropotin 8mo ago

I mean, CLI tool is also “reusable communication abstraction”, innit?

mmis1000 8mo ago
Tell me how many ways that print help message for a command you have seen and say "reusable" again. Mcp is exactly exists to solve this. The rest is just json rpc with simple key value pairs. You can probably let llm guess the help flag and try to parse help message. But the success rate is totally depends on model you are using.
- krzyk 8mo ago
  Most CLIs use `--help`, any other are just plain hostile to the users. `-h` is also popular, but there is also possible issue of that shorthand, hence `--help`.
  - mmis1000 8mo ago
    some come with only very short description but most part are only discoverable by 'man'. and windows mostly use \? and also \h, java user single - for long argument because it don't have short one. I doubt it is ever close to reusable. And even allowed position of parameters (or even meaning of arguments in case of ffmpeg) are program dependent. Some allow anywhere as long as it is started with a dash, some only allow before first input

troupo 8mo ago

MCP is literally "define a bespoke API using this vibe-coded protocol over JSON-RPC". There's nothing more standard or reusable or application-agnostic about it than using an API over any of the existing protocols.

0xbadcafebee 8mo ago
No, this misunderstands what MCP is for and how it works. Let's say you use Claude's chat interface. How can you make Claude connect to, say, the lights in your house? Without MCP, you would need Anthropic the company to add support to Claude the web interface to connect over a network to your home, use some custom routing software (that you don't have) to communicate over whatever lightbulb-specific IoT protocol your bulbs use, to be able to control them. Claude needs to support your specific lightbulb stack, and some kind of routing software would need to be added in your home to connect the external network to the internal devices. But with MCP, Claude only has to support MCP. They don't have to know anything about your lightbulbs or have some custom routing thing for your home. You just need to run an MCP server that talks to the lightbulbs... which the lightbulb company should make and publish, so you don't have to do anything but download the lightbulb MCP server and run it. Now Claude can talk to your lightbulbs, and neither you nor Claude had to do any extra work. In addition to the communication, there is also asynchronous task control features, AI-specific features, security features, etc that are all necessary for AI work. All this is baked into MCP. This is the power of standardized communications abstractions. It's why everyone uses HTTP and doesn't have their own custom application-specific tcp-server-language. The world wide web would just be 10 websites.
- losvedir 8mo ago
  No, that's not MCP. That's a pleasant idea that MCP has been shoehorned into trying to solve. But MCP the spec is far more complicated than it needs to be to support that story. Streamable HTTP transport makes it much more workable, and I imagine was designed by real people rather than the version prior to that, but it's still much more than it needs. Ultimately, 90% of use cases would be solved by a dramatically simpler spec which was simply an API discovery mechanism, maybe an OpenAPI spec at a .well-known location, and a simple public-client based OAuth approach for authentication and authorization. The full-on DCR approach and stateful connections specified in the spec is dramatically harder to implement.