It feels like there's a lot of overlap with the existing MCP "Resources" [0] concept, and that "Searchable Registry" + multi-protocol (MCP/A2A, etc) is the main difference?
Too many protocols got created (MCP, A2A, etc) and so now you've got to create a new standard that can consume them all, and Google being a search index would like to index them, please =)
The best solution we could find for this problem was a combination of a Wiki + "Saved Programs" (executable scripts).
When you ask a question, the system does a fuzzy Wiki search to see if any topic has relevant info. Wiki links serve as "graph edges" that form a Knowledge Graph.
So lets say I ask "What products from the FOOBAR API sold least last month?"
The agent would look up "FOOBAR API", and then write a script to call the "products" endpoint with a date range + SQL fetch from "sales" DB and do whatever it needs to do.
If none of this info exists (URL to FOOBAR, location of "sales" data), the agent asks for more info and offers to update the wiki for future.
This is search. Please don't reinvent search with a new acronym.
Agents can use Google. They can also see all the same signals humans do to judge quality. Maybe there's a need for a specialized directory, but does it need a spec or an acronym? No.
This seems useful as a standard interface, but, again, doesn’t solve the harder discovery problem. Once there is value in appearing in the top results, the system inherits the same adversarial dynamics as SEO/app stores, spam, scams, etc.
It feels like there's a lot of overlap with the existing MCP "Resources" [0] concept, and that "Searchable Registry" + multi-protocol (MCP/A2A, etc) is the main difference?
Too many protocols got created (MCP, A2A, etc) and so now you've got to create a new standard that can consume them all, and Google being a search index would like to index them, please =)
[0]: https://modelcontextprotocol.io/specification/2025-11-25/ser...
As always, relevant XKCD https://xkcd.com/927/
I work at a company with an LLM-adjacent tool.
The best solution we could find for this problem was a combination of a Wiki + "Saved Programs" (executable scripts).
When you ask a question, the system does a fuzzy Wiki search to see if any topic has relevant info. Wiki links serve as "graph edges" that form a Knowledge Graph.
So lets say I ask "What products from the FOOBAR API sold least last month?"
The agent would look up "FOOBAR API", and then write a script to call the "products" endpoint with a date range + SQL fetch from "sales" DB and do whatever it needs to do.
If none of this info exists (URL to FOOBAR, location of "sales" data), the agent asks for more info and offers to update the wiki for future.
This is search. Please don't reinvent search with a new acronym.
Agents can use Google. They can also see all the same signals humans do to judge quality. Maybe there's a need for a specialized directory, but does it need a spec or an acronym? No.
MCPs: Json endpoints with a "description" field.
More like: JSON-RPC, but without all good stuff.
This seems useful as a standard interface, but, again, doesn’t solve the harder discovery problem. Once there is value in appearing in the top results, the system inherits the same adversarial dynamics as SEO/app stores, spam, scams, etc.