Integration with Centralized Catalogues

[MarcoMetaMask]

Note: Throughout this text, agents <> services

Goals

To solve the cold start problem:

• Enable discovery of services that haven't yet registered on 8004 (from centralized catalogues)
• Enable providing feedback on 8004 to services that haven't yet registered on 8004

Current State

Since:

• Currently on 8004, anybody can register services owned by somebody else. The registration file links back to the on-chain agent, but the endpoint can be hosted on a different domain from the registration file. This means I can register an agent, use the registration URI (registrations section) to link back to the agent, but then insert an endpoint owned by somebody else.
• Currently, feedback can only be given to an agent registered on 8004

Then:

• The only way to mass-import services from centralized sources is to register agents/services that you don't own
• ...and then anybody can give feedback to them
• The drawback is that you could have multiple instances of the same unverified service with the same endpoint. When a third-party observer needs to give feedback, which agent ID should they pick? It's unclear—you would have duplicates.

Possible Solution

If:

• In the feedback registry, add a domain attribute. A feedback entry should indicate (as a target) at least one of the following fields: target agentId or domain.
• A DNS Verifier Watchtower service checks, for any endpoint, whether the domain has a TXT record pointing to the agent (e.g., chainId=x, registryAddress=k, agentId=y) and posts a feedback entry to that agent every week/month. clientAddress = the address of the trusted watchtower; tag1 = dnsVerification; tag2 = domain.com. Since feedback is permissionless, multiple such verification services could exist.

Then:

• Anybody can give feedback to unregistered services by filling in the domain field but leaving agentId empty.
• If agentId is filled, it's clear to observers whether its endpoints are verified or not. Regardless, the feedback is still valuable because it targets the domain.
• If the actual service owner registers later, when multiple unverified services exist in the registry, observers/SDKs will aggregate the feedback on that domain as related to the verified service, and use that verified agentId from that moment onwards.
• Anybody can import services from centralized catalogues (as agents with unverified endpoints) or directly read from those catalogues at the application layer (SDK) without importing them, while still enabling usage (messaging, tool calling) and feedback.

[jiayaoqijia]

In mature open-source ecosystems, especially package management systems like Homebrew, npm, PyPI, and Docker Hub, it is extremely common for packages to be uploaded by non-owners or forked/mirrored by multiple individuals. Mechanisms such as stars, likes, comments, and third-party validations are precisely the solutions ERC8004 employs to help users identify the most trustworthy agent registration from a vast sea of information. Therefore, the "problem" raised in this issue should not be considered a problem at all, but rather a normal phenomenon in decentralized ecosystems.

Restricting registration to "owners only" would introduce centralization—who would verify "who the real owner is"? This requires trusted third parties, which goes against the spirit of Web3. The openness of ERC8004 is its strength: multiple registrants maintaining metadata for the same service creates healthy decentralized competition.
The quality of registration (timeliness of updates, completeness of metadata) rather than ownership itself becomes the criterion for which agentId the community trusts. Market mechanisms will naturally filter out the most reliable registrations.

For agents not proactively registered on-chain by their owners, we can adopt Docker Hub's "official image" model: establish a neutral curatorship organization by the community or ERC8004 association to register these services, clearly labeled as community-curated. Simultaneously, design a standardized ownership claim process (via on-chain signatures, ENS verification, or DNS records) enabling seamless transfer of registration when the owner emerges.

At the SDK level, we can implement automatic aggregation of feedback for identical endpoints and calculate trust scores based on registration quality and community ratings to recommend the optimal agentId. This solves the cold start problem while maintaining the trustless nature of the system and avoiding over-engineering.

[MarcoMetaMask]

In mature open-source ecosystems, especially package management systems like Homebrew, npm, PyPI, and Docker Hub, it is extremely common for packages to be uploaded by non-owners or forked/mirrored by multiple individuals. Mechanisms such as stars, likes, comments, and third-party validations are precisely the solutions ERC8004 employs to help users identify the most trustworthy agent registration from a vast sea of information. Therefore, the "problem" raised in this issue should not be considered a problem at all, but rather a normal phenomenon in decentralized ecosystems.

Restricting registration to "owners only" would introduce centralization—who would verify "who the real owner is"? This requires trusted third parties, which goes against the spirit of Web3. The openness of ERC8004 is its strength: multiple registrants maintaining metadata for the same service creates healthy decentralized competition. The quality of registration (timeliness of updates, completeness of metadata) rather than ownership itself becomes the criterion for which agentId the community trusts. Market mechanisms will naturally filter out the most reliable registrations.

For agents not proactively registered on-chain by their owners, we can adopt Docker Hub's "official image" model: establish a neutral curatorship organization by the community or ERC8004 association to register these services, clearly labeled as community-curated. Simultaneously, design a standardized ownership claim process (via on-chain signatures, ENS verification, or DNS records) enabling seamless transfer of registration when the owner emerges.

At the SDK level, we can implement automatic aggregation of feedback for identical endpoints and calculate trust scores based on registration quality and community ratings to recommend the optimal agentId. This solves the cold start problem while maintaining the trustless nature of the system and avoiding over-engineering.

Thank you! Very interesting and smart comment:

• I'm proposing to keep enabling anybody to register any agent, so this should be compatible with what we are saying (incl. having duplicates). The txt record verification (per endpoint) would be optional
• "aggregation of feedback for identical endpoints" To achieve this, a feedback should be related also to an endpoint and not just to an agent. Otherwise, which aggregation key can you use across agents? This should be aligned with what I'm proposing (adding an optional endpoint attribute to the on-chain feedback). Am I understanding well?

[TheGreatAxios]

I second the approach around optional verification and having that further tie into some form of "Official". Unclear how beneficial it is in the short term but I think if this could be be for example proven by a signature (i.e I own the wallet and I own the domain) and then an entity can then further use some form of decentralized KYC/KYB (fully optional) that could greatly improve the trust factor of an agent if it can be proven that "Metamask owns this agent" for example.

[MarcoMetaMask]

I second the approach around optional verification and having that further tie into some form of "Official". Unclear how beneficial it is in the short term but I think if this could be be for example proven by a signature (i.e I own the wallet and I own the domain) and then an entity can then further use some form of decentralized KYC/KYB (fully optional) that could greatly improve the trust factor of an agent if it can be proven that "Metamask owns this agent" for example.

agentWallet > How about leaving the signature to the authentication layer and just keeping the public key address (agentWallet) as it is right now?
domain > So are you fine with using optional TXT DNS records?

[rickycambrian]

Great discussion, and would personally find this really useful. I started looking at the MCP centralized catalogues side here: https://github.com/rickycambrian/erc8004_mcp

I looked at the Smithery MCP registry and here is the breakdown of results:

• Total: 3,253
• With endpoint: 1,305
• With tools: 1,464
• Endpoint + tools: 1,119

For the Anthropic MCP registry found that of the 3,148, there was only one that used _meta.publisher-provided, and I'm not finding a simple way to introspect the available tools yet there. We do have the repos available here though, so I think we can find the available tools for a lot of the ones that have an endpoint available:
Total: 3148
With endpoint: 1044
With tools: 0
Endpoint + tools: 0
With repository: 2465

In the context of this discussion, what is the best way to register these MCP servers? Here is an example that can be queried from the base sepolia subgraph: https://thegraph.com/explorer/subgraphs/GjQEDgEKqoh5Yc8MUgxoQoRATEJdEiH7HbocfR1aFiHa?view=Query&chain=arbitrum-one

{
  agent(id: "84532:2122") {
    id
    agentId
    agentURI
    owner
    createdAt
    registrationFile {
      name
      description
      mcpEndpoint
      mcpVersion
      mcpTools
      mcpPrompts
      mcpResources
      a2aEndpoint
      a2aSkills
      active
    }
  }
}

@MarcoMetaMask for the above, the ipfs file shows a configSchema which would tell a user they need to provide exaApiKey to use the MCP server:

// 1. Query subgraph for agent
const agent = await querySubgraph(`{ agent(id: "84532:2122") { agentURI } }`);

// 2. Fetch full registration from IPFS
const ipfsUrl = agent.agentURI.replace('ipfs://', 'https://ipfs.io/ipfs/');
const registration = await fetch(ipfsUrl).then(r => r.json());

// 3. Get configSchema from endpoint
const mcpEndpoint = registration.endpoints.find(e => e.name === 'MCP');
console.log(mcpEndpoint.configSchema);
// { properties: { exaApiKey: { description: "Exa AI API key..." } } }

I have tried adding the information via Agent0 SDK metadata, but running into a limitation where the values show up as encoded and not human readable, see agent ID 84532:2130. What do you guys think the best way to present these MCP servers to users would be both in terms of having clarity around what secrets are needed?

In the context of Smithery it provides the information needed for available tools, but legitimacy verification seems harder here because they all fall under the same server.smithery.ai domain. On their website they show checkmarks for official ones, but need to investigate how to programmatically access that, and how that should be presented via Agent0 SDK usage.

For the Anthropic registry would need to investigate how to get the list of tools given nobody seems to be using _meta.publisher-provided on registration, and how to extract value from those registered with endpoints and github repos. As far as I can tell there is no verification of either when adding to the registry though, so it's a bit unclear to me whether someone could just post a legitimate repo for a malicious MCP server to capture credentials or do other fishy things with. I think inheriting the same security of centralized catalogues and trying to make that clear makes sense, but it does also make me wonder about the ways in which public repos could be better leveraged. For example if there was some type of Agent0 trusted deployer that found legitimacy through the github user and repo stars, history, and code itself to look for security concerns, I would probably feel better about that as a user than not knowing if I'll end up using some random person's private endpoint to send my secrets. Normally I would say let the market figure it out, but if in order to do so at least one person needs to find out the hard way and that it may not always be easy to detect, it might be too favorable towards an attacker.

I would be curious to hear people's thoughts around the 6.4k MCP servers in the repo I started, and what kind of usability vs security concerns we see, and whether centralized catalogues should be posted without any curation. So more directly, what would be the best path for what should be posted onchain for the MCP side given what I outlined?

Then I personally think it's interesting to think about how we can remove trust assumptions in differences between deployments and public repos, probably not the best rabbit hole to go down first so I might do a couple experiments before sharing more thoughts there.