The main reason is that it adds another layer (and human) that can, and probably will, get out of sync with the real-world implementation, whether that implementation is an API, web, or a CLI.
AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use).
Sure, companies want to expose MCP servers because it is the cool thing to do right now.
So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc.
And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net.
So MCP feels more like a temporary workaround for current model limitations.
Or what else am I missing about why MCP is more secure than a CLI?
EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.
That’s how I use gh, aws, etc. No need to modify any of the code in the cli, they’re just wrappers.
Just use the existing sandboxing infrastructure like bubblewrap, seccomp, etc. I have way more faith in that than in something than some regex-based blocklist.
Nah. Just don't let your model do anything potentially destructive until three or four other models have vetted the proposed action.
Filtering individual commands can never provide more than the shallowest semblance of security. If a smart model is hellbent on deleting your production database, it will write its own Python program to do it if the usual commands are blocked.
rm -rf ~
but sandboxing in general is not an easy problem.
On unix, you can easily create a new user account, switch to it (or ssh or setup vnc), and run the tool there. If users are enough for servers on the internet, they can be for your workstation (unless there’s something like copyfail, but you can make do with a vm then).
WAP was dumb and failed because it oversimplified the web, and phones evolved to be real computers.
MCP is more sophisticated than typical APIs. It adds organization, policy, and code vs data (prompts) partitioning.
IMO it’s more likely that non-LLM apps will start using MCP than it is for MCP to go the way of WAP.
I was maybe 10/11 when the Nokia 3330 came out, and being able to use the internet while not in front of a computer just felt like magic
Why would it? Do you see any agents or models use that? No, instead vibe coders at Anthropic vibe-designed a bespoke protocol that sidesteps and ignores the last 60 years of API development and integrations.
Yes, MCP is a hack that could have been carefully built on prior art, and it would have been better for it.
Yes, MCP is capable of expressing that prior art, and you can do semantic web concepts even if the wire protocol looks different.
Reminds me a lot of Microsoft’s WS-disaster of the early 2000s except the latter was thought through a little better.
To be fair a while back I did design an API for a general purpose model trainer which was absolutely atrocious for a few reasons, my own ignorance was a factor but the problem of accommodating everything from “model that can be trained in 30 seconds on a small machine” to “model that takes 30 days of training on a cluster” problematized it.
It would have made so much more sense to build a standard for documenting ordinary API endpoints and CLIs.
That's at least my experience with my current project: the traditional json, coding oriented API feels out of place, I maintain it out of habit. The real API is the MCP server, which is not designed like a traditional API would; understandability of the output for an LLM prevails instead of searchng for exhaustiveness, orthogonality etc.
The reason I'm asking those questions is that a customer of mine has a service with a JSON API, a Vue frontend and a score of customers using that JSON API. We know that the newest ones are using bots to code their clients (and they are using them wrong, by the mistakes they do.) I don't see a near future in which all those third party apps become LLMs that would benefit from a MCP server and we retire the API.
But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.
It’s like saying APIs are dead because you can just use HTTP. They’re not the same thing, though of course you can hand-roll the higher layer in the lower one. It’s just more work, less standard, less valuable.
I don’t think models will ever prefer a low level API to a decorated index of API features and how to use them, same way developers will never prefer a list of HTTP endpoints and bespoke headers + query strings + POST bodies over a structured API.
It’s like asking why we needed browsers when we had BBSes; they serve a different but similar purpose and are build on different abstraction levels.
You have a client, the client uses the SDK, talks to endpoint x. Endpoint x tells it very efficient that they are now talking protobuf and rpc over quick or http15 and thats it.
Why don't we have this? Right because of people.
Its always people problem.
MCP is now here, it might stay.
Should it? I think it can be very useful to constrain what your AI can do (e.g. read files but don’t delete them). MCP is a way to do that.
For example try giving a local LLM read access to specific folders in your email account
LLMs are much more proficient with bash and --help than they are with bespoke API protocols.
Treat LLMs like you would a junior programmer - keep things as generic and obvious as you can.
I've heard this one before
(Maybe it'll be the first time that a temporary workaround stays around longer than expected then)
And you’ll also often see CISO-offices that are managed by checklists and yet more committees.
Asking for MCP access is generally easier than asking for an API for several reasons:
1. MCP supports OAuth, so your access conform with numerous CIS (et al) compliance checklists (short lived secrets, MFA, user-specific credentials, user access managed by centralised directory services and thus can have business rules applied, etc)
2. MCP is something a business can make a cooperate decision on. And then you can refer to that decision each time you need an access to new service. Whereas API access isn’t. In some cases APIs are governed by LLDs, and then you have an extra layer of “fun” having to update documentation to describe, in detail, the technical specifications too.
3. MCP defines the interaction better. If you need to request access to an API then the inevitable question from the committee is “where is this code running from?” and so on and so forth. Whereas saying “MCP access for AI to assist the project team with development” is a lot easier conversation to have.
In short: Enterprises are a very different beast to your average business.
Not everything in the real world will expose an MCP server so AI can interact with it.
Eventually, AI will need to move beyond MCP and interact with the real world the same way humans do: by observing, interpreting, reasoning, and taking action in messy, imperfect environments.
MCP tries to organize our messy word to make interaction part with the world easier in the near term, and it will help accelerate very early progress. But ultimately, MCP is a temporary bridge. Not the final destination.
I give it max 3 to 6 years and it will just die.
The menial task of updating the interfaces when the code changes is something AI should be really good at, so it's essentially little to no actual programmer time waste
> So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc.
> And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net.
Updating MCP by AI is one time effort.
Having AI re-create what MCP would do for every piece of code that uses a service is massively wasted effort in comparison
It's not question of "model limitation" but of cost effectiveness.
> And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net.
My reaction to this is.. really? Presumably your API and API docs have a release process. Hopefully an automated one. Why isn't the "hey Claude, update the MCP server" step a part of it?
It's adding another failure point to the process for no gain.
Overall, I am in favor of this goal. I'm not sure this is the protocol I'd choose to accomplish it, but it's the one people hear about, and the one they're using.
Agents are just making REST calls and that's it.
The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use.
'MCP' is frankly a hurdle.
Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe garners a bit more attention .
MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
It could very well entrench itself however.
* Internal services that never had real APIs are getting them retrofitted via the MCP layer
* MCP servers can run with dedicated service accounts that assume-role to a safe(r) subset of the calling user's permissions
The second one addresses a much deeper architectural chasm. We want to have our agents carry nearly-the-same-but-not-the-most-dangerous permissions as we do. No regulated business can risk unleashing agents with zero judgement capacity to wreck their systems, and on the other hand the existing identity systems are not geared for real-time dynamically adjusted user permissions. The need for so called "agent-aware IAM" is urgent. So instead of letting users connect to the internal APIs directly with their full suite of powers, MCP servers act as stand-ins for API gateways.
MCPs are not as flexible as full-fledged CLI tools, and that's a bit of a shame. But they can also become identity-aware proxies that enforce the intended permissions for agent-safe use. It will probably take years before IAM systems can adapt to the needs of the new world, and it will take another DECADE after that for the improved IAM systems to become universally available across the larger enterprises. So in a big way I agree with you:
> MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.
"Workable" is a load-bearing term. MCP servers are by no means perfect, but they are good enough for specific needs and allow to move the balancing point as needed while the world catches up.
I'm an engineer and prefer CLI or raw API access 99% of the time. But I also have decades of scars from infosec. The single biggest security threat for a business used to be an employee who could not get their job done. They found ways to work around the roadblocks. These days the single biggest threat is an employee who can not get their job done, but has an infinitely patient agent with vast latent capabilities at their disposal.
Corporate automations face the same problems human driven agents use:
+ The 'tool' section of the chat is not the right place, and it's too limiting + The very concept of MCP server introduces a brittle layer - for what purpose?
CLI for local calls, REST for remote.
That's it.
We build security around that the same way we would otherwise.
Now -> 'better / standard' json type calling for both of those!
Sure! 'Agent Calling API' or something. Yes.
'Agentic Identity Standard'? Yes to that as well.
But MCP was 'the right solution for a period in LLMs that has been superceded.
If MCP did not exist today - we would not invent it. That's the strongest argument I think.
I remember 10s of HN submissions where handlers were trying to get conversations about MCP going on HN back when there was almost nothing known about it and nothing to say.
It was always about tricking people into thinking there was authentic interest in it and it still is.
And to be blunt, a) you're investment bias'ed and b) whether you're selling the product (MCP) to a gazillion companies doesn't exactly disprove a).
Just look at Microsoft -- they've buried more technology than most, and there's little correlation between usefulness and how deeply buried it is, and some would claim that the correlation is _inverse_. Organisational factors are what drive them, just as I suspect they are now driving OpenAI's insistence on MCP. I understand it's hard to see that from inside.
Wow if that's not an echo-chamber comment I don't know what is.
Wouldn’t expect anything less from someone working as a manager at OpenAI. I don’t think their org culture is survivable if you’re not 200% all-in on LLMs eating the universe.
Like imagine somebody saying “you’re the most handsomest boy in the world” and thinking “Shit, nobody would just make something like that up.”
"Person working on MCP tools says MCP is not dead."
Also, what's the hold up? If they all are building one, presumably using AI, shouldn't they all be done already?
If all of these companies spent equivalent time writing a CLI for agents to consume as they spend on MCP servers, would they be any worse off in terms of agents being able to interact with their products?
Still easily doable with CLI
mostly, but not enough — i have been experimenting with this, and what i found to help is:
- help menu is the default, not an error message to stderr. ex: `gh pr` and `gh pr --help` are byte identical
- if the subcommand, or the options passed are wrong, present suggestions. ex: `gh gists` -> "Did you meant this? gist"
- the help menu should provide examples like `tldr`. sprites.dev tool `sprite` does this well, `gh` is in the training set so theirs is shorter
- can you append the docs url to the bottom of the help menu?
- you're serving llms.txt, right?So, OpenAPI/Swagger for REST? GraphQL? SOAP schemas? All of these (and more) exist. What does MCP add that these don't have?
Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills.
MCP also has a few other under utilized mechanisms: elicitation[2] on the client side and completions on the server side[3]. It is an API of sorts, but specialized for agent harness <-> server interactions.
[0] https://modelcontextprotocol.info/docs/concepts/prompts/
[1] https://modelcontextprotocol.info/docs/concepts/resources/
[2] https://modelcontextprotocol.io/specification/2025-11-25/cli...
[3] https://modelcontextprotocol.io/specification/2025-11-25/ser...
The tools we need to solve this problem exist and they are boring. Types, jsonschema, openapi, all of it is a better integration point than MCP.
An enterprise has 20 services that each have a secret key (Datadog, Snowflake, etc). I want my team to have access to those services via coding agents. How do I guard those keys from both developer and agent? Put it behind MCP; neither dev nor agent ever sees the key. If developer leaves, revoke one OAuth cred.
I want to add access to internal and external services from one entry point without developers across hundred of teams having to sync or update their workspace. Put it behind one MCP interface.
I have enterprise skills and resources that I want to standardize and deliver to every team. But it has to vary in 10-15% of the skill body. Think same heuristics, but different specifics. MCP delivered prompts and resources can do that by dynamically templating them.
I want telemetry and data on how skills and tools are being used and I want to capture them using standard tooling like OTEL regardless of agent harness because I don't want to have to rebuild a solution on hooks if I charge vendors. MCP does that because I can capture all of the telemetry there.
> jsonschema, openapi, all of it is a better integration point than MCP.
Your argument feels like asking why do we need OAuth and OIDC when we already have usernames and passwords. They solve different problems. A simple service can just use a secret key or username + password. But more complex enterprise scenarios need the structure and flow of OAuth, SAML, and SCIM.
Teams and enterprises had problems maintaining API keys long before there was MCP and they will have the same problems afterwards. The better teams and enterprises have had solutions for a long time.
And with people I guess I might actually mean not people but tokens everybody has to spend on keeping their environment self-adapting...
To make them interoperable so that the APIs have similar surface areas and can just be used without special skills, we could even come up with a standard API surface area and create a...protocol.
If you squint, the SKILL.md and the context that it takes up is literally the same thing as the MCP server and tool description. They are literally the same thing except one is server delivered and one is not.
MCP is "Let's use Google Sheets and have a server-managed experience". Everyone sees the same thing on the server in real time.
Skills is "Let me download the Excel and send it back to you". Why? How is this better? Every time I update the Excel, I have to add a `.2026.final.final2.xlsx` and everyone updates their copy...how is this the superior experience?
You could literally, deterministically, zero AI, code-gen a CLI from an MCP specification, just like you can with an OpenAPI specification. I'm sure tools exist that do this. So if you want a CLI, there it is.
But the problem with a CLI is that it requires a shell environment, and not everywhere you may want to run an agent should or can have access to a shell. MCP enables the harness to tightly control that access. MCP allows the user to easily allowlist/denylist specific tools, or categorize tools into "ask me every time" versus "don't ask me just do it". Doing any of this with a CLI is really hard because CLIs are all very different; yes, AIs can easily learn how to use them, but that might be exactly what you don't want, hey AI don't issue that aws ec2 delete-instance command ah crap there it goes I wish I could have just denylisted its access to that tool.
MCPs are impossible to combine this way: everything you feed or get from them goes though the model and consumes tokens.
Remember: jq can always be a tool (MCP or otherwise). In this way you can allowlist specific CLI programs and give them to the agent via tools. Making python a tool is more difficult; that would have all of the same RCE injection issues that the shell would have.
There are isolation stacks that help make “running an agent with a shell on behalf of a customer in the cloud” possible. It’s just very risky. There’s a thousand attack vectors, and to a very real degree companies that are getting to this point are re-thinking their cloud infrastructure and architecture from first principals.
I think the basic solution to this is to have a "static shell" but with modern tools for the agents, not actually executing other binaries. It could have things like jq, curl, piping and redirection to/from session files. Maybe even Python if it can be made safe. If not, then there are a lot of languages can be.
The more I read this thread the more I'm convinced that the main value of MCP is to provide a server managed release process. This is the same advantage that SaaS has over client side apps.
However MCPs couples with a client willing to run tools locally can provide the best of both worlds
It seems like there's little point in MCP in that case. Maybe more point if it was a standard mechanism for MCP to provide additional data, in a completely compatible fashion with all other tools? You could perhaps even pass such URLs to other MCPs. You could have an MCP for jq for doing stream processing. Starts to look a lot like a shell, though.
Seems like MCPs could also be extended to store auxiliary data to your memory (or filesystem..), and then an additional extension to provide that kind of data as auxiliary data in the calls to MCP.
Well, even as is, MCP still provides a standard method of using OAuth for accessing such services. And you must use MCP if you wish to add something to the ChatGPT.com web service, so it's easy to see why OpenAI folks are seeing companies going that way.
why not build this directly into MCPs?
Sounds a lot like a shell to me.
The second value is more about how business works. There is no chance you can convince someone at WalMart to fund and release a `wmctl` that allows you to search and buy products. Now try to convince your regional Pizza chain to release a CLI too. WalMart and such are incentivized however to create "Whatever OpenAI and Anthropic integrate with". Shopify can create an MCP for every shop and allow the shop owner to customize it. Creating a CLI per shop makes no sense. OpenAI and Anthropic prefer MCPs because of the first benefit. So it works out for all parties involved.
Is this an advantage? Phrased differently, every MCP that could have been a CLI call is a new opportunity for sandbox escape.
Edit: Maybe to clarify, I’m talking about remote MCP. Local MCP is obviously nonsensical. Remote MCP is very much thriving aggressively.
They have different tradeoffs.
MCP servers on the side of the consuming organizations fit into the existing IT landscape, with centralized safeguard on who can access what a lot better and are easier to administer than letting their employees run arbitrary agents against arbitrary sources and destinations and cause chaos.
Something like MCP is not a one time investment, the API's need to be maintained and updated regularly to be useful. Maintenance work is already a cost factor and no one gets promoted by maintaining anything.
Within organizations, smart carrier oriented folks are picking up this area of work for their personal growth and visibility which comes across as if every company is going for it.
I for one love MCP. It's way faster in my experience than skills / shell. And I like how (with Claude Code) I can setup the MCP in the web interface, use it in the chat and the CLI.
Plus the flow to add an MCP via the browser is achievable to any user.
And one thing I don't understand of skills is this. I have an MCP for my life organisation app that authorizes via OAuth. The flow is fully via the browser so I can use the app session and its stored somewhere in claude.ai. How does authentication work with skills?
Would pair well with direnv to set the right keys per project.
Here's some companies that offer MCP servers but don't seem to offer an equally featured CLI:
- Asana
- Square
- Linear
- Dropbox
- Canva
- Slack (sorta)
- Figma (sorta)
Should they all be offering CLI tools? IMHO, yes absolutely. But an MCP server gets much more interest. I'd rather encourage them to keep improving and supporting their MCP services than telling them to drop it for a CLI.
There's lots of things like this in technology where you end up stuck with the first thing because its popularity perpetuates itself. The QWERTY keyboard I'm typing this on is a prime example. x86 is another one.
IME, MCP has often lagged APIs in terms of complete ess, so as a user, if there was an API, I would be better off using that because Codex is already so good at calling APIs.
Now, the API story sucks for non-coders, but I'm not really bullish on MCP for dev tools atm.
"Everyone is building this!"
Except... Few are actually using it. So what, exactly, is the value in MCP?
Especially that there are simple ways for anyone to spin their own MCP based on standards like OAS. I talk to dozens of new clients in a given week. Our product should attract users who want MCP. And in the last month only one conversation actively asked us if we had an MCP server. Surprised, I asked about use case and the response was as I'd expect: "No specific use case, we're just playing around with it". Seems to be pretty standard for AI conversations these days.
That's just because no one knows what they're doing and everyone is trying to copy everyone else. It's a giant mud hut made of shit.
MCP will go away, and something much simpler will play the same role.
That’s covered in the article: a human can modify the commands generated by the agent, or vice versa, to debug problems or transfer knowledge.
This would allow us to deliver standard prompts across the team without having to sync manually or with scripts; keep everyone up to date. Even allow per-user customization of "skills" via server rendering of the prompts.
AFAIK, Codex is the only major harness to not support this.
[0] https://github.com/openai/codex/issues/5059#issuecomment-453...
CLIs live in the same namespace as the agent, so any secrets the CLI needs access to, the agent can also exfiltrate. And access control is lightly gated by the agent's tool call policy.
For an enterprise-level deployment, it becomes quickly desirable to have a centralized MCP backbone, on which each MCP is attached to. A place you can attach policies to, log activity, and reason about access control.
A sign of weariness in the rapid evolution of tooling, where people got off the train a stop too early?
A confusing overloaded acronym (cli) and term (skill) lacking the marketability / easy mind share of a unique acronym?
These all fail to establish a hearty reason to be.
The walking dead are still dead.
With saas is turned out that distribution to a browser solves a pretty major pain point and I expect MCPs to be treated the same. Can you trivially replace an MCP server with a CLI tool which accepts a token? Yes - but why do that to yourself when you can hit the endpoint directly?
Claude on the web does this. The only issue is controlling network access, which could be fixed by per-skill ACLs.
A skill's instructions can direct the LLM to call the CLI.
Claude skills can be installed into Claude web from a web browser. Those skills can then run on the Claude app on your phone.
The UX here isn't great, but let's assume it can be improved. How would auth work with this alternative method? I want to connect to Puma store and that's done using a skill with a CLI. Can the CLI launch your web browser to do oauth from the skill (on a phone)? And then the credentials are saved where?
Not challenging you, I'm open to alternatives to MCP for sure. But MCP seems way more mature especially for non-programming use-cases.
Can you clarify why the never? What's the issue with giving a phone-based AI a sandboxed file system and bash shell?
Right now you have to create an MCP but v1s are always easier to maintain than v10.
We're speed running a trap.
I find a lot of HN content seems to be doomer farming
i was a big skeptic of MCPs
now i build em
With just an API, the agent needs to "read your API docs" to know how to call it (that can be an OpenAPI spec or even just text).
With MCP, the agent sees a bunch of tools it can call, and they've been trained to call tools so they nail it.
One more very important factor is authorization, which no one seems to mention in these discussions. CLIs were made for humans and use primitive mechanisms for authorization: either an API key you hardcode in your environment, or they literally run a background HTTP Server to get a callback OAuth call to receive a token from a browser authentication flow. Incredible that people are happy with that, appparently. With the MCP Authorization spec, you solve authorization across multiple MCP servers in the same standardized way, the LLM client you use just need to know the protocol, not how to login for every single MCP server.
Very importantly, if the MCP client does the authorization, the MCP provider has auditability: is this a call from a human or from a LLM? That's important in Enterprise! People think it's ok to let an LLM act on behalf of the human but that will eventually bite a lot of people. Did the LLM just try to hack the API while you were mindlessly clicking "yes" when it asked if you wanted to let it do something? Tough luck, there's no way to distinguish an LLM making a mistake from a human maliciously running some attack.
And as the post mentions, there's also more benefits like being able to "elicit" user input (not just request/response cycles) and the ability to have documentation and assets (skills also have this though).
> to an LLM that can call tools (since MCP essentially turns an API into a LLM tool).
"Tools" is literally an API call
> With MCP, the agent sees a bunch of tools it can call,
Yes, the agent first calls a specific API that returns the schema for that particular server. It's literally the same.
> One more very important factor is authorization, which no one seems to mention in these discussions.
Yes, API calls to services are often gated behind auth. OAuth that MCP uses is from 2006, and its version 2 is from 2012. What do you think it was created for?
> the MCP provider has auditability: is this a call from a human or from a LLM? That's important in Enterprise
We had "differentiate these two accounts and audit log their activity" probably since the 1950s
> there's also more benefits like being able to "elicit" user input
Two-way communication is also a thing since the 1950s, probably.
> The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server.
You have drunk the kool aid. No shot ~every company is building an MCP server.
I think it's just a fad and eventually you'll need to address the math no matter how much you sugar coat it - the 3x slower metric, eating of context window is all beneficial for LLM companies but not for the end user.
Ok, how many AI tools do you even use from 3 years ago? Funnily enough, I stopped paying for my chatGPT subscription a year ago.
"Many of these companies don't even have an external API! And yet, they're all building MCP servers."
Whether or not MCP is a temporary means to an end or a more permanent standard is kind of missing the point that the overall callable API surface is expanding rapidly. How it's called by the agent is an implementation detail.
Its absolutely hilarious to me how tech people keep imagining that "this time it will be different".
This has been done 100 times before, it's COM, it's the remote Java object marketplace, it's the semantic web.
You are imaging a world where businesses are OK being marginalized into a nameless, faceless api provider with no control over their product. This will never happen. You might get a couple of years while they chase investment frenzy, but it will fragment. They will lock you out of their services. They will interact directly with their customers.
News at 11.
Didn’t ~every company also jump on blockchain and NFTs?
AI is a bandwagon tech, a lot of people will 'build because others are' adhering to an ostensible standard.
Most of the people that I know are moving away from MCP in favour of skills where the advantage of MCP goes away if the REST API is clear enough.
Also - I'm sorry to say but MCP management on Codex (and Claude) is just really bad. Everything from discovery, to management, to context window, to documentation - it feels unfinished as a 'feature' even if the protocol is supposed to be narrow.
1) I have a big popup and yellow warning every time a window is opened or a sub agent is launched warning me that 'SkySomething Computer Use' does not work. I had to Google to find out that has something to do with Codex MCP. So already the externalizations of problems, resolutions ... not very well done.
I'm not even sure what to do - and I'm honestly not interested in 'fixing' something I didn't cause, I'm not sure of, and don't want to deal with.
2) Just listing the current MCPs, knowing really what the are for (clearly, concisely) is hard.
This is what you get if you type /mcp in Codex:
/mcp
MCP Tools
• No MCP tools available.
• codex_apps
• Auth: Bearer token
• Tools: (none)
• computer-use
• Auth: Unsupported
• Tools: (none)
As presented - it resolves to 'nonsense gibberish'. Those are things that I did not even install.
Do you expect people magically know what 'codex_apps' is?
Here is what 'AGI!' Codex 5.5 answered when I asked about 'codex_apps' is:
====
" codex_apps appears to be Codex’s own internal cache/tooling area, not part of J1 (my project).
"I only found it under .codex, e.g.:"
" I did not find it referenced by the J1 source. So unless you saw it somewhere specific, treat it as Codex runtime metadata for app/tool integration, not project code."
====
So even Codex itself has no idea what it's own MCP tools are, and after a full '1 minute of thinking' on 'xhigh' it responded with nonsense.
This whole experience fundamentally deflates my perception of AU, OpenAI, Codex and MCP.
This is supposed to be the 'future' but it feels like 1982 dialup.
This is where 'traditional UX' really starts to show it's value obviously, but you really need to consider enhancing this experience, possibly with some traditional ux mechanisms.
3) Knowing the 'state' of the MCP is totally opaque. Is the 'MCP server' running? Can I restart it? That might be outside the scope of 'Codex' but you're offering the product so all of the underlying stuff is essentially 'your responsibility' as well at least from a UX perspective. Why isn't the 'state' of the MCP listed.
4) How can I not just easily enable/disable individual MCPs so they don't chew up context?
5) How can I not discover MCPs from codex itself, so that I can find solutions to problems? MCPs are all a bit different, and awkward to install and manage. Like with VS Code, we can 'discover plugins'. Even from the Web we can search and discover plugins.
While I realize that most of this rant is oriented around MCP tooling management, and not the standard, I do feel that these issues are 'fundamentally at the crux' of the situation.
Our team has moved away from MCP into Skills - and after doing so, it's hard to see why MCP is going to be valuable - other than plausibly as defining some 'jon calling conventions'.
There's a lot of obvious things to improve, please do that.
That the 'smartest people in the world' have $100 Billion and are are totally scattered on so many issues completely blows my mind but it speaks to how systems are organized.
They don't need to hire anyone for this stuff, they need to have some basic product discipline and prioritize it, that's all.
If they don't do that, all the money in the world and all the best product people wouldn't be able to help.
I totally respect that 'Codex is young' - but it's been kind of a year now. That's a long time - and AI is supposed to 'accelerate time scales' and make people 'super productive' remember?
I hope they improve.
Haven’t we devs always dreamt of a common interface to query and introspect foreign APIs? Aren’t we lucky we stumbled into an “AI” that is founded upon human language and not some incomprehensible machine code? It seems to me LLMs only made the need for such a universality attractive. Such as so many circumstances where we will do things for our progeny which we would not (yet should have) done for ourselves !
I’ve felt the same thing about skills files, the first things juniors or onboarders should read to explicitly understand their own jobs!
As in: if your models and agents were as good as you claim them to be, we wouldn't need to re-implement half if our tools and a significant chunk of the web to conform to this vibe designed protocol.
In 99% of cases your AI agents already have all the access. They are just too stupid to do so.
Jane #2: "We're not a cult. We're an organization that promotes love and—"
Hank Hill: "Yeah, this is it."
I might be biased because I came up with it, but we are over complicating these systems. There is a simpler way, and it appears to work well since I built a system using it to test the idea.
- I think the comparison to TCP/DNS/BGP is the more apt one compared to MCP/A2A
- Those protocols negotiate capabilities and exchange information about themselves, but not in a self-serving manner of just talking about themselves, but with the goal of ultimately transporting data for a higher layer. Ask Protocol lacks that.
- Objects don't exist in a vacuum, but in a context. As the objects will only know about themselves they will always be limited in how to describe themselves best. An LLM that lives on the outside and just gets a static description of an object will be in a much better description to answer an "ask" query.
- Given that the existing agent protocols you are putting it in a context in already come with "description" fields and the like, the protocol seems too little of a value add to actually target. e.g. there is no benefit for a MCP server to conform to the prescribed manifest rather than implementing a freeform "ask" tool.
- If you want to actually bring the point across that it "occupies a different position" than transport/agent protocols, don't put it into a comparison matrix where you force it into the same schema
- ("Open Source" doesn't count as governance)
I work at Taco Bell. Every company on earth is working on Doritos Locos Tacos. I know this because I interact with every company on the planet, and they all tell me that Doritos Locos is in their development pipeline. When I see all of these “not everybody eats or wants Doritos Locos” posts I know that they are wrong because the appeal of them is universal, especially when paired with Baja Blast, mankind’s foremost favorite fluid
[1] “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” ― Upton Sinclair, I, Candidate for Governor: And How I Got Licked