11 ms·

I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP. The thing that all these "MCP is dead" posts are miss

by mxstbr 4mo ago

I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP. The thing that all these "MCP is dead" posts are missing is that whether or not MCP is used as a transport protocol is actually completely irrelevant. The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Most of these companies don't have a CLI. Many of these companies don't even have an external API! And yet, they're all building MCP servers. And that's why MCP is not only not dead, but more important than ever. Maybe we will turn every MCP server into a CLI under the hood. Maybe we'll use code mode. Maybe we'll implement tool search. All of those are just implementation details to the much more important point: our AI agents are getting access to services they otherwise would never have had access to.[0] That's what matters. So, is MCP dead as a direct communication layer for models to speak to? Maybe, maybe not. Is MCP dead as a protocol? Hell no, couldn't be further from the truth. [0]: Although I will say the Codex app's computer & browser use features have made this statement a lot weaker than it used to be. If you haven't tried them yet—they're mindblowing.

alexwwang 4mo ago
I agree. Mcp might be useless in a personal scenario but it absolutely plays a role of service infrastructure in organizations. It is another form of api for those abilities that are not wrapped with rest api yet. But when they are wrapped in mcp, it seems not necessary to wrap them into rest api or cli again in near future. So these mcp services survive. The only thing matters is how to import these mcp services into agent context on demand or say by the gradual disclosure principle.
- jimbokun 4mo ago
  Unless you also want humans to also interact with your tools. 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.
  - alexwwang 4mo ago
    This, IMO, is another scenario. MCP is designed and played as a part of the automatic tool chains. These are two different types of needs. But in the case you mentioned, when some parts of the work should be automated, it’s also possible to utilize mcp there.
bluegatty 4mo ago
It's not 'who is building' but 'who is using' that's the concern. 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) What's that supposed to mean? What is 'codex_apps'? 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.
deleted 4mo ago
[deleted]
jimbokun 4mo ago
You failed to describe what value the MCP protocol provides. 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?
- cle 4mo ago
  The security model and runtime requirements are completely different between making an HTTP request and executing arbitrary code. They have different tradeoffs.
  - lostmsu 4mo ago
    You nailed it! There are established tools that handle the security model. MCP is the 5th leg.
- fnordpiglet 4mo ago
  One advantage is the MCP advertises itself to the agent with its schema and api shape. Unless your CLI is in the corpus with lots of examples the agent has to learn every time. Skills help a little bit but I find the recall on skills pretty low. However I also find codex will reliably use MCPs advertised while Claude always reaches for tools like Bash() likely because it’s aligned so heavily on its own tools and is very hard to get to use an MCP if literally any Bash() approach is possible, including breaking glass to find creds, even when an MCP is clearly advertised in CLAUDE.md, skills, and explicit user instruction. I find it fascinating that Anthropic makes a product that seems to be really poor at following instructions and OpenAI seems to generally follow guard rails.
  - dnautics 4mo ago
    i mean you can surface an openapi schema too.
    - CharlieDigital 4mo ago
      MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two. 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/ https://modelcontextprotocol.info/docs/concepts/prompts/ [1] https://modelcontextprotocol.info/docs/concepts/resources/ https://modelcontextprotocol.info/docs/concepts/resources/ [2] https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation https://modelcontextprotocol.io/specification/2025-11-25/cli... [3] https://modelcontextprotocol.io/specification/2025-11-25/server/utilities/completion https://modelcontextprotocol.io/specification/2025-11-25/ser...
tulio_ribeiro 4mo ago
What’s up with case 09058169? Seems like a 5 minute fix
ford 4mo ago
Basically MCP is little more than a brand name for "APIs LLM's can use". This means more services are creating APIs, because xyz company who's never been super tech forward doesn't want their tools to be obsolete when everyone uses agents. 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.
- throwpoaster 4mo ago
  I suggest you implement an MCP server before adopting this as a firm technical opinion.
  - lazyasciiart 4mo ago
    The opinion that more companies creating APIs is good?
    - throwpoaster 4mo ago
      No, the technical opinion. MCP is an interesting integration pattern. Calling it "more APIs" is like calling software "just some code". It's true, not interesting.
- bluegatty 4mo ago
  "and the one they're using." no it's not. 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.
  - Aperocky 4mo ago
    It's that extra amazon box that wrap the actual box that wrap the thing you ordered. Except you're doing the wrapping.
mettamage 4mo ago
Based on the corporate I work, MCP is definitely not that. Not sure if it's useful, I just joined. We'll see.
goalieca 4mo ago
What do you think about MCP security being limited as it is. Frankly, it seems mathematically impossible.
CharlieDigital 4mo ago
It would be really, really great if Codex could support MCP Prompts[0] 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-4536967925 https://github.com/openai/codex/issues/5059#issuecomment-453...
ProAm 4mo ago
No offense but you are paid to say these things. Your paycheck depends on it [1] [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
julianlam 4mo ago
> The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Wow if that's not an echo-chamber comment I don't know what is.
- OtherShrezzing 4mo ago
  It’s definitely an outlandish statement to make. There’s 200-400mn companies in the world on a conservative estimate. I assume the poster means something like “all listed companies”.
- sevenzero 4mo ago
  Yup agreed, this reads like massive coping...
- jrflowers 4mo ago
  Trying to imagine my boss telling me that I’ve talked to everyone on earth in a convincing way and can’t stop laughing Like imagine somebody saying “you’re the most handsomest boy in the world” and thinking “Shit, nobody would just make something like that up.”
- shabgzer 4mo ago
  Resist the urge to nitpick and accept that the poster simply means "a large number of high-profile companies".
- tvink 4mo ago
  Yeah this is copium. Everyone is sprinting to adopt everything that is useful, and it just haven't happened with MCP. Also, what's the hold up? If they all are building one, presumably using AI, shouldn't they all be done already?
- rvz 4mo ago
  The comment just reads to me as: "Person working on MCP tools says MCP is not dead."
  - 4mo ago
bshaughn 4mo ago
The number one value of MCP's is that it forced everyone align on an API protocol, but the protocol itself has room for improvement.
jngiam1 4mo ago
I totally agree, we’ve been working with enterprises and MCP is the defacto way they are using agents with data.
tlogan 4mo ago
I would bet that MCP is going to die. 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.
- rixed 4mo ago
  Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained. 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.
  - pmontra 4mo ago
    Interesting points. A couple of questions. Do you have a frontend (React, Vue, anything) and if you do, does it interact with the server using the MCP server or the JSON API? Are all your clients AIs or do you expect that most of them will be AIs? 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.
jrflowers 4mo ago
> practically ~every company on the planet is building an MCP server 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
mempko 4mo ago
Have you heard of the Ask Protocol? (https://abject.world/ask-protocol/ https://abject.world/ask-protocol/). 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.
- hobofan 4mo ago
  Main points that came to my mind: - 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)
  - mempko 4mo ago
    You made some good points, let me address them. The reason comparing to TCP, DNS doesn't make sense is this doesn't replace those at all. The reason I compared against other agent frameworks and things like MCP is because that's the common question people have. You are right objects don't exist in a vacuum but you are wrong an object that just exposes a description and an LLM reading it from the outside does better. Think about object oriented programming, objects expose and interface but don't reveal all of their internals. Calling the Ask handler could change internal state. Maybe response depends on what object is asking. Maybe the Ask handler might want to call the callers Ask handler too. You can't do that by just exposing a description. You said the goal is to ultimately transport data to a higher layer. That's not the goal. You are thinking too hierarchical. The relationships between objects is dynamic and the concept of a higher layer makes no sense here since the point is to get rid of the hierarchical nature current agent protocols have. Keep in mind I built a working system to test the concept. You can download and try it.
zuzululu 4mo ago
great post I find a lot of HN content seems to be doomer farming i was a big skeptic of MCPs now i build em
- geysersam 4mo ago
  What advantage did you find in MCP vs a traditional API?
  - brabel 4mo ago
    No OP, but MCP really is just a logical next step once you've got an API. The API is the "low level" protocol, the MCP is the high level one, suited perfectly to an LLM that can call tools (since MCP essentially turns an API into a LLM tool). 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).
    - troupo 4mo ago
epsteingpt 4mo ago
Agree. But Word of caution: MCP will become the 'company wiki' of the 2020s unless you enable monetization and distribution. Right now you have to create an MCP but v1s are always easier to maintain than v10. We're speed running a trap.
meszmate 4mo ago
A lot of companies will never build a great CLI, and many will not prioritize a clean public API unless there is obvious demand.
xeiotos 4mo ago
On browser/computer use: I wish I could try them. But since OpenAI is going down the Apple path of cherry-picking random features to block in the EEA, without much explanation or timeline as to when they will be available (or even why they are blocked in the first place), I am unsure if I will be able to in this lifetime.
the_gipsy 4mo ago
Hank Hill: "Excuse me, are y'all with the cult?" Jane #2: "We're not a cult. We're an organization that promotes love and—" Hank Hill: "Yeah, this is it."
robotswantdata 4mo ago
I agree, codex app’s computer use agent feels sci-fi. Closest we’ve seen yet of a general purpose virtual worker.
baq 4mo ago
MCP vs CLI is the same discussion as between a GUI app and a web app: it's all about the distribution. There is approximately no difference in functionality except whether you're hitting a dedicated service or running a local tool which connects to a dedicated service. 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?
bredren 4mo ago
Isn’t this just a lagging indicator of popularity at the early liftoff of cli ai? 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.
j45 4mo ago
Maybe MCP doesn't have to be the entire or only solution, or judged as such, and another tool in the toolkit.
coderbants 4mo ago
I get the debate in this thread but this is IMHO the detail that matters: "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.
Aldipower 4mo ago
Off-topic question: Where is this an "App Store", as this is basically just a curated list off apps? I wouldn't exactly call it a "store". I have an approved ChatGPT App myself, but those do not surface anyway on the chatgpt.com domain. So, this isn't a "store", but a "curated directory". Calling this a store is misleading to a lot of us developers as you can see in the openai forums on this topic, where you find a lot of confusion around this. People put a lot of energy into developing a ChatGPT App, just to find out, they are completely on their own afterwards.
gobdovan 4mo ago
Remember when practically ~every company on the planet was building an NFT collection?
neya 4mo ago
Just because everyone builds it doesn't mean it will take off. Case in point: All the cloud serverless BS. Everyone in the industry are now switching back from server less because the math didn't work out. 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.
MatthewPhillips 4mo ago
Please keep in mind that CLIs do not run on mobile and never will. This is the elephant in the room that nearly everypne seems to be ignoring. This "debate" is built around the assumption that AI is only for at-your-desk work. It's obviously not. Having the ability to mix/match the services you use for everything in your life, whether that's email or social networks or managing your book collection, is going to be a normal thing everyone does in the future. It's just not today, because AI companies are almost exclusively focused on the programming use-case (and related desk job stuff).
- falcor84 4mo ago
  > CLIs do not run on mobile and never will Can you clarify why the never? What's the issue with giving a phone-based AI a sandboxed file system and bash shell?
  - MatthewPhillips 4mo ago
    How is the user installing the CLIs? Proprietary app store for each chat app?
    - falcor84 4mo ago
      I didn't mean that users would install them. I meant that if mcp and AI agents continue being popular, then Google and Apple could choose to provide apps with cli sandboxes with the proper permissions. It is a big change, but I just didn't understand the "never"; we've had bigger changes.
      - MatthewPhillips 4mo ago
        Ok sure, the "never" was a bit strong here. Running CLIs on phones is not a normal thing and not as simple as it is on desktop. Apple prohibits apps from downloading and executing code, so some sort of new Apple-approved thing would be required here. That's a very heavy lift. Of course anything is possible, I just don't think that people advocating for MCP's death have really thought through these problems, and are mostly focused on the desktop productivity use-cases.
docheinestages 4mo ago
Agreed. I think MCP should stay abstract in the sense tool-calling is. JSON-RPC could be one way to do it.
noworriesnate 4mo ago
I think graphql backed by mcp is the technically best solution. Graphql allows an agent to select which fields it wants in context. Graphql is easy to generate clis for / easy to generate libraries for (if we want llms to generate scripts that call tools).
- zingar 4mo ago
  GraphQL also allows the LLM to DOS your service
- deleted 4mo ago
  [deleted]
bmitc 4mo ago
MCP is not an answer to the lack of a CLI or API.
sd9 4mo ago
> I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP. > 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.
- zingar 4mo ago
  It was obvious hyperbole. I can believe that there are many companies where the boss heard about MCP and put it on a roadmap before anthropic decided that it wasn’t a good idea… and now the team is implementing this in the name of “we need to do some AI”
troupo 4mo ago
> All of those are just implementation details to the much more important point: our AI agents are getting access to services they otherwise would never have had access to. 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.
yepyoukno 4mo ago
What is so very strange is that MCP is what we have always wanted, for ourselves! 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!
qsxfthnkp2322 4mo ago
Mcp is not dead says the guy who gets paid half a million to work on it. News at 11.
zimbatm 4mo ago
Another aspect is access control. 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.
- delusional 4mo ago
  To the extent this is true, and it isn't with setuid binaries, it's a limitation of operating system apis.
croes 4mo ago
> The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. Didn’t ~every company also jump on blockchain and NFTs?
delusional 4mo ago
> Maybe we will turn every MCP server into a CLI under the hood. Maybe we'll use code mode. Maybe we'll implement tool search. 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.
btbuildem 4mo ago
> practically ~every company on the planet is building an MCP server 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.
windexh8er 4mo ago
This is a classic PM take IMO, no disrespect. "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.
Eridrus 4mo ago
You should probably consider that your perspective is also biased and you see all the companies that are in esting. 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.
hackrmn 4mo ago
The point is that MCP solves a problem that doesn't _really_ exist. While consuming context, which is still at a premium. Claiming that services wouldn't be accessible to agents without MCP is at best misleading -- they certainly do [have access] through exactly what article sheds light on -- command-line tools, including but not limited to, input and output of said tool(s). Also, from a purely technical standpoint, MCP is "non-compositional" compared to command-line tools, and those who don't value composition are IMO doomed to discover so at their own peril, sooner or later. 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.
mikecwang 4mo ago
So because people are doing it, it's the right thing to keep? There is a long way to go before we know the shape of the real solution. Don't let things like MCP slow down the exploration
KaiShips 4mo ago
[flagged]
imp0cat 4mo ago
Got any tips for building a MCP over CLI app?
listless 4mo ago
Oh man - hearing that we’re building MCP’s where there is no CLI makes me super nervous. It’s one thing to dupe the functionality of your CLI for better agent integration. It’s another to make it the sole method of interface locking everyone into a spec that we may decide we can do better at some point. Then we gotta pay off all the MCP debt and it will be cheaper to just not.
mycall 4mo ago
Wouldn't it be easier if MCP supported vector embeddings as input/output? It would shift its integration from a Broker Agent to a Deterministic Semantic Router. That by itself would prevent context bloat.

by mxstbr 4mo ago

alexwwang 4mo ago

I agree. Mcp might be useless in a personal scenario but it absolutely plays a role of service infrastructure in organizations. It is another form of api for those abilities that are not wrapped with rest api yet. But when they are wrapped in mcp, it seems not necessary to wrap them into rest api or cli again in near future. So these mcp services survive. The only thing matters is how to import these mcp services into agent context on demand or say by the gradual disclosure principle.

jimbokun 4mo ago
Unless you also want humans to also interact with your tools. 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.
- alexwwang 4mo ago
  This, IMO, is another scenario. MCP is designed and played as a part of the automatic tool chains. These are two different types of needs. But in the case you mentioned, when some parts of the work should be automated, it’s also possible to utilize mcp there.

bluegatty 4mo ago

It's not 'who is building' but 'who is using' that's the concern. 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) What's that supposed to mean? What is 'codex_apps'? 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.

deleted 4mo ago

[deleted]

jimbokun 4mo ago

You failed to describe what value the MCP protocol provides. 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?

cle 4mo ago
The security model and runtime requirements are completely different between making an HTTP request and executing arbitrary code. They have different tradeoffs.
- lostmsu 4mo ago
  You nailed it! There are established tools that handle the security model. MCP is the 5th leg.
fnordpiglet 4mo ago
One advantage is the MCP advertises itself to the agent with its schema and api shape. Unless your CLI is in the corpus with lots of examples the agent has to learn every time. Skills help a little bit but I find the recall on skills pretty low. However I also find codex will reliably use MCPs advertised while Claude always reaches for tools like Bash() likely because it’s aligned so heavily on its own tools and is very hard to get to use an MCP if literally any Bash() approach is possible, including breaking glass to find creds, even when an MCP is clearly advertised in CLAUDE.md, skills, and explicit user instruction. I find it fascinating that Anthropic makes a product that seems to be really poor at following instructions and OpenAI seems to generally follow guard rails.
- dnautics 4mo ago
  i mean you can surface an openapi schema too.
  - CharlieDigital 4mo ago
    MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two. 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/ https://modelcontextprotocol.info/docs/concepts/prompts/ [1] https://modelcontextprotocol.info/docs/concepts/resources/ https://modelcontextprotocol.info/docs/concepts/resources/ [2] https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation https://modelcontextprotocol.io/specification/2025-11-25/cli... [3] https://modelcontextprotocol.io/specification/2025-11-25/server/utilities/completion https://modelcontextprotocol.io/specification/2025-11-25/ser...

tulio_ribeiro 4mo ago

What’s up with case 09058169? Seems like a 5 minute fix

ford 4mo ago

Basically MCP is little more than a brand name for "APIs LLM's can use". This means more services are creating APIs, because xyz company who's never been super tech forward doesn't want their tools to be obsolete when everyone uses agents. 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.

throwpoaster 4mo ago
I suggest you implement an MCP server before adopting this as a firm technical opinion.
- lazyasciiart 4mo ago
  The opinion that more companies creating APIs is good?
  - throwpoaster 4mo ago
    No, the technical opinion. MCP is an interesting integration pattern. Calling it "more APIs" is like calling software "just some code". It's true, not interesting.
bluegatty 4mo ago
"and the one they're using." no it's not. 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.
- Aperocky 4mo ago
  It's that extra amazon box that wrap the actual box that wrap the thing you ordered. Except you're doing the wrapping.

mettamage 4mo ago

Based on the corporate I work, MCP is definitely not that. Not sure if it's useful, I just joined. We'll see.

goalieca 4mo ago

What do you think about MCP security being limited as it is. Frankly, it seems mathematically impossible.

CharlieDigital 4mo ago

It would be really, really great if Codex could support MCP Prompts[0] 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-4536967925 https://github.com/openai/codex/issues/5059#issuecomment-453...

ProAm 4mo ago

No offense but you are paid to say these things. Your paycheck depends on it [1] [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

julianlam 4mo ago

> The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. I know this because we interact with all of them. Wow if that's not an echo-chamber comment I don't know what is.

OtherShrezzing 4mo ago
It’s definitely an outlandish statement to make. There’s 200-400mn companies in the world on a conservative estimate. I assume the poster means something like “all listed companies”.
sevenzero 4mo ago
Yup agreed, this reads like massive coping...
jrflowers 4mo ago
Trying to imagine my boss telling me that I’ve talked to everyone on earth in a convincing way and can’t stop laughing Like imagine somebody saying “you’re the most handsomest boy in the world” and thinking “Shit, nobody would just make something like that up.”
shabgzer 4mo ago
Resist the urge to nitpick and accept that the poster simply means "a large number of high-profile companies".
tvink 4mo ago
Yeah this is copium. Everyone is sprinting to adopt everything that is useful, and it just haven't happened with MCP. Also, what's the hold up? If they all are building one, presumably using AI, shouldn't they all be done already?
rvz 4mo ago
The comment just reads to me as: "Person working on MCP tools says MCP is not dead."
- 4mo ago

bshaughn 4mo ago

The number one value of MCP's is that it forced everyone align on an API protocol, but the protocol itself has room for improvement.

jngiam1 4mo ago

I totally agree, we’ve been working with enterprises and MCP is the defacto way they are using agents with data.

tlogan 4mo ago

I would bet that MCP is going to die. 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.

rixed 4mo ago
Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained. 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.
- pmontra 4mo ago
  Interesting points. A couple of questions. Do you have a frontend (React, Vue, anything) and if you do, does it interact with the server using the MCP server or the JSON API? Are all your clients AIs or do you expect that most of them will be AIs? 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.

jrflowers 4mo ago

> practically ~every company on the planet is building an MCP server 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

mempko 4mo ago

Have you heard of the Ask Protocol? (https://abject.world/ask-protocol/ https://abject.world/ask-protocol/). 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.

hobofan 4mo ago
Main points that came to my mind: - 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)
- mempko 4mo ago
  You made some good points, let me address them. The reason comparing to TCP, DNS doesn't make sense is this doesn't replace those at all. The reason I compared against other agent frameworks and things like MCP is because that's the common question people have. You are right objects don't exist in a vacuum but you are wrong an object that just exposes a description and an LLM reading it from the outside does better. Think about object oriented programming, objects expose and interface but don't reveal all of their internals. Calling the Ask handler could change internal state. Maybe response depends on what object is asking. Maybe the Ask handler might want to call the callers Ask handler too. You can't do that by just exposing a description. You said the goal is to ultimately transport data to a higher layer. That's not the goal. You are thinking too hierarchical. The relationships between objects is dynamic and the concept of a higher layer makes no sense here since the point is to get rid of the hierarchical nature current agent protocols have. Keep in mind I built a working system to test the concept. You can download and try it.

zuzululu 4mo ago

great post I find a lot of HN content seems to be doomer farming i was a big skeptic of MCPs now i build em

geysersam 4mo ago
What advantage did you find in MCP vs a traditional API?
- brabel 4mo ago
  No OP, but MCP really is just a logical next step once you've got an API. The API is the "low level" protocol, the MCP is the high level one, suited perfectly to an LLM that can call tools (since MCP essentially turns an API into a LLM tool). 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).
  - troupo 4mo ago

epsteingpt 4mo ago

Agree. But Word of caution: MCP will become the 'company wiki' of the 2020s unless you enable monetization and distribution. Right now you have to create an MCP but v1s are always easier to maintain than v10. We're speed running a trap.

meszmate 4mo ago

A lot of companies will never build a great CLI, and many will not prioritize a clean public API unless there is obvious demand.

xeiotos 4mo ago

On browser/computer use: I wish I could try them. But since OpenAI is going down the Apple path of cherry-picking random features to block in the EEA, without much explanation or timeline as to when they will be available (or even why they are blocked in the first place), I am unsure if I will be able to in this lifetime.

the_gipsy 4mo ago

Hank Hill: "Excuse me, are y'all with the cult?" Jane #2: "We're not a cult. We're an organization that promotes love and—" Hank Hill: "Yeah, this is it."

robotswantdata 4mo ago

I agree, codex app’s computer use agent feels sci-fi. Closest we’ve seen yet of a general purpose virtual worker.

baq 4mo ago

MCP vs CLI is the same discussion as between a GUI app and a web app: it's all about the distribution. There is approximately no difference in functionality except whether you're hitting a dedicated service or running a local tool which connects to a dedicated service. 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?

bredren 4mo ago

Isn’t this just a lagging indicator of popularity at the early liftoff of cli ai? 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.

j45 4mo ago

Maybe MCP doesn't have to be the entire or only solution, or judged as such, and another tool in the toolkit.

coderbants 4mo ago

I get the debate in this thread but this is IMHO the detail that matters: "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.

Aldipower 4mo ago

Off-topic question: Where is this an "App Store", as this is basically just a curated list off apps? I wouldn't exactly call it a "store". I have an approved ChatGPT App myself, but those do not surface anyway on the chatgpt.com domain. So, this isn't a "store", but a "curated directory". Calling this a store is misleading to a lot of us developers as you can see in the openai forums on this topic, where you find a lot of confusion around this. People put a lot of energy into developing a ChatGPT App, just to find out, they are completely on their own afterwards.

gobdovan 4mo ago

Remember when practically ~every company on the planet was building an NFT collection?

neya 4mo ago

Just because everyone builds it doesn't mean it will take off. Case in point: All the cloud serverless BS. Everyone in the industry are now switching back from server less because the math didn't work out. 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.

MatthewPhillips 4mo ago

Please keep in mind that CLIs do not run on mobile and never will. This is the elephant in the room that nearly everypne seems to be ignoring. This "debate" is built around the assumption that AI is only for at-your-desk work. It's obviously not. Having the ability to mix/match the services you use for everything in your life, whether that's email or social networks or managing your book collection, is going to be a normal thing everyone does in the future. It's just not today, because AI companies are almost exclusively focused on the programming use-case (and related desk job stuff).

falcor84 4mo ago
> CLIs do not run on mobile and never will Can you clarify why the never? What's the issue with giving a phone-based AI a sandboxed file system and bash shell?
- MatthewPhillips 4mo ago
  How is the user installing the CLIs? Proprietary app store for each chat app?
  - falcor84 4mo ago
    I didn't mean that users would install them. I meant that if mcp and AI agents continue being popular, then Google and Apple could choose to provide apps with cli sandboxes with the proper permissions. It is a big change, but I just didn't understand the "never"; we've had bigger changes.
    - MatthewPhillips 4mo ago
      Ok sure, the "never" was a bit strong here. Running CLIs on phones is not a normal thing and not as simple as it is on desktop. Apple prohibits apps from downloading and executing code, so some sort of new Apple-approved thing would be required here. That's a very heavy lift. Of course anything is possible, I just don't think that people advocating for MCP's death have really thought through these problems, and are mostly focused on the desktop productivity use-cases.

docheinestages 4mo ago

Agreed. I think MCP should stay abstract in the sense tool-calling is. JSON-RPC could be one way to do it.

noworriesnate 4mo ago

I think graphql backed by mcp is the technically best solution. Graphql allows an agent to select which fields it wants in context. Graphql is easy to generate clis for / easy to generate libraries for (if we want llms to generate scripts that call tools).

zingar 4mo ago
GraphQL also allows the LLM to DOS your service
deleted 4mo ago
[deleted]

bmitc 4mo ago

MCP is not an answer to the lack of a CLI or API.

sd9 4mo ago

> I run the team at OpenAI that's responsible for the ChatGPT App Store, Codex plugins, and all things MCP. > 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.

zingar 4mo ago
It was obvious hyperbole. I can believe that there are many companies where the boss heard about MCP and put it on a roadmap before anthropic decided that it wasn’t a good idea… and now the team is implementing this in the name of “we need to do some AI”

troupo 4mo ago

> All of those are just implementation details to the much more important point: our AI agents are getting access to services they otherwise would never have had access to. 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.

yepyoukno 4mo ago

What is so very strange is that MCP is what we have always wanted, for ourselves! 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!

qsxfthnkp2322 4mo ago

Mcp is not dead says the guy who gets paid half a million to work on it. News at 11.

zimbatm 4mo ago

Another aspect is access control. 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.

delusional 4mo ago
To the extent this is true, and it isn't with setuid binaries, it's a limitation of operating system apis.

croes 4mo ago

> The reason MCP isn't dead is because practically ~every company on the planet is building an MCP server. Didn’t ~every company also jump on blockchain and NFTs?

delusional 4mo ago

> Maybe we will turn every MCP server into a CLI under the hood. Maybe we'll use code mode. Maybe we'll implement tool search. 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.

btbuildem 4mo ago

> practically ~every company on the planet is building an MCP server 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.

windexh8er 4mo ago

This is a classic PM take IMO, no disrespect. "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.

Eridrus 4mo ago

You should probably consider that your perspective is also biased and you see all the companies that are in esting. 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.

hackrmn 4mo ago

The point is that MCP solves a problem that doesn't _really_ exist. While consuming context, which is still at a premium. Claiming that services wouldn't be accessible to agents without MCP is at best misleading -- they certainly do [have access] through exactly what article sheds light on -- command-line tools, including but not limited to, input and output of said tool(s). Also, from a purely technical standpoint, MCP is "non-compositional" compared to command-line tools, and those who don't value composition are IMO doomed to discover so at their own peril, sooner or later. 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.

mikecwang 4mo ago

So because people are doing it, it's the right thing to keep? There is a long way to go before we know the shape of the real solution. Don't let things like MCP slow down the exploration

KaiShips 4mo ago

[flagged]

imp0cat 4mo ago

Got any tips for building a MCP over CLI app?

listless 4mo ago

Oh man - hearing that we’re building MCP’s where there is no CLI makes me super nervous. It’s one thing to dupe the functionality of your CLI for better agent integration. It’s another to make it the sole method of interface locking everyone into a spec that we may decide we can do better at some point. Then we gotta pay off all the MCP debt and it will be cheaper to just not.

mycall 4mo ago

Wouldn't it be easier if MCP supported vector embeddings as input/output? It would shift its integration from a Broker Agent to a Deterministic Semantic Router. That by itself would prevent context bloat.