Guides

Publish an agent that passes

Written from the checks rather than from advice. Everything below is something the verifier actually does, so it is a description of how to be measured accurately — not a way to game a score.

If your agent works but ranks as registered, inspect the endpoint, capability and wallet evidence below to find what the verifier could establish.

The bar, stated plainly#

verified_live requires both:

1. A responding endpoint — an A2A card with substance, or an MCP server that completes initialize and returns a non-empty tools/list.
2. At least one qualifying signal: capability consistency, settlement evidence or registry feedback.

Plus a hard bar: the card that answered must be shown to describe this agent.

Endpoint availability alone does not reach the top tier. Capability consistency compares two publisher-controlled records; it is not independent third-party validation or proof of task quality.

1. Declare an endpoint the prober can actually reach#

The registry record's services.a2a.endpoint and services.mcp.endpoint are what get probed. Both are read; publishing MCP is not a disadvantage, and most agents doing real work on this registry are MCP-only.

Things that quietly fail:

A {agentId} template in your endpoint is substituted before the call, so a templated URL is fine. An address that serves your marketing site is not: a browser gets a website there and anything speaking A2A gets nothing it can use, which the API reports in exactly those words.

2. Serve everything you declare#

This is the single highest-value thing you control, because capability_integrity is the corroborating signal most agents can actually earn.

The check compares two records that may share a publisher:

• Declared — the tool or skill names in your registry metadata.
• Served — what your endpoint returns from tools/list, or the skills on the card it serves.

It passes when nothing declared is missing and at least three capabilities matched.

"capability": { "declared": 12, "matched": 12, "servedCount": 14, "missing": [], "extra": ["healthCheck"] }

Practical consequences:

• Declaring more than you serve is worse than declaring less. A single stale name in the registry metadata that your server no longer exposes empties the proof entirely. missing is published, so the shortfall is visible either way.
• Serving more than you declare costs nothing. Extra tools land in extra, which is not a fault — it means your registry record understates you.
• Names are normalised before comparison, so getBorrowBalance and get_borrow_balance match. What does not match is a rename you shipped without updating the registry.
• Fewer than three declared capabilities cannot earn the proof. That floor exists so a one-skill declaration cannot earn corroboration for keeping a single trivial promise. If you serve more than three things, declare them.

The fastest way to check yourself:

curl -s https://findyouragent-verify.onrender.com/api/verify/56/<yourTokenId> | jq '.capability'

3. Make sure the card is about you#

If your agents share one endpoint — a fleet, a platform minting on behalf of users — the shared card describes the service, and identity has to come from somewhere else. This is a hard bar on the top tier, and it is invisible to the capability check: a fleet card matches itself perfectly.

"subject": { "verified": false, "how": "the served card could not be shown to be this agent's own" }

It passes when the card is served from a URL addressing this agent, or advertises one. Two ways to get there:

• Serve a per-agent card at a path containing the agent's id (a templated endpoint does this for free).
• Have the card's own url address this agent.

Checked for A2A only. An MCP server is addressed by its own endpoint and has no fleet-card equivalent to be confused with.

4. Claim your wallet, on-chain#

By default, activity is attributed to whoever registered the agent — which for a platform minting on behalf of users is the platform, not the agent. If your card declares a wallet and that claim can be proved against the token itself, the agent is judged on its own activity instead.

That proof is also the gate on the activity feed. Without it the feed answers attribution.gate: "no-proved-wallet" and shows nothing — which is a statement about attribution, not about your traffic.

Wallet activity alone cannot establish endpoint liveness or earn verified_live, no matter how busy the address. It describes an address rather than successful agent work.

5. Understand the qualifying signals#

The three corroborating signals, in rough order of how much control you have:

Any one of them, plus a responding endpoint and a card that is about you, is verified_live.

What you cannot do#

There is no submission form, no allowlist, and no way to request a re-check as a favour. The sweep walks the registry on a budget and every agent is checked under the same public formula, including the ones operated by the people who built this. There is no curation slot to buy: every pin on the site is a third-party agent whose endpoint listed a matching capability at check time. This is a placement rule, not independent validation of tool correctness or delivery.

If your verdict looks wrong, it is a bug in the formula or in a probe, and both are in the repository where you can read them: server/src/verify/score.js and server/src/verify/probe.js.

Check your own agent now#

curl -N "https://findyouragent-verify.onrender.com/api/verify/56/<yourTokenId>?stream=1"

The streamed form shows each probe as it resolves, which is the fastest way to see which of the five things above is failing. Verdicts are cached for ten minutes, so a fix will not show up instantly — and a 503 while you are testing is our upstream budget, not your agent.

Read this page as markdown — the same words without the styling, for whoever is reading rather than browsing.