Agentry — The Trust Layer for the Agent Economy

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

With no annotations, the description must carry the full behavioral disclosure burden. It only mentions the 200 success response and content type, but does not disclose safety (e.g., read-only nature), authentication requirements, rate limits, or potential error responses. The verb 'Return' implies read-only but no explicit behavioral context is given.

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 very brief and front-loaded with the purpose. It includes a structured response section that adds value, and every sentence/line is informative with no fluff.

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-parameter GET endpoint, the description covers the basic return type and success response. However, it omits error responses, authentication context, and any relationship to sibling endpoints, leaving the description minimally complete rather than thorough.

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 only parameter, agent_id, is self-explanatory, and the description's 'by ID' aligns with the schema. However, the description adds no extra meaning about format, source, or constraints, and schema description coverage is 0%, so the parameter meaning is only partially clarified beyond the schema.

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 clearly states it 'Return a single agent's A2A card by ID' using a specific verb and resource. It distinguishes the A2A card endpoint from sibling tools like get_agent_api_agents__agent_id__get, though it does not explicitly call out alternatives.

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 provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or prerequisites, leaving the agent to infer usage solely from the name and minimal description.

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?

With no annotations, the description must carry the burden of disclosure. It mentions the response format (agent cards, A2A-compatible) and a 200 response with content-type, but does not state read-only semantics, pagination behavior, error handling, or any side effects. The absence of a readOnlyHint makes this a notable gap.

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 concise and front-loaded with the title and key purpose. The 'Responses' section is minimal but not overly verbose. It avoids unnecessary fluff, though it could be better structured with more meaningful response details.

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 4 optional parameters, no output schema, and no annotations, the description is incomplete. It does not explain how to use pagination (top, cursor) or filtering (q, category), nor does it describe the agent card structure or any error conditions, leaving a substantial gap for an agent to correctly invoke the tool.

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 75% (q, cursor, category are described, top is not). The description adds no parameter-level meaning, failing to compensate for the undocumented 'top' parameter or explain how q, category, and cursor interact. It adds no value beyond the schema.

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 clearly states it returns agent cards in an A2A-compatible format, using the verb 'returns' with a specific resource. It does not explicitly differentiate from sibling tools like list_agents or search_agents, but the A2A compatibility and 'open discovery endpoint' provide some distinguishing context.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or comparison to sibling tools such as discover_single_agent or list_agents, leaving the agent without decision support.

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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions a 200 response with JSON content type but does not disclose important traits such as authentication requirements, error handling, rate limits, or whether the operation is read-only. The description is minimally transparent.

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 concise and well-structured, starting with a title, a clear one-sentence summary, and a responses section. It avoids unnecessary fluff, though the responses section is minimal. It is not bloated, which is appropriate, but it sacrifices detail.

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?

The tool is simple (one parameter, no output schema), but the description is incomplete. It mentions totals, balance, and tx count, but does not provide the response structure or potential error cases. Given that no output schema exists, the description should explain more about the return value and failure modes.

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 schema has one parameter, agent_id, with no description (0% coverage). The description says 'for an agent' but does not explain the parameter format, constraints, or how it relates to the summary. This adds little beyond what the schema already implies from the tool name.

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 clearly states the tool's function: 'Get payment summary for an agent — totals, balance, tx count.' This is specific about the verb and resource, and mentions output fields. However, it does not explicitly differentiate from sibling tools like get_payment_profile or list_transactions, so it stops short of a 5.

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?

There is no guidance on when to use this tool versus alternatives. The description only states what the tool does; it does not mention prerequisites, exclusion conditions, or scenarios where another tool would be more appropriate.

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 are provided, so the description must carry the full burden of behavioral disclosure. It implies a read-only check but does not explicitly state that no state changes occur, nor does it disclose error behavior, authentication requirements, or rate limits.

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 short and front-loaded with the core purpose. It includes redundant headers like 'Check Quote' and 'Successful Response (Success Response)' but is still appropriately sized and structured.

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?

With no output schema, the description should explain the response body or status meanings, but it only lists a 200 response and content type. It omits key context like possible error codes, pending/paid status semantics, and any prerequisites, making it incomplete for a payment status tool.

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 0% description coverage for its 2 parameters, and the tool description does not explain either 'quote_id' or 'mint_url'. It only mentions 'mint quote' at a high level, failing to compensate for the missing schema descriptions.

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 clearly states 'Check the payment status of a mint quote,' using a specific verb ('Check'), a specific resource ('mint quote'), and a specific scope ('payment status'). This distinguishes it from sibling tools that create quotes or retrieve mint info.

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 provides no guidance on when to use this tool versus alternatives such as create_quote or get_mint_info. It only states what the tool does, with no context, prerequisites, or exclusions.

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 are provided, so the description must disclose behavior alone. It states the high-level action ('claims ownership') but omits details such as ownership verification, idempotency, side effects, or error conditions. The response section only mentions a generic 200 success, adding minimal value.

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 brief and front-loaded with the core purpose. However, the 'Responses' section is largely redundant (success is implied by HTTP) and takes space that could have clarified parameters or usage. Still, it is not bloated.

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?

With four parameters, no annotations, and no output schema, the description is insufficient for an agent to reliably invoke the tool. It lacks context on the claim workflow, required inputs, and response interpretation, making it a minimal but incomplete spec.

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 0%, and the description does not explain any of the four parameters. The purpose of name and message (optional) and the required agent_id and contact_email are left undefined, leaving the agent to guess their semantics.

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 clearly states the tool's function: a developer claims ownership of an existing agent listing. It uses a specific verb (claims) and resource (agent listing), distinguishing it from sibling tools like register_agent (new listing) and discover_single_agent.

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 implies usage context (a developer claiming ownership) but provides no explicit guidance on when to use this tool versus alternatives like register_agent or get_agent. There are no exclusions or prerequisites stated.

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?

With no annotations, the description must disclose behavioral traits. It clarifies that this is a quote, not the actual melt, but does not mention side effects, expiry, balance requirements, or authentication. No information about state changes or safety is provided.

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 concise and front-loaded with the main purpose. The Responses section adds limited value but is not bloated. Overall it is appropriately sized.

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?

The tool has no output schema, so the description should explain the response content. It only says 'Successful Response' without detailing quote fields, expiry, or next steps. For a 3-parameter API, this lack of detail is a significant gap.

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 0%, and the description provides no explicit parameter explanations. It implies agent_id and payment_request roles but does not cover mint_url or clarify any parameter format or constraints.

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 states a specific verb and resource: 'Get a quote to melt ecash into a Lightning payment (NUT-05).' This clearly distinguishes it from the sibling mint quote tool, which likely handles the reverse 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?

The description provides clear context with 'Used when an agent wants to pay a Lightning invoice using their ecash.' It does not explicitly mention when not to use it or name alternatives, but the use case is well-defined.

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?

With no annotations, the description carries the full burden. It explains the payment-then-mint flow and mentions a 200 response, but it does not disclose important behavioral details such as quote expiry, required authentication, or the actual response fields beyond generic 'Success Response'.

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 concise and front-loaded with the core purpose. The 'Responses' section adds little value since it just says 'Successful Response', but the overall structure is efficient and easy to scan.

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?

The tool involves a multi-step payment workflow and has three parameters, yet the description omits parameter semantics, expected output fields, and error cases. Since there is no output schema, the missing return-value information further harms completeness.

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 0%, and the description provides no explanation of the three parameters (agent_id, amount_sats, mint_url). It fails to compensate for the lack of schema-level descriptions, leaving parameter semantics completely unexplained.

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 a specific verb+resource: 'Create a Lightning invoice to fund ecash minting (NUT-04).' It clearly names the operation and distinguishes from the sibling 'create_melt_quote' by specifying ecash minting.

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?

It provides clear workflow context: the agent pays the invoice, then calls /mint/tokens to receive ecash proofs. However, it does not explicitly state when not to use this tool or name alternatives directly.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions a 200 response with JSON content type, but does not describe what the discovery process entails (e.g., network fetch, cache update) or any side effects, permissions, or error behaviors.

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 concise and well-structured with a clear title, a one-sentence summary, and a responses section. It avoids redundancy but is somewhat sparse, leaving out potentially useful context without bloat.

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 tool with one parameter and no output schema, the description adequately states the core action and response type. However, it lacks error cases, parameter format details, and an explicit alternative, leaving clear gaps for an AI agent to fully understand when and how to use it.

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 0%, and the description barely compensates. It implies agent_id identifies the agent via 'single agent's', but provides no format, type context beyond the schema's string type, or examples. The description adds minimal semantic value beyond the field name.

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 states a specific verb ('Discover / re-check') and resource ('a single agent's A2A Agent Card'). The 'single' qualifier effectively distinguishes it from batch discovery tools like trigger_discovery_cycle, making the purpose unambiguous.

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 clearly indicates the tool is for a single agent, but it does not explicitly state when to prefer this over alternatives like get_agent or trigger_discovery_cycle. Usage is implied by the scope ('single agent') but not contrasted with siblings.

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?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Returns comprehensive agent information' but does not state that it is read-only, any authentication requirements, rate limits, or error behavior (e.g., what happens with an invalid ID). The 'Responses: 200' section is minimal and lacks error cases.

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 well-structured and appropriately sized. It front-loads the purpose, then lists the comprehensive fields returned, and ends with a minimal response section. No unnecessary fluff; the field list is informative and earns its place.

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-parameter GET tool with no output schema, the description lists the return fields comprehensively, which covers the expected response content. However, it omits potential error responses (e.g., 404) and any pagination or edge-case behavior, leaving a small gap in completeness.

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 covers 100% of parameters with a clear description for agent_id (unique identifier, example, source). The description's phrase 'by ID' adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.

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 clearly states 'Get full details for a specific AI agent by ID', specifying the verb and resource. The list of returned fields (trust score, verification status, etc.) differentiates it from siblings like get_agent_trust or discover_single_agent, making it the comprehensive 'get agent' endpoint.

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 implies usage for retrieving full agent details but does not explicitly mention when to use this versus alternatives (e.g., for trust-specific info, use get_agent_trust). It provides no exclusions or alternative tool guidance.

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 are provided, so the description must carry the burden. It indicates a read operation ('Get') and includes a standard 200 response, but does not disclose what the trust report contains, whether authentication is required, or any error conditions. This is minimal behavioral transparency.

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 very short: a title and one sentence of substance, plus a response block. It is front-loaded with the verb and resource, and there is no filler. However, the response block is somewhat boilerplate and the description is under-specified, keeping it from a 5.

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?

With one parameter, no annotations, and no output schema, the description should provide context about the trust report, its contents, and any usage notes. It only states that it returns a trust report for an agent, which is insufficient for an agent to know what to expect or how to use the result.

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 description does not mention agent_id at all, and schema coverage is 0%. The parameter is only defined by its name and type (string), with no explanation of how to obtain the agent_id or what format it expects. The description fails to compensate for the schema's lack of information.

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 clearly states it 'Get the trust report for an agent,' using a specific verb and resource. This distinguishes it from sibling tools like get_agent (general agent info) and get_badge_* which retrieve different data.

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 implies usage when an agent's trust report is needed, but provides no explicit guidance on when to prefer this tool over alternatives, any prerequisites, or exclusions. It is a minimal statement of purpose rather than clear usage guidance.

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 are provided, so the description carries the full burden of behavioral disclosure. It only states 'Return embed code snippets' and includes a 200 response with Content-Type: application/json. It does not disclose whether this is a read-only operation, any authentication requirements, rate limits, or side effects. The description lacks sufficient transparency for a tool with no annotations.

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 concise and front-loaded with the main action ('Get Badge Embed Code' and 'Return embed code snippets'). The responses section adds minimal value but is not verbose. It is appropriately sized for a simple tool, though the response section is somewhat tautological.

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 tool has no output schema, no annotations, and only one parameter, the description is incomplete. It does not define what 'embed code snippets' actually are (HTML, iframe, JavaScript?), nor does it describe any variations or options. The description provides no return format details beyond a 200 status and JSON content type, which is insufficient for full understanding.

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 one parameter (agent_id) with 0% description coverage. The description does not mention agent_id at all, nor does it explain its format, meaning, or how to obtain it. Since schema coverage is 0%, the description was expected to compensate but fails to add any meaning beyond the parameter name.

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 clearly states the tool's function: 'Return embed code snippets for an agent's badge.' This uses a specific verb ('Return') and resource ('embed code snippets'), and it distinguishes itself from sibling tools like get_badge_json and get_badge_svg by focusing on embed code rather than raw JSON or SVG.

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 implies usage context by saying it returns embed code for an agent's badge, but it does not explicitly mention when to use this tool versus alternatives (e.g., get_badge_json, get_badge_svg). There is no exclusion or alternative guidance, so usage is implied rather than explicit.

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?

With no annotations, the description carries full behavioral disclosure burden. It only mentions a 200 response and content-type, but does not explain error behavior, invalid agent_id handling, or actual response structure. This is very thin transparency.

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 concise and structured with a clear header and a Responses section. It includes only necessary information, though the Responses section is minimal.

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?

The tool is simple, but the description lacks parameter semantics and behavioral detail. With no annotations or output schema, the description should provide more context about the response shape and possible error conditions. It is not fully self-contained.

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 schema has one parameter agent_id with no description, and schema description coverage is 0%. The description does not explain what agent_id is or how it is used. The description fails to compensate for the missing schema info.

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 clearly states the tool returns badge metadata in shields.io endpoint format, which is a specific verb+resource+format. It distinguishes itself from sibling tools like get_badge_svg and get_badge_embed_code by being the JSON variant.

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?

It provides clear context for usage by mentioning it can be used with the shields.io endpoint URL template. However, it does not explicitly state when to prefer this tool over the SVG or embed alternatives, nor does it give exclusions.

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 are provided, so the description carries the full burden. It only mentions the 200 response and content-type, but does not disclose error responses, authentication needs, or whether the SVG is returned directly or wrapped in JSON. This ambiguity is a notable gap.

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 includes redundant text like 'Get Badge Svg' (mirroring the tool name) and 'Successful Response (Success Response)' which is tautological. It is short but contains filler that does not earn its place.

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?

With no output schema and no annotations, the description leaves critical ambiguity about the response format (SVG vs JSON) and lacks any error or edge-case information. For a simple endpoint, it should explain what the caller gets and any caveats.

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 50%, with agent_id having no description in the schema. The tool description adds no parameter details beyond what the schema already provides, so it fails to compensate for the undocumented agent_id parameter.

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 clearly states 'Return an SVG badge for an agent listing,' which specifies the exact action and resource. It distinguishes this from sibling tools like get_badge_json (returns JSON) and get_badge_embed_code (returns embed code) by explicitly naming SVG.

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?

There is no guidance on when to use this endpoint versus the sibling badge endpoints. It does not mention alternatives, exclusions, or any context such as 'use this when you need the raw SVG.'

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?

With no annotations, the description carries the full burden for behavioral disclosure. It only notes a 200 response with JSON content type, but does not explain ordering, pagination, limit semantics, authentication needs, or what 'snapshot history' means in practice. This is insufficient for a tool with no annotation support.

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 short and front-loaded with the main sentence, but it includes a boilerplate 'Responses' section that restates standard HTTP success info without adding meaningful detail. It is not bloated, but the structure does not significantly aid comprehension.

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 absence of an output schema and annotations, and only minimal parameter schema, the description should provide more context about the return format, limit behavior, or historical ordering. It does not, leaving the agent with an under-specified tool definition.

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 0%, so the description must compensate, but it never mentions the parameters (agent_id, limit). The schema provides types and constraints (e.g., limit default 10, max 50), but the description adds no semantic meaning beyond that, such as what limit refers to or how agent_id is used.

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 clearly states the tool fetches AgentCard snapshot history for an agent, using specific verb+resource ('Get Card History'). It is distinguishable from sibling tools like get_agent or get_agent_trust, though it does not explicitly call out those differences.

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no contrast with other getter tools. The description is purely definitional and leaves the agent to infer appropriate usage.

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?

With no annotations provided, the description carries the full burden. It discloses what the tool returns ('current status, any matched agents, and timestamps') and mentions the 200 response. However, it does not explicitly state that the operation is read-only, nor does it mention potential errors, authentication needs, or side effects. This is a moderate level of transparency for a simple status getter.

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 short and front-loaded with the title 'Get Intake' and a clear one-sentence purpose. The 'Responses' section is slightly generic but not wasteful. Overall, it is efficient and easy to scan.

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 single-parameter tool with no output schema, the description adequately explains the return content (status, matched agents, timestamps) and the expected success response. It lacks error handling details and example usage, but for a simple status check it is reasonably complete.

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 0%, so the description must compensate for parameter meaning. It does not mention 'intake_id' at all, nor its format or source. The parameter name is somewhat self-explanatory, but the description adds no value beyond the schema's basic type/required information.

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 clearly states the tool's purpose: 'Check the status of a previously submitted broker intake request.' It uses a specific verb ('check') and resource ('broker intake request'), and the name 'get_intake' aligns with the sibling 'submit_intake' to distinguish retrieval from creation.

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 implies when to use it: after a 'previously submitted' intake request. This provides clear context for use, and the sibling tool 'submit_intake' makes the alternative obvious, but the description does not explicitly mention when not to use it or name alternatives.

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?

With no annotations, the description carries the full burden of disclosing behavior. It only mentions a generic 200 response with content-type, but does not state that this is a read-only operation, potential side effects, rate limits, or what data is actually returned. The NUT-06 reference is a protocol spec, not behavioral transparency.

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 short and uses a clear structure with headings and a response section. There is slight redundancy in repeating 'Get Mint Info' in the heading and first sentence, but overall it is efficient and appropriately sized for a simple tool.

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 lack of an output schema and the presence of many sibling tools, the description is incomplete. It does not describe what information is returned (beyond a generic success response), any examples, or how the output might be structured. For a tool called 'get_mint_info', users need to know what fields are in the response, but that is absent.

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 0%, and the description does not explain the 'mint_url' parameter beyond its name. While the parameter name is self-explanatory, the description adds no extra meaning about format, requirements, or the meaning of the default value. The tool relies entirely on schema structure, which is minimal.

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 states a specific verb and resource: 'Get info about a Cashu mint (NUT-06).' This clearly distinguishes it from sibling tools like get_mint_keys and get_mint_keysets, which are for other aspects of the Cashu protocol.

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 provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context such as 'use this when you need general mint information rather than keys or keysets.'

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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action and a 200 response content type. It does not explicitly confirm read-only behavior, permissions, error cases, or any side effects, leaving critical safety information unstated.

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 concise and front-loaded: the first sentence states the core purpose, and the response section is minimal and directly relevant. There is no redundant filler or unnecessary elaboration.

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?

The tool is simple (one optional parameter, no output schema), and the description provides the essential purpose and protocol reference. However, it lacks usage guidance and parameter semantics, which are needed for confident invocation, making the description minimally viable but not fully complete.

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 0%, and the description does not mention or explain the sole parameter 'mint_url' at all. The default value appears only in the schema, and the description adds no meaning beyond the raw field name, failing to compensate for the lack of schema documentation.

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 states a specific action ('Get active public keys from a Cashu mint') and references the NUT-01 protocol, clearly distinguishing it from related mint tools such as get_mint_keysets_get. The verb and resource are explicit, making the tool's purpose unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or exclusions, and fails to contrast with sibling tools like get_mint_keysets_get. The agent receives no decision support for tool selection.

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?

The description indicates a GET-like read operation but does not explicitly disclose that it is read-only, mention authentication requirements, or describe error behavior. Since no annotations are present, the description carries the full burden, but it only states the obvious action without enriching behavioral context.

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 concise, with two short sentences and a response status heading. The response section adds little value, but overall the text is economical and front-loaded with the main purpose.

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 GET tool, the description provides a basic summary of what it does, but it lacks parameter guidance, behavioral nuances, and clarity on when to choose this over similar mint-related tools. Given the minimal schema and missing annotations, it is minimally viable but not fully complete.

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 one parameter (mint_url) with 0% description coverage, and the description does not explain its purpose, type, or how it affects the result. Although the parameter name is self-explanatory, the description fails to compensate for the lack of schema docs.

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 clearly states the tool retrieves all keysets from a Cashu mint per NUT-02, using a specific verb and resource. Mentioning NUT-02 distinguishes it from sibling tools like get_mint_keys (NUT-01), so purpose is unambiguous.

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 implies use when fetching keysets from a Cashu mint, but it does not explicitly state when to use this tool over alternatives, such as get_mint_info or get_mint_keys. No exclusions or when-not-to-use guidance is provided, so usage guidelines are only implied.

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 are provided, so the description carries the full burden of behavioral disclosure. It does not mention authentication, read-only nature, error responses, or any side effects. The only behavioral hint is the '200 Successful Response' section, which is minimal.

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 brief, with no extraneous content. It front-loads the key purpose and includes only a minimal 'Responses' section. Every sentence serves a purpose.

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 GET with one parameter, the description covers the essentials but lacks return value details, error behavior, and any prerequisites. The absence of an output schema and annotations increases the need for more context, which is not 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 0% and the description does not explicitly explain the agent_id parameter beyond the phrase 'an agent's,' implying it identifies the agent. This adds little meaning over the schema itself, which only provides the name and type.

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 states a specific verb and resource: 'Get an agent's ecash payment profile.' This clearly differentiates it from siblings like update_payment_profile (update) and agent_payment_summary (summary).

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 implies usage when you need the full payment profile, but it does not explicitly contrast with the similar agent_payment_summary tool or mention exclusions. There's no guidance on when to prefer this over alternatives.

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 are present, so the description carries the full burden of behavioral disclosure. It only states the tool returns registry-wide statistics and lists a 200 success response, without revealing authentication needs, rate limits, what data is actually returned, or any side effects. This is insufficient for transparency.

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 very concise and front-loaded with its purpose, consisting of two core sentences. The 'Responses' section is somewhat redundant ('Successful Response (Success Response)') but provides the content type, adding minor value. Overall, it is efficient with minimal fluff.

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 zero-parameter endpoint, this description is minimally viable. However, it lacks specifics about what statistics are included, how they are aggregated, or any error conditions beyond 200. Given no output schema or annotations, the description could have provided more context about the expected response.

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 tool has zero parameters and an empty schema, so there is nothing to document. The description adds no parameter information, but none is required; this meets the baseline for a parameterless tool.

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 clearly states the tool's action ('Get Registry Stats') and resource ('registry-wide statistics'), making the purpose specific. It implicitly distinguishes itself from sibling endpoints like list_agents or get_mint_info by focusing on aggregate registry stats, though it does not explicitly compare itself to alternatives.

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 provides no guidance on when to use this tool versus the many sibling endpoints, nor does it mention exclusions or alternative tools. It merely states what it does, leaving the agent without context for tool selection.

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 are provided, so the description carries the full burden. It discloses that the tool returns discovered agent cards, capabilities, and errors, which is useful. However, it does not mention read-only behavior, potential side effects, authentication requirements, or pagination behavior beyond the return content.

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 concise and structured with a heading, summary, and response section. It avoids excessive detail, though the opening 'Get Scan Results' and 'Get recent A2A Agent Card scan results' are somewhat redundant.

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 GET endpoint with two pagination parameters, the description provides basic return information (agent cards, capabilities, errors) but misses key context such as how pagination works (limit/offset defaults and effects) and any conditions under which scan results are available. Without an output schema, more detail would be expected.

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 0%, and the tool description says nothing about the limit and offset parameters. The parameter names are intuitive (pagination), but the description fails to compensate for the lack of schema descriptions, leaving default behavior and constraints unexplained in prose.

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 clearly states 'Get recent A2A Agent Card scan results' with a specific verb (get) and resource (scan results). It distinguishes itself from sibling tools like trigger_scan_api_scanner_scan_post by focusing on retrieval rather than initiation.

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 implies this tool is for retrieving scan results, but it does not explicitly state when to use it versus alternatives (e.g., trigger_scan_api_scanner_scan_post for initiating scans) or mention any prerequisites or exclusion criteria.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the return is a paginated list and enumerates the fields included, but doesn't disclose authentication requirements, rate limits, or sorting behavior. This is sufficient for a simple read-only list, but not particularly rich.

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 mostly concise and front-loaded with the purpose, but includes a redundant header 'List Agents' and a nearly empty 'Responses' section that only states '200: Successful Response' and content type. This is minor waste but not a major issue.

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?

The description gives a good overview of returned fields and directory size, which helps an agent understand the tool's output without an output schema. It doesn't explain pagination mechanics or error cases, but for a straightforward listing tool with clear schema parameters, it is reasonably complete.

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%, and the description only mentions 'optional filtering and pagination' without adding details beyond the schema. The schema already documents limit, offset, and category with examples, so the description adds minimal additional meaning.

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 clearly states the tool lists AI agents in the Agentry directory, which is a specific verb+resource. The inclusion of 'with optional filtering and pagination' further clarifies scope. It distinguishes from siblings like search_agents and get_agent by focusing on listing rather than searching or retrieving a single agent.

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 implies the tool is for browsing the agent directory with optional filtering and pagination, but does not explicitly state when to use it over alternatives like search_agents or list_categories. No exclusions or alternative tool recommendations are provided.

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?

With no annotations provided, the description carries the full burden. It transparently describes the return structure with an example response showing category and count fields, and states that it returns every category. It does not mention authentication or side effects, but the read-only nature is implied by 'List'.

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 concise and front-loaded, beginning with a clear statement of what it does. It includes a helpful response example without unnecessary verbosity.

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 tool's simplicity (no parameters, no output schema), the description is complete. It defines the response shape via an example and clarifies scope (all categories, counts). No additional details like pagination are necessary for this simple read.

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 tool has zero parameters, so the input schema is empty and there are no parameter descriptions needed. The description does not add any parameter information, but the baseline for 0 params is 4.

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 clearly states 'List all agent categories with counts' and 'Returns every category in the directory along with the number of agents in each,' specifying the verb, resource, and output. This distinguishes it from sibling tools like list_agents_api_agents_get, which lists agents rather than categories.

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 explicitly notes it is 'Useful for building category filters or understanding the directory's coverage areas,' providing clear use cases. However, it does not mention any alternatives or when not to use it, so it lacks the exclusionary guidance for a 5.

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 are provided, so the description carries the full burden of behavioral disclosure. It states the response content type but does not mention authentication requirements, pagination, error responses, or any side effects. For a read operation, it should at least note if results are paginated or if there are any limits.

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 concise but includes a redundant heading 'List Ecash Agents' that repeats the tool name and the first sentence. It fronts the key purpose, but the duplicate could be trimmed for tighter structure.

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 0-parameter list tool, the description covers the core purpose and response format. It lacks guidance on result structure or pagination, but given the low complexity and absence of output schema, it is reasonably complete.

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 tool has zero parameters, so the description need not explain parameter meaning. The baseline of 4 applies, as the empty schema already fully covers the absence of parameters.

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 clearly states the tool lists all agents with ecash payments enabled, using a specific verb ('list') and resource ('agents that have ecash payments enabled'). This distinguishes it from sibling tools like list_agents, which likely list all agents, and get_agent, which targets a single agent.

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 implies the usage context: when you need to list ecash-enabled agents. However, it provides no explicit guidance on when to prefer this tool over alternatives like list_agents or search_agents, nor does it mention any exclusions.

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?

With no annotations, the description must carry the full burden of behavioral disclosure. It only mentions optional filters and a 200 response, but fails to disclose pagination behavior, default values, response structure, or the read-only nature of the operation. This is insufficient.

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 concise and front-loaded, but the heading 'List Transactions' is redundant with the first sentence. Minor redundancy aside, it is efficient and easy to scan.

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 4 optional parameters, no output schema, and no annotations, the description should offer more context. It lacks information about pagination, default values, return structure, and edge cases, leaving significant gaps for effective tool use.

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 0%, so the description should explain each parameter. It mentions filtering by agent or type (mapping to agent_id and tx_type) but omits limit and offset entirely. It provides minimal value beyond the parameter names.

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 clearly states the tool lists ecash transactions with optional filtering by agent or type. It uses a specific verb ('list') and resource ('ecash transactions'), and the mention of filters distinguishes it from generic list tools.

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 implies when to use the tool (when you need a list of ecash transactions), but it provides no explicit alternatives or exclusions. Given the many payment-related siblings, more guidance would help, but the core use case is clear.

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?

With no annotations, the description carries the full burden. It discloses the HTTP response (402 status, X-Cashu headers, body) and the payment flow. However, it lacks details on authentication requirements, error cases, and side effects. The inclusion of a '200: Successful Response' section is inconsistent with the stated 402 behavior, adding confusion.

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 mostly concise and uses bullet points for clarity. However, the 'Responses: 200' section is misleading and contradicts the tool's stated purpose, wasting space and potentially confusing the agent. Otherwise, every sentence contributes to understanding the endpoint's behavior.

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?

The description explains the response format and the follow-up payment flow, which is useful for a simple one-parameter endpoint. Yet it omits important operational details like authentication, error handling, and the exact structure of the body. The presence of an irrelevant 200 response further detracts from completeness.

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 0%, and the description does not explain the agent_id parameter. It only appears in the endpoint path, leaving its role implicit. The description provides no additional meaning about what agent_id represents or how it is used.

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 states a specific verb and resource: 'Return a 402 Payment Required response with X-Cashu headers.' It also explains the business purpose (advertise charges) and the overall flow, clearly distinguishing it from sibling payment tools like send_ecash or create_quote.

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?

It gives clear context for when to use this endpoint: when an agent wants to charge for services. It also explains the calling agent's next steps (mint a token and send via /send or X-Cashu header), providing usage guidance. However, it doesn't explicitly mention when not to use it or name alternative tools.

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?

With no annotations provided, the description carries the full burden. It discloses the key behavioral trait of swapping proofs at the mint to prevent double-spending, which is valuable. However, it does not mention side effects like token consumption, crediting to the agent, or idempotency, leaving gaps for a mutation operation.

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 short and front-loaded with the purpose, followed by a brief behavioral explanation and a minimal response section. It's efficiently written with no fluff, though the response section could be slightly more informative without harming conciseness.

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 two-parameter tool with no output schema and no annotations, the description provides the core flow but omits critical details like the exact response body, error cases, and what agent_id represents. It's not fully complete but is more informative than a bare one-liner, earning a middle score.

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 0%, so the description must compensate. It clarifies that 'token' is a Cashu ecash token, but provides no meaning for 'agent_id', which is a required parameter. This leaves the agent guessing about the role of agent_id, making the description insufficient for parameter understanding.

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 specific verbs 'Receive/redeem' and names the resource 'Cashu ecash token', making the tool's purpose immediately clear. It also distinguishes from siblings like 'send_ecash' by describing the receive flow and even cites the standard NUT-03 swap.

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 implies the usage context: it is for receiving/redeeming ecash tokens, as opposed to sending or verifying. While it doesn't explicitly name alternatives or state when not to use the tool, the context is clear enough that an agent would know this is the counterpart to send operations.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the agent is added immediately, appears in search results, and that an A2A discovery scan is triggered if the URL is reachable. It also notes optional fields improve discoverability. This is solid coverage of key behavior.

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 well-structured with a heading, clear explanatory paragraphs, and a response section. It is front-loaded with the main purpose and contains no filler. Though longer than a two-sentence model, every sentence serves a purpose.

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 tool's complexity (11 parameters, 2 required, no output schema), the description covers the essential context: what the tool does, immediate effects, optional field benefits, and the 201 response. It does not mention failure cases or authentication, but for a registration tool with a schema-rich parameter list, this is adequate.

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 covers 100% of parameters, so the baseline is 3. The description adds value by explaining that optional fields (pricing, features, integrations) improve discoverability, and implies that the URL is used for A2A scan triggering, enriching the schema's bare definitions.

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 clearly states the tool's function: 'Register a new AI agent in the Agentry directory' with a specific verb (register) and resource (AI agent). It distinguishes from siblings by focusing on new agent registration versus claiming, discovery, or listing operations.

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 provides clear context for when to use this tool: to submit an AI agent for listing, with immediate addition and search visibility. It does not explicitly mention alternatives or when not to use it, but the context is unambiguous enough for basic selection.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the schema by explaining that the search is full-text across multiple fields and that results are ranked by relevance with trust scores, pricing, and capability metadata. This covers the core behavior and return content, though it does not mention pagination behavior or rate limits.

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 front-loaded and relatively concise, with the first sentence defining the tool's purpose. However, it includes a redundant '### Responses' section that states 'Successful Response' and 'Content-Type' without useful information, which adds slight clutter. Overall, it is mostly efficient.

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?

The description explains what the tool returns (matching agents, ranking, trust scores, pricing, metadata) even though there is no output schema. It covers the search scope and output content sufficiently for a search operation. Pagination is left to the schema's limit/offset parameters, which is acceptable.

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%, and the schema descriptions already provide detailed parameter semantics including examples, ranges, and constraints. The tool description adds no additional parameter-specific meaning, so the baseline of 3 is appropriate.

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 clearly states the tool searches the agent directory by keyword, specifies the exact fields searched (names, descriptions, features, integrations), and describes the output (ranked results with trust scores, pricing, capability metadata). This distinguishes it from sibling tools like list_agents, which likely returns all agents without keyword ranking.

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 clearly implies when to use this tool: when you need to find agents by keyword. However, it does not explicitly mention alternatives (e.g., list_agents for browsing all agents, or get_agent for fetching a single agent) or state when not to use it. This is clear context but lacks explicit differentiation guidance.

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?

With no annotations provided, the description carries the full burden. It discloses that the token is bearer (a security warning), explains what happens in each mode (verify/record vs. return minting instructions), and states that the endpoint records intent and provides the token. Missing details like potential side effects or idempotency, but it provides substantial behavioral context.

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 concise and well-structured: a clear heading, two bullet points for modes, a security warning, and a responses section. Every sentence adds value, and it is front-loaded with the main purpose.

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 payment tool with 5 parameters and no output schema, the description should explain return values and edge cases. It lacks specifics about the 200 response body and possible errors. However, it covers the two operational modes and the bearer-token nuance, making it reasonably complete for a simple transfer operation.

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 0%, so the description must compensate. It clarifies the 'token' parameter by specifying it is a pre-minted cashu token and notes the optional no-token mode. However, other parameters (sender_agent_id, recipient_agent_id, amount_sats, memo) are not explicitly described, though their names are fairly self-explanatory. Some compensation is made, but not fully.

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 clearly states 'Send ecash tokens from one agent to another', which is a specific verb+resource. It distinguishes from sibling tools like receive_ecash by focusing on the sending action, and the two modes add further clarity on how sending works.

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 gives clear context on when to use the tool (sending ecash between agents) and explains two modes (with or without a pre-minted token). However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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 are provided, so the description carries the full burden. It only mentions a generic 200 response and does not disclose side effects (e.g., email dispatch), required permissions beyond 'Admin', error responses, or rate limits. This is a significant gap for a mutation-like tool.

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 short and front-loaded with the core action. However, the first line 'Send Outreach' is redundant with the tool name, and the response section is generic. Overall, it is concise and readable, with only minor waste.

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 endpoint with two parameters and no output schema or annotations, the description is incomplete. It lacks error handling, authentication requirements, and details about the response payload or whether outreach is actually sent. The agent would need more information to fully understand the result and potential failures.

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 0%, so the description must compensate for parameter meaning. It mentions 'specific agent contact' but does not explicitly define 'agent_id' or 'contact_email'. The parameter names are self-explanatory, but the description adds minimal value and does not map them to the tool's workflow.

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 clearly states the tool's purpose: 'Admin endpoint to send trust score outreach to a specific agent contact.' This uses a specific verb ('send'), a specific resource ('trust score outreach'), and target ('specific agent contact'), distinguishing it from sibling tools.

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 provides clear context by labeling it as an 'Admin endpoint' and specifying it sends trust score outreach to a specific agent contact. It does not explicitly mention alternatives or when not to use, but the context is sufficiently clear for a unique action.

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 are provided, so the description carries the full burden. It does disclose some behavioral outcomes: a confirmation email will be sent and a broker specialist will follow up. It also mentions a 201 response. However, it does not detail side effects, data handling, idempotency, or other important behavioral traits, leaving gaps.

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 concise and front-loaded, beginning with 'Submit Intake' and a clear one-sentence summary. The additional 'Responses' section is somewhat redundant but not harmful. Overall, it is appropriately sized and well-structured, though the response section could be trimmed.

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 tool's complexity (7 parameters, no annotations, no output schema), the description is insufficient. It explains the high-level purpose but does not provide enough detail about parameter semantics, prerequisites, or exactly what a successful submission entails. An agent would struggle to correctly populate the fields without additional information.

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 7 parameters with 0% description coverage, yet the description offers no parameter-level guidance. It only generically says 'Provide your business details and requirements,' failing to explain what each field (email, needs, tools, budget, etc.) means or how to populate them. This is a severe deficiency for invocation.

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 clearly states the tool's purpose with a specific verb and resource: 'Submit a broker intake request to find the right AI agent for your needs.' This distinguishes it from sibling tools like get_intake, which retrieves intake data. The purpose is unambiguous and specific.

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 provides clear context on when to use the tool: when you want to submit business details and requirements to be matched with AI agents. It also mentions the follow-up process. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of full guidance.

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?

With no annotations, the description must disclose behavioral traits, but it only mentions a 200 response. It does not state whether the operation is long-running, destructive, requires admin privileges, or produces any side effects beyond triggering the cycle.

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 brief and front-loaded with the purpose. The 'Responses' section adds minimal value but does not bloat the description significantly.

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 no output schema and sparse annotations, the description should explain what a successful discovery cycle returns or what the JSON content includes. It does not, nor does it mention error cases or operational expectations.

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 tool has zero parameters and an empty schema, so there is nothing to explain. Per the baseline for zero params, this scores 4.

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 clearly states the tool triggers a full discovery cycle across all agents, using a specific verb and resource. This differentiates it from the sibling tool discover_single_agent, which only handles one agent.

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 provides no guidance on when to use this tool versus alternatives. It does not mention discover_single_agent or other discovery-related tools, nor any conditions or prerequisites.

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?

With no annotations provided, the description carries the full burden. It clearly discloses that the tool performs a network scan, extracts metadata, and stores results. It also mentions the 202 response, suggesting asynchronous acceptance. It lacks details on side effects or auth, but the stored-results behavior and endpoint check are transparent enough for a trigger tool.

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 concise and front-loaded with the primary action, followed by a brief explanation and a response section. Every sentence adds value, but the response section is minimal and could be integrated more neatly. Overall, it is well-structured and not bloated.

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 one-parameter tool with no output schema, the description covers the core action and storage behavior. However, it omits details about asynchronous execution (implied by 202 but not stated) and what the response body contains. This leaves the agent uncertain about the immediate return value and follow-up sequence, so completeness is moderate.

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 schema has one parameter 'domains' with 0% coverage. The description adds meaning by clarifying that domains are checked for /.well-known/agent.json, implying each string is a base domain. However, it does not specify domain format (e.g., with or without scheme, trailing slash), leaving some ambiguity.

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 opens with a specific verb+resource: "Scan domains for A2A Agent Card discovery," and elaborates by checking for /.well-known/agent.json and extracting capability metadata. It clearly distinguishes from sibling tools like trigger_discovery_cycle and get_scan_results by stating it operates on given domains and stores results.

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 implies usage context by stating it scans domains and that results can be retrieved later via the scan results endpoint. However, it does not explicitly contrast with alternatives like trigger_discovery_cycle or state when not to use this tool, so the guidance remains implied rather than explicit.

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?

With no annotations, the description carries the full burden. It discloses auth requirements (registered identity or admin key) and a 200 response, but does not mention side effects, idempotency, or what happens to existing fields. This adds some value but lacks rich behavioral detail.

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 concise and front-loaded, with a clear title and brief paragraphs. The response section is minimal but not overly verbose, so it earns a near-perfect score.

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 complexity (10 parameters, no annotations, no output schema), the description is insufficient. It omits field-level guidance, error scenarios, and operational details, making it incomplete for reliable invocation.

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 0%, yet the description provides no explanation of any of the 10 parameters. It only gives a high-level context of updating a payment profile, which does not add meaning beyond the schema's names and types.

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 clearly states it updates an agent's ecash payment profile, using a specific verb ('Update') and resource ('payment profile'). This distinguishes it from sibling tools like get_payment_profile (read) and other payment tools.

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 provides clear usage context: self-serve for registered agents and admin key for platform operations. It does not explicitly mention when not to use it or alternatives, but the self-serve/admin distinction gives practical guidance.

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?

The description discloses what the verification covers (format, amount, spent status), which adds value. But it does not state whether the operation is read-only, requires authentication, or how errors are returned. Since annotations are absent, the description carries the burden, and this leaves safety and failure behavior unclear.

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 one sentence explaining the purpose and a brief response section. Every sentence earns its place, no redundant text. It is concise and front-loaded with the core purpose.

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 a simple one-parameter tool with no output schema and no annotations, the description explains the core function but lacks response details (what fields are returned), error conditions, and any side-effect notes. This is adequate for basic understanding but leaves gaps for an agent needing full context.

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 0%, and the description does not explain the 'token' parameter beyond calling it a 'Cashu ecash token.' It omits format details, examples, or constraints. The description adds minimal meaning beyond the schema's field name and type.

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 clearly states 'Verify a Cashu ecash token — check format, amount, and spent status.' This identifies a specific verb (verify), a specific resource (Cashu ecash token), and the distinct scope of verification (format, amount, spent status), which distinguishes it from sibling tools like send_ecash and receive_ecash.

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 implies when to use the tool: to verify a token before use. However, it does not explicitly mention when NOT to use it or provide alternative tool names. Context is clear, but there are no exclusions or explicit alternatives.

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