The article you link (and general movements in that area, like e.g. discussed here[0]) don't advocate for abandoning MCP, just that masquerading MCP usage as code usage makes it more efficient. In that system MCP still provides a valuable role to act as a tool discovery protocol, a role that would have to be filled one way or another unless you are building a system with a set of tools that is known ahead of time.
It sounds like you are viewing MCP servers through a narrow lens of local coding agents.
I'm mostly working with MCP servers in the context of enterprise/organizational usage for connecting internal data sources and workflows/internal APIs through a standardized interface. There is no equivalent of a "ls or AGENTS.md" there, as there is no file system and no shell in those contexts.
If there is no file system where do the MCP definitions live and how are the agents aware of them? How are your end users aware of these definitions? There has to be a file somewhere.
If you mean the configuration of the entry points similar to a .mcp.json for Claude Code, they can exist in any form, but ultimately, that only contains the endpoints of MCP servers (the entry points for discovery for each of the MCP servers).
If you mean the definitions of what tools are part of what MCP server (= the meat of what is involved in tool calling), those definitions are part of the MCP server and are only retrieved at runtime.
> how are the agents aware of them
Same as in Claude Code, the agent (= the control loop for the LLM) contacts the list of MCP endpoints, gathers all of the available tools on each MCP server, and then exposes those tools to the LLM (and handles the interactions between LLM and MCP server).
> There has to be a file somewhere.
Not in any way that's meaningful for an `ls` operation.
It conceptually isn't that far from OpenAPI defintions, but MCP do make certain affordances for making consumptions by LLMs easier.
But it certainly also differs by how they are typically consumed. In what software do you just provide your consuming client just an OpenAPI schema URL to be retrieved at runtime? In my experience, none.
[0]: https://news.ycombinator.com/item?id=45917182