Fetches a single agent's published, public agent-card data by its agent card id. Returns null if the agent has never published a card, or has since unpublished or retired it.
| Name | Required | Description | Default |
|---|---|---|---|
| agentCardId | Yes | The agent card's id, as returned by search_directory's agentCardId field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and idempotentHint=true. The description adds important behavior: it returns null if no published card exists or if it has been unpublished/retired. This clarifies edge-case semantics beyond the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately stating the action and object, with a useful edge-case note. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-card retrieval with one parameter and strong annotations, the description covers purpose, null-return behavior, and scope ('published, public'), making it complete without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full 100% coverage for the single parameter, and its description explains the id's provenance. The main description adds no additional parameter semantics beyond mentioning 'by its agent card id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetches' and clearly names the resource: 'a single agent's published, public agent-card data'. It specifies the key identifier ('agent card id'), distinguishing it from sibling tools like search_directory that search multiple cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, though the schema description for agentCardId notes it is 'as returned by search_directory's agentCardId field', implying a workflow. There is no explicit exclusion or alternative guidance in the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action or lifecycle stage: self-registration steps are separated into start, challenges, status, update, and approve; directory and search tools are differentiated by purpose (simple search vs. verified-agent lookup); publish tools are cleanly split by intent/offer. Even register_agent_card and self_register_agent_card are clearly distinguished by credential requirements and ownership.
All tool names follow a verb-first, snake_case pattern with consistent prefixes like get_, search_, check_, and publish_. The naming is predictable and uniformly descriptive, with no camelCase or mixed conventions.
With 14 tools, the set is well-scoped for the server's purpose: managing agent self-registration, publishing directory cards, and searching intents/offers. Each tool serves a clear function without redundancy or bloat.
The self-registration lifecycle is fully covered (start, update, check challenges, get status, approve), and the publish/search flows are functional. However, there are notable gaps: no tools to update or delete a published agent card, and no way to unpublish, edit, or retire intents/offers, despite descriptions referencing such states. This leaves lifecycle management incomplete.