This was the easiest call and many like me made it in March[0] among all of the anti-MCP wave of influencers claiming it dead (many, many prominent folks in tech including Garry Tan). Literally every tech influencer in every social feed in March was calling MCP dead and crowning CLI the winner (completely ignoring every reasonable argument around security, observability/telemetry, ease of deployment and operations, etc.)
A direct quote from March, 2026[1]:
> If you’re still not convinced that a lot of this discourse [regarding the death of MCP] lacks nuance and is just hype, congrats on buying into the current AI-influencer FOMO hype cycle; see you in 6 months when the influencers move on to the next revelation of the moment to stay relevant and get your eyeballs and dollars.
It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`.
My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in general, the major clients have spotty implementation for some of the features in the spec.
> My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec
MCP servers provide three things: tools, resources, and prompts. Of these, tools seem to be the only part implemented consistently across major clients like ChatGPT, Claude.ai, Claude Code, etc.
For prompts and resources, there doesn't seem to be a common understanding of how clients are supposed to consume them.
For example, if an MCP server exposes resources, Claude Code can discover them and consume them when needed without you explicitly asking for a specific resource. Claude.ai behaves differently. It doesn't automatically discover and consume those resources. Instead, it gives you a way to manually add an MCP resource to the prompt.
So while MCP defines tools, resources, and prompts at the protocol level, the actual user experience for resources and prompts varies quite a bit across clients.
In practice, the problem with resources is that many resource collections are too large to list exhaustivley, and if that's the case you will need to need to implement a proper search tool anyways (as the Completions utility isn't a good fit), at which point there is little use in also implementing all of that as a resource, rather than `list_`,`search_`,`get_` for a resource.
That feels like it should be the obvious use case for something like a `?q` query param, formalized or not, but it seems like nobody working on the spec and libraries ever considered query params as a use case, since they're still broken in the Typescript library.
The idea of "model controlled", "application controlled" and "user controlled" for tool, resources and prompts (respectively) was aligned with the chat interface. It breaks for the autonomous agent paradigm where the agency is the user and the lines are blurred. Unfortunately MCP has been mostly relegated to tool calling leaving potentially powerful capabilities on the table due to lac of client support for them.
I disagree on Prompts since virtually all of the mainstream harnesses implement them: Cursor, Claude, OpenCode, Copilot. Prompts are very clearly just a remotely delivered `/` command and it is easy to see why this is really powerful (single entry point, no need to update/sync skills, dynamic sets by audience, dynamic construction of the payload by audience, etc). For all intents and purposes, it should be viewed as an analog to local, text-only skills.
Codex is the only mainstream harness that does not implement this in the client.
Prompts I am not that sold on but it seems silly to not implement it in clients.
A good use case for resources is small amounts of commonly needed state that can be fetched and proactively updated by the mcp server, saving latency when the model requests it.
Prompts is possibly one of the most useful enterprise features for MCP.
Dynamically target sets of `/` commands to teams in an enterprise by their identity+claims? Legal team gets a set of skills? Finance team gets another just by their roles? Always up-to-date delivery of what are effectively remotely served skills? Telemetry on who is using which skill? Server-side rendering of skills so that common skills can be composed? With placeholders replaced by user- or team-custom options? Easy to ship new skills as long as the user has connected the MCP? Easy to retire skillsets that are outdated across the entire enterprise?
MCP Prompts is one of the most powerful capabilities in the spec for enterprises.
OpenAI team: if you are angling for enterprise, you need to get this solved. Your FDEs are going to make a killing getting this set up for enterprises. Build an enterprise skills management platform around this that's integrated to their directory. Streamlined setup of the MCP via MDM. Telemetry on enterprise wide usage of curated skills across the enterprise, by team, by individual. You need this.
CharlieDigital · · focus · HN ↗
A direct quote from March, 2026[1]:
It was fairly obvious why MCP would be needed once AI engineering and uptake moved beyond the solo developer and single harness stack of "what works for Me" versus "what works for My Team", particularly in an enterprise context. The key mistake people made was thinking in terms of their own workflows and own local stacks instead of a team's workflow and a team's operational stack. There was also an ignorance of MCP's stateless HTTP mode (yes, it was already a thing in March; the 2026-07-28 revision of the spec just prioritizes it as the primary focus moving forward) versus local `stdio`.My biggest complaint right now is that OpenAI has still refused to implement the MCP Prompts spec[2] and in general, the major clients have spotty implementation for some of the features in the spec.
[0] <a href="https://news.ycombinator.com/item?id=47380270">https://news.ycombinator.com/item?id=47380270
[1] <a href="https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/" rel="nofollow">https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
[2] <a href="https://github.com/openai/codex/issues/5059" rel="nofollow">https://github.com/openai/codex/issues/5059
rajeevk · · focus · HN ↗
MCP servers provide three things: tools, resources, and prompts. Of these, tools seem to be the only part implemented consistently across major clients like ChatGPT, Claude.ai, Claude Code, etc.
For prompts and resources, there doesn't seem to be a common understanding of how clients are supposed to consume them.
For example, if an MCP server exposes resources, Claude Code can discover them and consume them when needed without you explicitly asking for a specific resource. Claude.ai behaves differently. It doesn't automatically discover and consume those resources. Instead, it gives you a way to manually add an MCP resource to the prompt.
So while MCP defines tools, resources, and prompts at the protocol level, the actual user experience for resources and prompts varies quite a bit across clients.
hobofan · · focus · HN ↗
crooked-v · · focus · HN ↗
spennant · · focus · HN ↗
CharlieDigital · · focus · HN ↗
Codex is the only mainstream harness that does not implement this in the client.
justinhj · · focus · HN ↗
A good use case for resources is small amounts of commonly needed state that can be fetched and proactively updated by the mcp server, saving latency when the model requests it.
politician · · focus · HN ↗
CharlieDigital · · focus · HN ↗
Dynamically target sets of `/` commands to teams in an enterprise by their identity+claims? Legal team gets a set of skills? Finance team gets another just by their roles? Always up-to-date delivery of what are effectively remotely served skills? Telemetry on who is using which skill? Server-side rendering of skills so that common skills can be composed? With placeholders replaced by user- or team-custom options? Easy to ship new skills as long as the user has connected the MCP? Easy to retire skillsets that are outdated across the entire enterprise?
MCP Prompts is one of the most powerful capabilities in the spec for enterprises.
OpenAI team: if you are angling for enterprise, you need to get this solved. Your FDEs are going to make a killing getting this set up for enterprises. Build an enterprise skills management platform around this that's integrated to their directory. Streamlined setup of the MCP via MDM. Telemetry on enterprise wide usage of curated skills across the enterprise, by team, by individual. You need this.
ianjbutler · · focus · HN ↗
[dead]