Hacker News Reader

Comment by rajeevk | Hacker News Reader

> 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.

View on HN

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.

An MCP server should be self-describing, so I use prompts to deliver skills or skill-like context.

Reply on news.ycombinator.com