[CharlieDigital]

    > I have no idea what I'm missing.

The questions I'd ask:

    - Do you work in a team context of 10+ engineers?
    - Do you all use different agent harnesses?
    - Do you need to support the same behavior in ephemeral runtimes (GH Agents in Actions)?
    - Do you need to share common "canonical" docs across multiple repos?
    - Is it your objective to ensure a higher baseline of quality and output across the eng org?
    - Would your workload benefit from telemetry and visibility into tool activation?

If none of those apply, then it's not for you. Server hosted MCP over streamable HTTP benefits orgs and teams and has virtually no benefit for individuals.

[monsieurbanana]

What I want to know is what's the difference between a remote mcp and an api with an openapi.json endpoint for self-discovery? It's just as centralized

[CharlieDigital]

It's instructive to skim the top level of the MCP spec to get a sense. But you can also scroll to the end of the post and see the three .gifs there and see why MCP: because it also defines interaction models with the clients and exposes MCP prompts as `/` (slash) commands and MCP resources as `@` (at) references among other things.

You are right: MCP tools are in essence OpenAPI specs with some niceties like standardized progress reporting. But MCP is more than tools.

[monsieurbanana]

Neither slash commands or interaction models are unique to mcp, you can have a http api that offers both.

More concretely, you can have an installable (and updatable) skills that will teach the agents how to use your api and will come with slash commands.

What you cannot do with an mcp is pipe the output into standard tools (jq, head, etc...) or create scripts around it, etc.

[fartfeatures]

MCP is useful for the above. I work on my own more often than not and the utility of MCP goes far beyond the above. (see my other comment above).