Agent Arena Registry

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations and no output schema, the description carries full behavioral disclosure burden. It successfully compensates by listing specific return fields (name, description, endpoints, reputation, reviews, cross-chain presence) and noting 'Free endpoint' (cost/permission status). It does not disclose rate limits, caching, or error behaviors (e.g., not found).

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?

Three efficient, front-loaded sentences: (1) core purpose, (2) return values (critical given no output schema), (3) cost behavior. No redundancy or waste; each sentence provides unique value not duplicated in structured fields.

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?

Given the simple 2-parameter input structure but complete absence of output schema and annotations, the description provides adequate completeness by enumerating return fields and cost. Could be improved by mentioning error handling (e.g., agent not found) or required prerequisites.

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?

Schema description coverage is 100%, documenting both chainId and agentId with specific formats (e.g., 'ERC-8004 registry'). The description reinforces the 'on-chain ID' concept but does not add syntax details, validation rules, or usage examples beyond the schema's scope. Baseline 3 is appropriate for high-coverage schemas.

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?

Description uses specific verb 'Retrieve' + resource 'full profile' + scope 'specific agent by their on-chain ID'. The phrase 'specific agent by ID' clearly distinguishes this from sibling search_agents (which would find agents without exact IDs) and register_agent (which creates).

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 phrase 'specific agent by their on-chain ID' implies this requires an exact identifier, suggesting when to use it (when you know the ID). However, it lacks explicit guidance contrasting with search_agents for discovery scenarios or stating what to do if the ID is unknown.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, yet description carries substantial burden effectively: discloses mutation ('Mints'), side effects ('indexes for discovery'), cost ('$0.05 USDC'), payment rail ('x402'), and network ('Base mainnet'). Missing only failure modes, reversibility, or idempotency details.

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?

Three sentences with zero waste. Front-loaded with core action, followed by side effects, followed by cost requirements. Every clause provides necessary information about blockchain mechanics or financial obligations.

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?

Strong coverage for a 7-parameter blockchain operation: covers purpose, cost, mechanics, and indexing. Only gap is absence of output specification (transaction hash, token ID, etc.) particularly important since no output schema is provided.

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?

Schema description coverage is 100%, establishing baseline 3. Description provides high-level context for the registration process but does not augment individual parameter semantics (e.g., uniqueness constraints on 'name', valid formats for 'capabilities') beyond what the schema already documents.

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?

Excellent specificity: identifies exact action ('Register'), resource ('AI agent'), location ('Base blockchain ERC-8004 registry'), and distinguishes from siblings get_agent_profile (read) and search_agents (query) by clearly signaling a creation/minting operation.

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?

Clear from context that this is for initial creation ('new AI agent') versus the read-oriented siblings. However, lacks explicit guidance on what to do for updates (if agent already exists) or prerequisites like wallet prerequisites, falling short of explicit when/when-not rules.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Excellently discloses the unusual payment requirement ('$0.001 USDC via x402 on Base mainnet') and return structure ('endpoints, pricing, and reputation scores'). Could explicitly state idempotency/safety characteristics.

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?

Three sentences, each with distinct purpose: action, return values, payment requirement. Front-loaded with verb, zero redundancy. Perfect information density.

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?

Strong coverage given complexity: payment mechanism disclosed (critical for 402-enabled tool), return values described (compensating for missing output schema), and search scope clarified. Only minor gaps like rate limits or error conditions prevent a 5.

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?

Schema coverage is 100% with complete descriptions for all 4 parameters. Description reinforces query semantics ('capability, name, or description') but does not add substantial semantic value beyond the schema. Baseline 3 appropriate for high schema coverage.

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?

Specific verb 'Search' with clear resource 'Agent Arena registry' and exact scope 'by capability, name, or description'. Implicitly distinguishes from sibling register_agent (create vs search) and get_agent_profile (discovery vs specific retrieval).

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?

Provides clear context for searching (capability/name/description terms) but lacks explicit guidance on when to use this versus get_agent_profile for direct lookups. No 'when-not' or alternative tool references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.