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

No annotations exist, so the description carries the full burden. It does disclose two useful traits — output is unsigned and derived from a template — but says nothing about permissions, whether it persists a file, error behavior for unknown faces, or what the agent gets back.

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?

A single front-loaded sentence with no filler; every clause (card shape, face list, template source, unsigned status) contributes information.

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 annotations, no output schema, and a nested `overrides` object, the description is too thin: it never explains what the built card contains, where it is written, or how overrides merge with the template. An agent can pick the tool but cannot confidently invoke it with overrides.

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 does add real meaning for `face` by enumerating the four valid values (the schema gives only an unconstrained string), but `overrides` — a nested object, the most semantically opaque parameter — is not mentioned at all.

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?

Names a specific verb (Build) and a specific resource (A2A v1.0-shaped Agent Card) scoped 'from its template' for a named set of faces. The trailing 'Unsigned' implicitly separates it from card_sign, but the sibling is never named, so differentiation is inferred rather than stated.

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?

Usage is only implied: 'Unsigned' hints that signing (card_sign) is a separate follow-up step, and 'from its template' suggests this is the generation stage before verify/sign. There is no explicit when-to-use, when-not-to-use, or named alternative.

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 at all, the description must carry the full behavioral load, and it does disclose useful traits: the algorithm (JWS/RS256), that the private key stays in keys/ with chmod 600, that files are written to cards/, and that a JWKS is exported. However, it never says whether an existing card file is overwritten (a destructive side effect that matters here), what identifies the target file, or what the call returns.

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?

One tight sentence with the security posture front-loaded alongside the outputs; every clause (algorithm, destination directory, key location, key permissions) adds real information. It is dense but not padded.

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 two-parameter mutation tool with a nested object, no annotations, and no output schema, the description covers outputs and safety but not inputs or overwrite semantics. An agent knows what the call produces but not how to shape the overrides payload or what happens to pre-existing card files.

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 is the only source of parameter meaning — and it explains neither what a 'face' identifier is nor what the nested 'overrides' object accepts. The single hint ('a face's Agent Card') maps loosely to the required param but leaves the only meaningful input, the nested overrides structure, entirely opaque.

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?

States a concrete verb chain (build + sign), the resource (a face's Agent Card), and the side effects (write to cards/, export public JWKS). It is distinguishable from card_build in principle, but the description never explicitly says how it differs from that sibling, leaving the agent to infer that card_build only builds.

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?

Usage is only implied by the operation itself — an agent can guess you call this when you need a signed card plus a published JWKS, but there is no stated when-to-use, no prerequisite (e.g., must the face exist first?), and no pointer to card_verify or card_build as the 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 behavioral burden. It usefully discloses that verification uses the local JWKS and that tampered cards are rejected, which adds meaningful context beyond the schema. However, it does not state whether the operation is read-only, what errors or return values occur, or what permissions/filesystem access are required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tightly written sentences with no filler. It front-loads the primary validation behavior and follows with the rejection behavior for tampered cards.

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 validation tool, the description covers the core validation and signature-checking behavior. However, with no output schema and no annotations, it leaves important context unstated, especially what a successful or failed validation returns to the caller.

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?

There is one required parameter, card_path, with 0% schema description coverage. The description does not explain that this parameter is a filesystem path or what format it expects, so the agent must infer meaning solely from 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 states a specific verb+resource: it validates a card's schema and verifies its JWS signature against local JWKS. This clearly distinguishes it from sibling tools like card_build and card_sign, which create or sign cards.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when the tool is useful (to validate a card after building/signing), but it never explicitly says when to use it versus alternatives or what preconditions apply. There is no direct routing guidance to siblings such as card_sign or gateway_delegate.

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 behavioral burden and does disclose the pipeline: verify card, certify-check, mandate with budget cap and expiry, dispatch, quarantine ingest, and receipt-on-delivery. It also states important constraints ('No artifact, no payment'), though it omits error modes, permissions, and reversibility details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then compresses the workflow into a compact pipeline. It is dense but not padded; the final 'No artifact, no payment' constraint is useful 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 complex workflow tool with no annotations, no output schema, and 0% schema description coverage, the definition gives a useful pipeline overview and test-scope constraints. It still leaves important parameter semantics and operational preconditions unclear, so it is only minimally adequate overall.

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 six undocumented parameters. It hints at budget cap, expiry, card verification, and local agent types, but does not explain prompt, skill_id, or the exact relationship between the listed agent names and agent_id, leaving most required parameters underspecified.

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: delegating a task through a governed gateway to local test agents. It is clearly distinct in substance from card_build/card_sign/card_verify/receipt_list, though it does not explicitly name those siblings.

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?

Usage is implied by 'LOCAL test agent' and 'No artifact, no payment,' which signal a test-only, non-production scope. However, there is no explicit when-to-use guidance relative to card_verify or receipt_list, and no when-not-to-use conditions beyond the local/test framing.

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. 'Read' signals a non-mutating retrieval and 'Includes chain verification' discloses a meaningful behavior, but it says nothing about pagination via limit, ordering, or what the verification returns.

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?

One compact sentence with the resource front-loaded and no wasted words. Every clause adds information.

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?

There is no output schema and no annotations, so the description should do more to explain result shape and the limit parameter. It covers the ledger contents but leaves an agent guessing about pagination and verification output.

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% for the single optional limit parameter, and the description never mentions it. The name 'limit' is intuitive, but default value, maximum, and pagination behavior are left entirely unspecified.

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?

States a specific verb (Read) and a well-defined resource (the hash-chained delegation ledger), and enumerates what it contains (mandates, refusals, delivery receipts). It is distinguishable from the card_* and gateway_delegate siblings, though it does not name them.

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 given on when to call this versus card_verify or gateway_delegate, nor on prerequisites or exclusions. The read/ledger framing implies a retrieval use case, but nothing is explicit.

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