4 ms·

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,

by 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.
    - jmogly 8mo ago
      OP never mentioned letting the agent run as him or use his secrets. All of the issues you mention can be solved by giving the agent it’s own set of secrets or using basic file permissions, which are table stakes. Back to the MCP debate, in a world where most web apis have a schema endpoint, their own authentication and authorization mechanisms, and in many instances easy to install clients in the form of CLIs … why do we need a new protocol, a new server, a new whatever. KISS
      - CharlieDigital 8mo ago
        > OP never mentioned letting the agent run as him or use his secrets That is implicit with a CLI because it is being invoked in the user session unless the session itself has been sandboxed first. Then for the CLI to access a protected resource, it would of course need API keys or access tokens. Sure, a user could set up a sandbox and could provision agent-specific keys, but everyone could always enable 2FA, pick strong passwords, use authenticators, etc . and every org would have perfect security. That's not reality.
  - justboy1987 8mo ago
    [flagged]
- otabdeveloper4 8mo ago
  Just use a custom PATH and run in a chroot jail. CLI sandboxing is a solved problem compared to whatever MCP is.
- krzyk 8mo ago
  I don't think so. There is no MCP standard for authentication, our infosec banned MCP because of that.
  - CharlieDigital 8mo ago
    It's right there in the docs and it's just OIDC + OAuth: https://modelcontextprotocol.io/specification/draft/basic/authorization https://modelcontextprotocol.io/specification/draft/basic/au...
    - dtraub 8mo ago
      While the spec includes OAuth 2.1 now, that's only half the story. The real question is where the credentials live. When your agent calls a CLI or curls an API, it uses credentials stored on the developer's machine. For one person that's fine. But for 50 agents across a department, each needing keys for Slack, Jira, GitHub, your CRM, and a dozen internal APIs? You've recreated the pre-SSO world, except access is autonomous and at machine speed. Remote MCP servers (streamable HTTP, not stdio) change that. The agent authenticates via OAuth/SSO, the server holds the downstream keys, and the user never sees them. Disable the SSO account and every agent loses access. This is the same pattern as centralizing database credentials instead of baking them into every microservice config, just on a different layer. Longer version: https://dev.to/dennistraub/missing-from-the-mcp-debate-who-holds-the-keys-when-50-agents-access-50-apis-mb3 https://dev.to/dennistraub/missing-from-the-mcp-debate-who-h...
      - CharlieDigital 8mo ago
        Yes; I made the same point in my write up. The auth story is heavily overlooked by most folks that are solo-vibing and then think that advice, the tools, and the practices that work for 1 works for a team or org.
harrall 8mo ago
CLI doesn’t work for your coworkers that aren’t technical. Have you tried to use a random API before? It’s a process of trial and error. With the MCP tools I use, it works the first time and every time. There is no “figuring out.”
- mkoubaa 8mo ago
  If you can't write a good CLI I doubt you could write a good MCP
- JeremyNT 8mo ago
  This should be trivial if you have proper API documentation in something like swagger. You can generate a cli tool with no "figuring out" anything either.
  - clintonb 8mo ago
    Nothing is “trivial” when you combine humans and computers. I worked at the MIT Computing Help Desk during my undergraduate years. We joked that we received callas from Nobel laureates who could find subatomic particles but couldn’t find the Windows Start button. My company is currently trying to rollout shared MCPs and skills throughout the company. The engineers who have been using AI tools for the past 1-2 years have few, if any, issues. The designers, product managers, and others have numerous issues. Having a single MCP gateway with very clear instructions for connecting to Claude Desktop and authenticating with Google eliminates numerous problems that would arise from installing and authenticating a CLI. The MCP is also available on mobile devices. I can jot down ideas and interact with real data with Claude iOS and the remote MCP. Can’t do that with a CLI.
- AussieWog93 8mo ago
  >CLI doesn’t work for your coworkers that aren’t technical. This actually isn't true. I've written bespoke CLI tools for my small business and non-technical people run them without issue. They get intimidated at first but within a day or so they're completely used to it - it's basically just magic incantations on a black box.
oneseventwonine 8mo ago
For the Agent to use CLI, don't we have to install CLI in the run-time environment first? Instead for the MCP over streamable HTTP we don't have to install anything and just specify the tool call in the context in't it?
- tptacek 8mo ago
  This rolls up to my original point. I get that if you stipulate the agent can't run code, you need some kind of systems solution to the problem of "let the agent talk to an API". I just don't get why that's a network protocol coupling the agent to the API and attempting to capture the shape of every possible API. That seems... dumb.
  - kasey_junk 8mo ago
    Environments where it’s hard to install and configure cli tools and where you want oauth flows. That is mcp for coding agents is dumb. For gui apps installed at non-cli using non-permissive endpoints it makes a lot of sense.
    - tptacek 8mo ago
      Right, this is the part of the problem I get, but a universal meta-API seems like they're overshooting it by a lot.
      - kasey_junk 8mo ago
        The argument that mcp is poorly designed is different than “just use cli” which is further different than mcp is a dead end. I agree mcp is bad as a protocol and likely not what solves the problem long term. But clearly the cli focus is an artifact of coding agents being the tip of the iceberg that we are seeing for llm agent use cases.
jabber86 8mo ago
I am creator of HasMCP (my response could have a little bias). Not everyone has home/work computer by preference mostly. I know a lot of people just use iPad or Android tablet in addition to their phone. They still use applications to work on the things. This number is not a small amount of people. They need to access openworld data or service specific data. This is where MCP is still the one of the best ways. It tries to standardize the auth, messaging, feedback loop where API can't do alone. A CLI app can do for sure but we are talking about a standard maybe the way is something like mcpcli that you can install your phone but still would you really prefer installing bunch of application to your personal device? Some points that MCP is still not good as of today: - It does not have a standard to manage context in a good way. You have to find your hack. The mostly accepted one search, add/rm tool. Another one is cataloging the tools. - lack of client tooling to support elicitation on many clients (it really hurts productivity but this is not solved with cli too) - lack of mcp-ui adoption (mcp-ui vs openai mcp app) I would suggest keep building to help you and your users. I am not sponsor of MCP, just sharing my personal opinion. I am also creator HasCLI but kindly biased for MCP then CLI in terms of coverage and standardization.
- troupo 8mo ago
  > It tries to standardize the auth, messaging, feedback loop where API can't do alone. If it tried to do that, you wouldn't have the pain point list. It's a vibe coded protocol that keeps using one-directional protocols for bi-directional communication, invents its own terms for existing stuff (elicitation lol), didn't even have any auth at the beginnig etc. It's a slow sad way of calling APIs with JSON-RPC
- CharlieDigital 8mo ago
  The biggest disappointment I have with MCP today is that many clients are still half-assed on supporting the functions outside of MCP tools. Namely, two very useful features resources and prompts have varying levels of support across clients (Codex being one of the worst). These two are possibly the most powerful ones since they allow consistent, org-level remote delivery of context and I would like to see all major clients support these two and eventually catch up on the other features like elicitation, progress, tasks, etc.
phpnode 8mo ago
no, it's all about auth. MCP lets less-technical people plug their existing tools into agents. They can click through the auth flow in about 10 seconds and everything just works. They cannot run CLIs because they're not running anything locally, they're just using some web app. The creator of the app just needed to support MCP and they got connectivity with just about everything else that supports MCP.
- tptacek 8mo ago
  Write better CLIs for the agents of the less-technical people. The MCPs you're talking about don't exist yet either. This doesn't seem complicated; MCP seems like a real dead end.
  - phpnode 8mo ago
    How are those CLIs being installed and run on hosted services? You'll need to sandbox them and have a way to install them automatically which seems difficult. How does the auth flow work? You'd need to invent some convention or write glue for each service. These are far more complicated than just using MCP, regardless of the benefits of the protocol itself.
    - krzyk 8mo ago
      If one doesn't sandbox agent run environment then there is a problem there already.
      - phpnode 8mo ago
        I think a big part of why this discussion is coming up again and again is that people assume the way they are using AI is universal, but there's a bunch of different ways to leverage it. If you have an agent which runs within a product it usually cannot touch the outside world at all by design, you do not need an explicit sandbox (i.e. a VM or container) at all because it lives in an isolated environment. As soon as you say "we use CLIs not MCP" well now you need a sandbox and everything else that goes along with it. If you can tell ahead of time what external connectors you need and you're already sandboxing then by all means go with CLIs, if you can't then MCP is literally the only economical and ergonomic solution as it stands today.
0xbadcafebee 8mo ago
A lot of the reasons to use MCP are contained in the architecture document (https://modelcontextprotocol.io/specification/2025-11-25/architecture https://modelcontextprotocol.io/specification/2025-11-25/arc...) and others. Among them, chief is security, but then there's standardization of AI-specific features, and all the features you need in a distributed system with asynchronous tasks and parallel operation. There is a lot of stuff that has nothing to do with calling tools. For any sufficiently complex set of AI tasks, you will eventually need to invent MCP. The article posted here talks about those cases and reasons. However, there are cases when you should not use MCP, and the article points those out too.
- tptacek 8mo ago
  If the chief reason to use MCP is security, I'm sold: it's a dead letter, and we're not going to be using it a couple years from now.
  - 0xbadcafebee 8mo ago
    Security is the chief reason in that it's the most important, since AI security is like nuclear waste. But the reason you should use it is it's a standard, and it's better to use one standard and be compatible with 10,000 apps, than have to write 10,000 custom integrations. When I first used ChatGPT, I thought, "surely someone has written some kind of POP3 or IMAP plugin for ChatGPT so it can just connect to my mail server and download my mail." Nope; you needed to write a ChatGPT-specific integration for mail, which needed to be approved by ChatGPT, etc. Whereas if they supported any remote MCP server, I could just write an MCP server for mail, and have ChatGPT connect to it, ask it to "/search_mail_for_string" or whatever, and poof, You Have Mail(tm).
- DetroitThrow 8mo ago
  >Among them, chief is security Considering many popular MCPs have done auth incorrectly, this made me lol
- troupo 8mo ago
  > Among them, chief is security The security is so chief that they had no security at all until several versions later when they hastily bolted on OAuth. MCP is a vibe-codef protocol that rode one of the many AI hype waves where all "design documents" are post-hoc justifications.
locknitpicker 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. That sounds like a hack to get around the lack of MCP. If your goal is to expose your tools through an interface that a coding agent can easily parse and use, what compels you to believe throwing amorphous structured text is a better fit than exposing it through a protocol specially designed to provide context to a model? > The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. I think you got it backwards. Early agents couldn't handle, and the problem was solved with the introduction of an interface that models can easily handle. It became a solved problem. Now you only argue that if today's models work hard enough, they can be willed into doing something with tools without requiring a MCP. That's neat, but a silly way to reinvent the wheel - poorly.
master_crab 8mo ago
Yes, this has been the gradual evolution of AI context and tooling. Same thing is occurring with some of the use cases of a vector DB and RAG. Once you can have the agent interact with the already existing conventional data store using existing queries, there is no point in introducing that work flow for inference.
MatthewPhillips 8mo ago
This limits AI usage to desktops, and mostly technical oriented tasks. MCP let's you connect to your email, shop, etc, from phone chat apps.
- bbkane 8mo ago
  I want CLIs for those too so I,a human, can use them

by tptacek 8mo ago

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.
  - jmogly 8mo ago
    OP never mentioned letting the agent run as him or use his secrets. All of the issues you mention can be solved by giving the agent it’s own set of secrets or using basic file permissions, which are table stakes. Back to the MCP debate, in a world where most web apis have a schema endpoint, their own authentication and authorization mechanisms, and in many instances easy to install clients in the form of CLIs … why do we need a new protocol, a new server, a new whatever. KISS
    - CharlieDigital 8mo ago
      > OP never mentioned letting the agent run as him or use his secrets That is implicit with a CLI because it is being invoked in the user session unless the session itself has been sandboxed first. Then for the CLI to access a protected resource, it would of course need API keys or access tokens. Sure, a user could set up a sandbox and could provision agent-specific keys, but everyone could always enable 2FA, pick strong passwords, use authenticators, etc . and every org would have perfect security. That's not reality.
- justboy1987 8mo ago
  [flagged]
otabdeveloper4 8mo ago
Just use a custom PATH and run in a chroot jail. CLI sandboxing is a solved problem compared to whatever MCP is.
krzyk 8mo ago
I don't think so. There is no MCP standard for authentication, our infosec banned MCP because of that.
- CharlieDigital 8mo ago
  It's right there in the docs and it's just OIDC + OAuth: https://modelcontextprotocol.io/specification/draft/basic/authorization https://modelcontextprotocol.io/specification/draft/basic/au...
  - dtraub 8mo ago
    While the spec includes OAuth 2.1 now, that's only half the story. The real question is where the credentials live. When your agent calls a CLI or curls an API, it uses credentials stored on the developer's machine. For one person that's fine. But for 50 agents across a department, each needing keys for Slack, Jira, GitHub, your CRM, and a dozen internal APIs? You've recreated the pre-SSO world, except access is autonomous and at machine speed. Remote MCP servers (streamable HTTP, not stdio) change that. The agent authenticates via OAuth/SSO, the server holds the downstream keys, and the user never sees them. Disable the SSO account and every agent loses access. This is the same pattern as centralizing database credentials instead of baking them into every microservice config, just on a different layer. Longer version: https://dev.to/dennistraub/missing-from-the-mcp-debate-who-holds-the-keys-when-50-agents-access-50-apis-mb3 https://dev.to/dennistraub/missing-from-the-mcp-debate-who-h...
    - CharlieDigital 8mo ago
      Yes; I made the same point in my write up. The auth story is heavily overlooked by most folks that are solo-vibing and then think that advice, the tools, and the practices that work for 1 works for a team or org.

harrall 8mo ago

CLI doesn’t work for your coworkers that aren’t technical. Have you tried to use a random API before? It’s a process of trial and error. With the MCP tools I use, it works the first time and every time. There is no “figuring out.”

mkoubaa 8mo ago
If you can't write a good CLI I doubt you could write a good MCP
JeremyNT 8mo ago
This should be trivial if you have proper API documentation in something like swagger. You can generate a cli tool with no "figuring out" anything either.
- clintonb 8mo ago
  Nothing is “trivial” when you combine humans and computers. I worked at the MIT Computing Help Desk during my undergraduate years. We joked that we received callas from Nobel laureates who could find subatomic particles but couldn’t find the Windows Start button. My company is currently trying to rollout shared MCPs and skills throughout the company. The engineers who have been using AI tools for the past 1-2 years have few, if any, issues. The designers, product managers, and others have numerous issues. Having a single MCP gateway with very clear instructions for connecting to Claude Desktop and authenticating with Google eliminates numerous problems that would arise from installing and authenticating a CLI. The MCP is also available on mobile devices. I can jot down ideas and interact with real data with Claude iOS and the remote MCP. Can’t do that with a CLI.
AussieWog93 8mo ago
>CLI doesn’t work for your coworkers that aren’t technical. This actually isn't true. I've written bespoke CLI tools for my small business and non-technical people run them without issue. They get intimidated at first but within a day or so they're completely used to it - it's basically just magic incantations on a black box.

oneseventwonine 8mo ago

For the Agent to use CLI, don't we have to install CLI in the run-time environment first? Instead for the MCP over streamable HTTP we don't have to install anything and just specify the tool call in the context in't it?

tptacek 8mo ago
This rolls up to my original point. I get that if you stipulate the agent can't run code, you need some kind of systems solution to the problem of "let the agent talk to an API". I just don't get why that's a network protocol coupling the agent to the API and attempting to capture the shape of every possible API. That seems... dumb.
- kasey_junk 8mo ago
  Environments where it’s hard to install and configure cli tools and where you want oauth flows. That is mcp for coding agents is dumb. For gui apps installed at non-cli using non-permissive endpoints it makes a lot of sense.
  - tptacek 8mo ago
    Right, this is the part of the problem I get, but a universal meta-API seems like they're overshooting it by a lot.
    - kasey_junk 8mo ago
      The argument that mcp is poorly designed is different than “just use cli” which is further different than mcp is a dead end. I agree mcp is bad as a protocol and likely not what solves the problem long term. But clearly the cli focus is an artifact of coding agents being the tip of the iceberg that we are seeing for llm agent use cases.

jabber86 8mo ago

I am creator of HasMCP (my response could have a little bias). Not everyone has home/work computer by preference mostly. I know a lot of people just use iPad or Android tablet in addition to their phone. They still use applications to work on the things. This number is not a small amount of people. They need to access openworld data or service specific data. This is where MCP is still the one of the best ways. It tries to standardize the auth, messaging, feedback loop where API can't do alone. A CLI app can do for sure but we are talking about a standard maybe the way is something like mcpcli that you can install your phone but still would you really prefer installing bunch of application to your personal device? Some points that MCP is still not good as of today: - It does not have a standard to manage context in a good way. You have to find your hack. The mostly accepted one search, add/rm tool. Another one is cataloging the tools. - lack of client tooling to support elicitation on many clients (it really hurts productivity but this is not solved with cli too) - lack of mcp-ui adoption (mcp-ui vs openai mcp app) I would suggest keep building to help you and your users. I am not sponsor of MCP, just sharing my personal opinion. I am also creator HasCLI but kindly biased for MCP then CLI in terms of coverage and standardization.

troupo 8mo ago
> It tries to standardize the auth, messaging, feedback loop where API can't do alone. If it tried to do that, you wouldn't have the pain point list. It's a vibe coded protocol that keeps using one-directional protocols for bi-directional communication, invents its own terms for existing stuff (elicitation lol), didn't even have any auth at the beginnig etc. It's a slow sad way of calling APIs with JSON-RPC
CharlieDigital 8mo ago
The biggest disappointment I have with MCP today is that many clients are still half-assed on supporting the functions outside of MCP tools. Namely, two very useful features resources and prompts have varying levels of support across clients (Codex being one of the worst). These two are possibly the most powerful ones since they allow consistent, org-level remote delivery of context and I would like to see all major clients support these two and eventually catch up on the other features like elicitation, progress, tasks, etc.

phpnode 8mo ago

no, it's all about auth. MCP lets less-technical people plug their existing tools into agents. They can click through the auth flow in about 10 seconds and everything just works. They cannot run CLIs because they're not running anything locally, they're just using some web app. The creator of the app just needed to support MCP and they got connectivity with just about everything else that supports MCP.

tptacek 8mo ago
Write better CLIs for the agents of the less-technical people. The MCPs you're talking about don't exist yet either. This doesn't seem complicated; MCP seems like a real dead end.
- phpnode 8mo ago
  How are those CLIs being installed and run on hosted services? You'll need to sandbox them and have a way to install them automatically which seems difficult. How does the auth flow work? You'd need to invent some convention or write glue for each service. These are far more complicated than just using MCP, regardless of the benefits of the protocol itself.
  - krzyk 8mo ago
    If one doesn't sandbox agent run environment then there is a problem there already.
    - phpnode 8mo ago
      I think a big part of why this discussion is coming up again and again is that people assume the way they are using AI is universal, but there's a bunch of different ways to leverage it. If you have an agent which runs within a product it usually cannot touch the outside world at all by design, you do not need an explicit sandbox (i.e. a VM or container) at all because it lives in an isolated environment. As soon as you say "we use CLIs not MCP" well now you need a sandbox and everything else that goes along with it. If you can tell ahead of time what external connectors you need and you're already sandboxing then by all means go with CLIs, if you can't then MCP is literally the only economical and ergonomic solution as it stands today.

0xbadcafebee 8mo ago

A lot of the reasons to use MCP are contained in the architecture document (https://modelcontextprotocol.io/specification/2025-11-25/architecture https://modelcontextprotocol.io/specification/2025-11-25/arc...) and others. Among them, chief is security, but then there's standardization of AI-specific features, and all the features you need in a distributed system with asynchronous tasks and parallel operation. There is a lot of stuff that has nothing to do with calling tools. For any sufficiently complex set of AI tasks, you will eventually need to invent MCP. The article posted here talks about those cases and reasons. However, there are cases when you should not use MCP, and the article points those out too.

tptacek 8mo ago
If the chief reason to use MCP is security, I'm sold: it's a dead letter, and we're not going to be using it a couple years from now.
- 0xbadcafebee 8mo ago
  Security is the chief reason in that it's the most important, since AI security is like nuclear waste. But the reason you should use it is it's a standard, and it's better to use one standard and be compatible with 10,000 apps, than have to write 10,000 custom integrations. When I first used ChatGPT, I thought, "surely someone has written some kind of POP3 or IMAP plugin for ChatGPT so it can just connect to my mail server and download my mail." Nope; you needed to write a ChatGPT-specific integration for mail, which needed to be approved by ChatGPT, etc. Whereas if they supported any remote MCP server, I could just write an MCP server for mail, and have ChatGPT connect to it, ask it to "/search_mail_for_string" or whatever, and poof, You Have Mail(tm).
DetroitThrow 8mo ago
>Among them, chief is security Considering many popular MCPs have done auth incorrectly, this made me lol
troupo 8mo ago
> Among them, chief is security The security is so chief that they had no security at all until several versions later when they hastily bolted on OAuth. MCP is a vibe-codef protocol that rode one of the many AI hype waves where all "design documents" are post-hoc justifications.

locknitpicker 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. That sounds like a hack to get around the lack of MCP. If your goal is to expose your tools through an interface that a coding agent can easily parse and use, what compels you to believe throwing amorphous structured text is a better fit than exposing it through a protocol specially designed to provide context to a model? > The reason we have MCP is because early agent designs couldn't run arbitrary CLIs. Once you can run commands, MCP becomes silly. I think you got it backwards. Early agents couldn't handle, and the problem was solved with the introduction of an interface that models can easily handle. It became a solved problem. Now you only argue that if today's models work hard enough, they can be willed into doing something with tools without requiring a MCP. That's neat, but a silly way to reinvent the wheel - poorly.

master_crab 8mo ago

Yes, this has been the gradual evolution of AI context and tooling. Same thing is occurring with some of the use cases of a vector DB and RAG. Once you can have the agent interact with the already existing conventional data store using existing queries, there is no point in introducing that work flow for inference.

MatthewPhillips 8mo ago

This limits AI usage to desktops, and mostly technical oriented tasks. MCP let's you connect to your email, shop, etc, from phone chat apps.

bbkane 8mo ago
I want CLIs for those too so I,a human, can use them