AffixIO

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

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent already knows this is a non-idempotent non-destructive operation. The description adds only the HTTP route (POST /v1/aamva/parse), with no note on failure modes for malformed payloads, quota/auth needs, or what parsing produces.

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 zero filler; the verb, resource, and endpoint are all in the first clause.

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 could reasonably say what the parse yields (e.g. decoded licence fields) but does not, and there is no guidance on the expected barcode input format. It is minimally adequate for a one-body parse endpoint but leaves the agent guessing about the return shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'body' parameter is documented as a JSON request body quoting the OpenAPI contract. The description adds nothing about the payload format or required fields, so the baseline 3 applies.

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 names a specific verb ('Parse') and a specific resource ('US driving licence AAMVA PDF417 barcode payload'), which is enough to distinguish it from the sibling affix_mrz_parse. It stops short of explicitly naming that alternative, so it is clear but not sibling-differentiating to the level 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 statement of when to use this tool versus alternatives, no prerequisites (e.g. a raw barcode payload is required), and no exclusion guidance. The usage is only implied by the resource named.

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?

Annotations declare readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false — a non-idempotent, non-destructive call. The description adds that it produces a narrative explanation ('so Medusa can explain what happened and when'), but doesn't mention the non-idempotency, side effects, or auth context. It doesn't contradict annotations but adds limited behavioral depth.

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 well-formed sentence with the verb and resource front-loaded, plus the endpoint hint. No filler.

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-param audited read with no output schema, the description is thin — it doesn't explain the response shape, the time window for 'recent', or how to pass credentials. Adequate but leaves gaps an agent must fill by guessing or reading external docs.

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% (single 'body' param with a description pointing to the OpenAPI schema). Description adds nothing about the body content and the schema itself is thin ('See the AffixIO OpenAPI schema resource'), so baseline 3 is fair but no extra value is added.

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 resource ('recent trust events for an agent credential') and even names the endpoint. It's clear what it does, though it doesn't sharply differentiate from sibling affix_merkle_audit or the other affix_agent_trust_* 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 says what it does but not when to choose it over siblings like affix_agent_trust_verify or affix_merkle_audit. No exclusions, prerequisites, or alternative-routing 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?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this is a non-idempotent but non-destructive POST. The description adds that attestation output is optional, but says nothing about required credentials, whether a decision is recorded/consumed, or side effects of the POST.

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 tightly written sentence that front-loads the operation and appends the endpoint cheaply. No filler, though the endpoint path is only marginally informative.

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 authorisation endpoint with no output schema, the description covers the gist but omits what a decision response looks like and whether the call has side effects or quota costs. Adequate but with visible gaps.

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?

Only one parameter exists (body) and schema description coverage is 100%, so the baseline is 3. The description does not expand on the request body beyond naming the resource/action semantics it represents.

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: check whether a verified AI agent is allowed to run a given action against a named resource, and it names the endpoint. It is a genuine authorisation-decision tool, distinguishable from sibling verification tools, though it does not explicitly contrast itself with affix_agent_trust_verify or affix_verify.

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 call this versus the many adjacent trust tools (affix_agent_trust_verify, affix_delegate_verify, affix_gate_verify, affix_verify_policies). The usage context is only implied by the word 'authorise'.

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 annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description doesn't need to restate safety. However, the description adds little beyond the endpoint path: it doesn't explain that this is a non-idempotent POST that returns a badge but doesn't persist a destructive change, nor does it mention auth requirements or whether the badge is one-time.

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, tightly worded sentence with the endpoint parenthetical at the end. It is front-loaded and wastes no words, though it could be slightly more informative for the same length.

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 one-parameter tool with no output schema and annotations covering the safety profile, the description is minimally adequate. It is missing guidance on when to use it vs siblings and any behavioral notes about the non-idempotent POST, which is the main 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 coverage is 100% (the single body parameter is described as pointing to the OpenAPI schema resource), so the baseline is 3. The description adds no parameter details beyond what the schema provides.

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 (Return) and resource (public trust badge payload) and scopes it to a verified agent credential. It is clear what the tool produces, though it doesn't explicitly distinguish itself from the sibling agent_trust tools (verify, enrol, authorise, audit).

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 like affix_agent_trust_verify or affix_agent_trust_audit, nor any prerequisites or exclusions. The agent must infer usage from the name alone.

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?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, closed-world write, so the safety profile is covered. The description usefully adds the endpoint and the framing that this is pre-authorisation enrolment, but it does not say what happens to an existing credential on 'refresh', whether it requires auth, or how failures surface.

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 the action first, then audience, then route; nothing is padded or restated. It could be tightened only marginally, e.g. the endpoint parenthetical could be dropped if the server details cover it.

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 so return values need not be explained, and annotations cover the mutation profile. The remaining gap is the request body: the description and schema both punt to an external OpenAPI resource, so an agent has no in-band hint about required fields for an enrolment call.

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?

Only one parameter (body) and schema description coverage is reported at 100%, so the baseline is 3. However, the schema text is merely a deferral ('See the AffixIO OpenAPI schema resource for the contract'), so the description adds no field-level meaning beyond what the schema pointer provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb pair ('Create or refresh') plus a precise resource ('AffixIO agent-trust credential') and scope ('for an AI agent ... for a user or merchant'), with the HTTP route supplied. It is clearly distinct from siblings like affix_agent_trust_verify or affix_agent_trust_authorise, though it never names those siblings to make the contrast explicit.

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?

'before it acts for a user or merchant' gives an implicit timing condition that tells the agent when this is needed in a flow. There is no explicit when-not guidance, no mention of prerequisite steps (e.g. prerequisite identification of the agent) and no pointer to the alternative tools (verify/authorise/audit) if a credential already exists.

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?

Annotations already declare the safety profile (non-read-only, non-idempotent, non-destructive, closed-world), and the description adds the POST route and the shape of the returned state (scope/subject/expiry), which is genuinely useful with no output schema. It does not explain why verification is flagged non-idempotent, nor any auth or rate-limit 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?

A single well-formed sentence that front-loads the verb and resource before the return values and route. No redundant or filler text, though the parenthetical route is arguably metadata rather than definition.

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 one-parameter verification call with no output schema, the description usefully enumerates the return fields and the HTTP route. It still omits how the credential is supplied in the body and any auth or failure-state context an agent would need to call it confidently.

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?

Only one optional 'body' parameter and schema coverage is 100%, so per the rubric the baseline is 3. The description confirms the endpoint but adds no detail on what the body must contain (the credential itself?), leaving the schema's pointer-style body description to carry the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb 'Verify' plus a precisely named resource, 'AffixIO agent-trust credential', with the returned fields (scope, subject, expiry) spelled out. This distinguishes it from other verify siblings like affix_token_verify or affix_delegate_verify by resource, though it never explicitly contrasts with 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?

The description states what happens but gives no when-to-use context, no prerequisites (does a credential need to be enrolled first?), and no guidance on choosing this over affix_agent_trust_authorise, affix_gate_verify, or the other verify 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?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds no behavior beyond that: nothing about side effects, auth requirements, rate limits, or what an aggregate call actually does; the endpoint path (POST /v1/aggregate/verify) is the only marginal addition.

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 front-loaded sentence with no wasted words and the key qualifier ('multiple/aggregate') placed first. It is efficient, though arguably too terse for the tool's complexity.

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 an aggregate tool that takes an opaque JSON body, has no output schema, and carries only minimal annotations, the description omits what gets aggregated, what the response looks like, and any prerequisites. An agent has almost nothing beyond the endpoint to call this correctly.

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 a single optional 'body' parameter whose schema description is present (100% coverage), so the baseline is 3. The description adds no meaning about the body contract, only pointing to the endpoint path; it defers entirely to the OpenAPI 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?

States a specific verb and resource ('Run multiple verifications in one aggregate call'), and the word 'multiple/aggregate' implicitly separates it from the single-verify siblings like affix_verify. It stops short of naming any alternative explicitly, so it is clear but not fully differentiated.

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

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

The phrase 'multiple verifications in one aggregate call' implies the batch use case, but there is no explicit when-to-use/when-not guidance and no named alternative among the many *_verify siblings. Usage is left to inference.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the request must be authenticated and the target must be a /v1 or /api endpoint. It omits error semantics and rate limits, so not a 5.

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?

Two tight sentences with the action front-loaded and no filler. Every clause carries information (auth requirement, endpoint scope, parameter source).

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 generic API passthrough with no output schema and full schema coverage, the description gives enough to construct a correct call. It could still note the response/error shape or where the OpenAPI spec lives, but nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema, including the 'without a query string' constraint on path. The description adds no syntax or format detail beyond what the schema provides, which is the expected baseline.

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 and resource: an authenticated GET against AffixIO /v1 or /api endpoints. The read/write distinction against the sibling affix_api_write is inferable from the name and the word 'GET', though the sibling is never named explicitly.

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 points the agent at 'the published OpenAPI path and query parameters' as the source of truth, which implies this is the generic passthrough for any read endpoint. However it never says when to prefer this over affix_api_write or the many purpose-built affix_* tools, and offers no 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the mutation risk is covered. The description adds real context beyond that: requests are authenticated, and access is limited to /v1 and /api paths with admin surfaces excluded. It stops short of describing error behavior or rate limits, so not a 5.

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?

Two tight sentences with zero filler; the operation and its scope constraint are both front-loaded. Nothing in the text is redundant with the schema or annotations.

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 generic authenticated write proxy with no output schema, the description covers the write methods and the reachable path space, which is the minimum an agent needs. It omits anything about response shape, error handling, or how credentials are supplied, leaving real gaps for a tool this broad.

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 75%, so the schema already documents body, path, query, and the method enum. The description's mention of the three methods and the /v1 or /api path prefixes reinforces the two required parameters but adds no format, syntax, or example detail beyond the schema. Baseline 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?

States a specific verb set (POST/PATCH/DELETE) and resource (AffixIO /v1 or /api endpoint) in one clause, immediately distinguishing it from the read counterpart affix_api_read. The added scope note about excluded administration paths sharpens rather than muddies the purpose.

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?

Gives explicit negative scope ('Account, key, OAuth and webhook administration paths are not exposed'), which tells the agent when this tool will fail. It doesn't name affix_api_read as the alternative for GET, but the read/write split is unambiguous from the verb list.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context about the key's algorithm and offline verification purpose, but does not disclose return format, key rotation behavior, or any auth requirements.

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 zero waste. It states the action and the artifact without unnecessary 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?

For a simple key-retrieval tool, the description states the returned artifact and its purpose, but with no output schema it omits the key's encoding/format and gives no guidance on valid query parameters. It is adequate but leaves gaps an agent may need to fill.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter has its own description ('Optional query parameters.'), so the schema carries the burden. The tool description adds no parameter meaning beyond that baseline.

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 ('Get') and resource ('public key used to verify ML-DSA-65 attestations'), and the resource is unique among siblings (a key retrieval, not a verification or audit operation). An agent can distinguish it from affix_verify and other affix tools without opening the schema.

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

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

The phrase 'for offline verification' gives a clear intended use case, telling the agent when this key is needed. However, it does not explicitly name alternatives (e.g. online verification tools) or state when not to use it.

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 only repeats the operation and the endpoint. Annotations state it is non-read-only, non-idempotent, non-destructive, but the caller gets no context on prerequisites (e.g., witness must be prepared first), cost/latency, or what the proof output looks like.

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?

It is a single sentence and front-loaded, but the sentence mostly repeats the title and endpoint, which is low value.

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 a non-idempotent write with no output schema and no annotations describing side effects. The description should explain preconditions (witness preparation), the form of the result, and whether calls are billed; none of this is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both circuitId and body are documented in the schema, and the body is deferred to the OpenAPI schema resource. The description adds nothing beyond the schema, so the baseline of 3 applies.

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?

A specific verb and resource: 'Generate a zero-knowledge proof for a circuit'. It is clearly distinguished from sibling tools like affix_circuit_verify (which presumably verifies) and affix_witness_prepare. The agent knows exactly what this tool does.

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 such as affix_circuit_verify, affix_witness_prepare, or affix_proof_ref_verify. The agent must infer the correct workflow position on its own.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds nothing beyond restating purpose – no note that it's non-idempotent, no mention of permissions, failure modes, or that verifying a proof is a state-touching operation despite sounding like a read. No added 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?

Single concise sentence with the endpoint path included. Efficient, though perhaps under-specified for the complexity of the operation.

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?

A proof-verification tool with no output schema, no annotations explaining the non-idempotent, non-readOnly profile, and only a pointer to external OpenAPI schema for the request body. An agent lacks enough context to know what a successful verification returns or what the body needs beyond 'see the OpenAPI schema'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are documented in the schema. The description only names circuitId via the URL path, adding nothing about the request body's proof/witness fields beyond pointing to the OpenAPI schema. Baseline 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?

States a specific verb ('Verify') and resource ('zero-knowledge proof for a circuit'). Clear purpose, though it doesn't differentiate from siblings like affix_aggregate_verify, affix_proof_ref_verify, or affix_merkle_verify_proof, which are all verification 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?

No guidance on when to use this tool versus alternatives. With many sibling verification tools (aggregate_verify, proof_ref_verify, merkle_verify_proof, circuit_prove), an agent must infer selection criteria on its own.

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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. Even so, the description adds zero behavioral detail: it does not say whether issuance requires prior authentication/enrolment, whether the resulting proof is single-use or how long it lives, or what triggers failure. For a state-creating POST tool this is a meaningful 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?

One front-loaded sentence with no filler; the endpoint is a useful anchor. It is efficient, though the extreme terseness leaves useful space unused for a mutation 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?

No output schema exists, so the description should describe what issuance returns (proof format, identifiers, expiry) and how to use it — it says nothing. With no usage context and no return-value explanation for a POST operation, the definition is too thin for an agent to call confidently.

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 a single `body` parameter with full schema description coverage, so the schema carries the contract (deferring to the AffixIO OpenAPI resource). The description adds no parameter meaning beyond what the schema provides, which is the baseline-3 case when coverage is high.

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 ('Issue') and resource ('delegated-authority proof') plus the underlying endpoint, which is enough to distinguish it from sibling verbs like affix_delegate_verify. It does not, however, explicitly contrast itself with siblings such as affix_token_issue or affix_agent_trust_authorise, so differentiation is only implied by the resource name.

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 when-to-use guidance, no prerequisite or ordering information, and no mention of the obvious alternative affix_delegate_verify (the natural counterpart for checking such a proof). The agent must infer the correct context entirely from the tool name.

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?

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, which is notable for a 'verify' verb and hints the call may consume or mark the proof. The description adds nothing about side effects, whether the proof is single-use, or auth requirements — it only restates the verb and route. With annotations carrying the safety profile, the description still contributes almost no behavioural 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?

One short sentence with the verb and resource front-loaded and the HTTP route appended as a compact locator. No filler or redundancy.

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 verification endpoint with no output schema, the description says nothing about what a result means, how an invalid proof is reported, or whether verification consumes the proof — the most important questions for a non-idempotent, non-read-only verify call. Against a very dense sibling namespace, this leaves real gaps.

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 a single opaque 'body' parameter and the schema description coverage is 100%, so the structured data nominally covers the parameter. The description adds nothing about what the body must contain (proof encoding, delegated authority fields), which is the baseline 3 for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and a specific resource ('Verify a delegated-authority proof') plus the backing route, which differentiates it from the many other verify siblings (agent_trust_verify, circuit_verify, merkle_verify_proof) by resource. It stops short of naming the issuance counterpart affix_delegate_issue or any sibling explicitly, so it is clear but not fully differentiated.

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 call this versus affix_delegate_issue, affix_proof_ref_verify, or affix_verify, and no stated prerequisites (e.g. needing a proof produced by affix_delegate_issue). Usage must be inferred entirely from the name.

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?

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds only the HTTP method and path, and says nothing about what completing a session does, whether it can be replayed, or what auth it requires.

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; the action and endpoint are stated immediately. It is efficient, though extremely terse.

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?

No output schema exists, so the description should carry more of the burden: it never explains the result of completing a session or the precondition that a session must exist. For a state-changing gate operation, this leaves notable gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the id path segment and the body are documented in the schema), so the baseline of 3 applies. The description adds no extra meaning about the id or body contract beyond pointing at the OpenAPI resource.

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 ('Complete') and resource ('multifactor gate session'), which is enough to separate it from affix_gate_multifactor_start, _factor, and _get. It stops short of explicitly contrasting those siblings, but the action 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?

There is no statement of when to call this versus the sibling gate tools (start/factor/get), nor any prerequisite such as an in-progress session. The sequencing is only weakly implied by the word 'Complete'.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description adds nothing beyond the redundant POST verb. It does not disclose auth requirements, whether repeat submissions of the same factor are accepted, what the session state becomes, or any failure semantics.

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 short sentence with the action front-loaded and the endpoint appended as a low-cost routing aid. No filler, though it is arguably under-specified rather than genuinely concise.

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?

A mutation tool with a free-form body, no output schema, and no explanation of what a 'factor' is (TOTP, push, signature?), what valid factor values exist, or what the response returns. Annotations carry the safety profile, but the description leaves the agent guessing about the request contract.

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 reported at 100%, so the baseline is 3; the description adds nothing about the id path segment or factor payload. This is arguably worse than baseline because the body parameter is documented only as 'See the AffixIO OpenAPI schema resource for the contract', but the schema itself carries the formal contract.

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 and resource ('Submit a factor to a multifactor gate session') and even pins the endpoint POST /v1/gate/multifactor/:id/factor. It is distinguishable from affix_gate_multifactor_start/get/complete, though it never explicitly says how it differs from 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?

Placement in the multifactor flow is only implied by 'a multifactor gate session' – an agent can infer this is a mid-flow submission, but there is no statement of prerequisites (must a session be started first?) or of when to prefer complete/get instead.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered elsewhere. The description adds only the notion of 'current state', implying a live status read, but says nothing about session expiry, error behavior for unknown ids, or response shape.

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 zero filler; the resource and scoping constraint come first.

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?

Adequate for a simple read tool whose annotations cover safety, but with no output schema the description does not indicate what 'state' contains (pending factors, completion status), leaving the agent unable to anticipate the return value.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description confirms the required id is a session identifier, but the optional 'query' object is described only generically in the schema and gets no clarification here.

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 (fetch), resource (multifactor gate session) and scope (current state, by id). The read-only 'get' nature contrasts implicitly with siblings affix_gate_multifactor_start/factor/complete, but the description never names or rules out those alternatives explicitly.

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 when-to-use guidance, no prerequisites, and no mention of the related start/factor/complete tools in the same flow. The agent must infer that this is the polling/status step of a multifactor gate session.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. Beyond that the description adds only the REST path; it says nothing about session lifetime, whether calling it twice creates duplicate sessions, auth requirements, or what state the session begins in.

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 action front-loaded and the endpoint appended as a scannable identifier. Nothing is wasted, though the endpoint fragment is of marginal value to an agent that will not call the REST API directly.

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?

This is a state-creating mutation tool with no output schema and no annotations explaining the session model, yet the description gives no hint of the workflow (start -> submit factors -> complete) or what the caller receives back. An agent cannot tell what to do with the result or what is required next.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, but the single 'body' parameter is documented only as 'JSON request body. See the AffixIO OpenAPI schema resource for the contract,' which is a pointer rather than semantics. With full nominal coverage the baseline of 3 applies, and the description adds nothing further about the body.

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+resource ('Start a multifactor gate session') and even names the underlying endpoint, which the sibling 'start' tools (quorum_start) mirror. The verb 'start' cleanly distinguishes it from the companion gate_multifactor_complete/factor/get siblings, though the description does not explicitly articulate that distinction.

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 when-to-use guidance, no prerequisites, and no mention of the sibling tools (factor, complete) that form the multifactor workflow. The agent must infer that this opens a session that later needs factors submitted via other 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the HTTP endpoint and repeats 'pending', but does not explain what approval does, whether it needs specific authority, or what happens if the quorum is incomplete.

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 zero filler; the action and target lead the sentence and the endpoint is parenthetical. Efficient, though it is arguably too terse for a mutation endpoint.

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 mutation tool with annotations covering safety and no output schema, the description is minimally adequate: it identifies the action, state, and endpoint. It leaves the request body contract entirely to an external resource, which an agent cannot inspect from this definition alone.

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 listed at 100%, so the baseline is 3. However, the schema text itself is thin ('Path segment `id`.' and a body that just defers to the OpenAPI resource), and the description adds nothing about parameter format or body content. No value added 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?

States a specific verb ('Approve') and resource ('quorum gate session'), plus a state qualifier ('pending') and the exact endpoint. An agent can tell it apart from affix_gate_quorum_start and affix_gate_quorum_get, though it doesn't name those siblings explicitly.

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 says nothing about when to call this versus alternatives, no prerequisites (does a quorum session have to be started first?), and no exclusions. The word 'pending' is the only implicit cue.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds only that it returns the session's 'current state', which usefully implies a non-mutating snapshot but says nothing about error behavior for unknown/expired session ids or any auth requirements.

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 well-formed sentence with the verb and identifying key front-loaded and zero filler. It is efficient, though its brevity borders on under-specification rather than trimming redundancy.

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 read tool whose annotations cover the safety profile, the definition is functional but thin: with no output schema, the description could have sketched what 'current state' contains (quorum progress, approvals, expiry). The undefined query parameter and unknown-id failure mode are also left unaddressed.

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 nominally 100%, so the baseline is 3, and 'by id' merely restates the required id parameter. The opaque free-form 'query' bag is documented only as 'Optional query parameters', and the description does nothing to clarify what keys it accepts, so no value is added over 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?

States a specific verb ('Fetch'), resource ('quorum approval gate session') and keying ('by id'), so the agent knows exactly what the tool does. It does not, however, differentiate itself from the closely named siblings affix_gate_quorum_approve and affix_gate_quorum_start beyond the implicit read-vs-write split.

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 call this versus affix_gate_quorum_start (to create a session), affix_gate_quorum_approve (to advance one) or affix_gate_multifactor_get (a different gate family). No prerequisites, no post-approval polling hint, no 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false, so the mutation profile is covered. The description adds only the HTTP verb/path and nothing about session lifetime, required auth, or what state is created. With annotations doing the safety lifting, this is minimal added value but not contradictory.

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 short sentence, front-loaded with the action and resource, with the endpoint appended as supporting detail. Nothing is wasted.

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?

This is a stateful session-start operation with no output schema to explain the returned session identifier, and the description says nothing about the response or the follow-up lifecycle. For a tool that anchors a multi-step quorum approval flow, the definition leaves the agent unable to proceed confidently beyond the call itself.

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 a single 'body' parameter and schema description coverage is reported at 100%, so the mechanical baseline is 3 even with no parameter detail in the description. In practice the schema's only text points to an external OpenAPI resource, so neither description nor schema tells the agent how to build the request body.

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 (Start) and resource (quorum approval gate session) and even names the endpoint. It is clearly not a tautology. However it offers no differentiation from siblings like affix_gate_quorum_approve, affix_gate_quorum_get, or the multifactor gate family, so an agent cannot tell from the text alone which gate variant applies.

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 when-to-use guidance, no mention of prerequisites (e.g. what must exist before starting a session), and no reference to the companion tools affix_gate_quorum_approve / affix_gate_quorum_get that presumably consume the session this call creates. Usage is left entirely to inference.

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?

Annotations already disclose that this is non-read-only, non-idempotent, and non-destructive. The description adds only the HTTP method and path, which is marginal. It does not explain what the verification mutates or records, what permissions are required, or what happens on failure.

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 zero filler. Every word contributes to identifying the operation.

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 the description does not describe the response, required body contents, or request context. For a POST verification tool with many siblings, this leaves meaningful gaps for correct 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?

The single body parameter is 100% described in the schema, but the description only says to consult the OpenAPI schema resource, adding no semantic detail about the body. With a single documented parameter, 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 gives a specific verb ('Run') and resource ('permission-circuit gate verification') plus the HTTP endpoint, which is more informative than a tautology. It does not, however, differentiate this tool from close siblings like affix_circuit_verify or affix_verify, leaving an agent to infer the distinction.

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 when-to-use, when-not-to-use, or alternative-tool guidance is provided. An agent is left to guess whether this is the right verification call among the many affix_* verify 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds that it returns uptime state and version, but says nothing about timeouts, retries, or what a failure looks like.

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 sentence, front-loaded with the check action, no 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 no-required-param health probe with rich annotations and no output schema, the description is minimally adequate but does not explain the shape or meaning of a healthy/unhealthy result, which is the main thing an agent needs.

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 single 'query' bag is documented in-schema; the description adds no parameter detail. Baseline 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?

States a specific verb+resource ('Check that the AffixIO verification API is up') plus an additional return detail (version). Clearly distinguishable from verification siblings like affix_verify.

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 name and description imply a health-check liveness probe, but there is no explicit guidance on when to call it versus alternatives (e.g., affix_api_read, affix_trial_quota) or when not to use it.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond what annotations provide—no authentication needs, rate limits, pagination, or response format 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 a single sentence, front-loaded with the action and resource, and wastes no words. It is appropriately sized for a simple list operation.

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 read-only list tool with no output schema, the description gives the full set of expected return values (the carriers), which is helpful. It does not describe response structure or query filtering behavior, but the core content is complete enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the optional 'query' parameter is already documented in the schema. The description adds no parameter syntax, filtering options, or format details beyond the schema baseline.

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 ('List') and resource ('supported proof carriers'), and enumerates the exact carrier values. This distinguishes it from siblings such as affix_list_circuits by resource. An agent can tell what it does without opening the schema.

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 discovering supported carriers, but does not explicitly say when to use it versus alternatives or mention any prerequisites. Usage is clear from context but not spelled out.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description only adds that ids and metadata are returned; it says nothing about auth, pagination, or filtering 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?

A single front-loaded sentence that conveys the resource and the return shape with zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only listing tool whose annotations carry the safety profile and which has no output schema, the description states what comes back (ids and metadata) and is sufficient for correct invocation, with only minor gaps around filtering.

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?

One optional 'query' object with 100% schema description coverage, so the schema already documents it. The description adds no meaning about what keys the query accepts or how they filter results; baseline 3 applies.

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 (List) and resource (AffixIO zero-knowledge circuits) and even previews the payload ('ids and metadata'). It is clearly distinguishable from action-oriented siblings like affix_circuit_prove/affix_circuit_verify, though it does not explicitly 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?

There is no when-to-use guidance and no exclusions. A reader can infer this is a discovery call preceding prove/verify, but the description never states that or points to any sibling.

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?

Annotations carry the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the agent knows this mutates state and is not idempotent. The description adds nothing beyond the endpoint path: it does not say what the audit records, whether re-running has side effects, or what auth is required. Note the mild tension between the read-sounding verb 'audit' and readOnlyHint=false, but this is not a direct contradiction.

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; the purpose leads. The trailing endpoint path is slightly redundant but serves as a useful anchor.

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 state-mutating operation with no output schema and a request body whose contract is deferred to an external resource, the description does not tell the agent what a receipt looks like, what the audit produces, or what side effects to expect. It is too thin given this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single 'body' parameter is documented in the schema, but only by deferring to 'the AffixIO OpenAPI schema resource for the contract.' The description adds no field-level or format meaning, so the high-coverage baseline of 3 applies.

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+resource: auditing a single verification receipt against the Merkle audit tree, and the '(POST /v1/merkle/audit)' anchor pins the operation. The word 'single' lightly separates it from the sibling affix_merkle_audit_batch, though the differentiation is implicit 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?

There is no explicit when-to-use guidance, but 'single' implies the batch sibling (affix_merkle_audit_batch) is the alternative for multiple receipts. The condition that selects this tool is only implied, not 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, and the description adds nothing beyond the endpoint path. Because it is flagged as non-read-only but described as an 'audit' (which sounds like a read), the agent gets no explanation of what state this mutates, whether it consumes/records receipts, or what permissions 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?

It is a single, front-loaded sentence with no wasted words. Brevity is efficient, though the terse one-liner leaves semantic gaps that a slightly longer treatment could close.

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 batch, non-read-only operation with no output schema and a body whose contract is externalized to an OpenAPI resource, the description is too thin. It does not describe the request shape, the response, or the effect on the Merkle audit tree.

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 single body parameter is documented in the schema (deferring to the AffixIO OpenAPI schema resource), so the baseline is 3. The description adds only the URL path and no details on the body contract beyond what the schema already points to.

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 ('Audit') plus resource ('multiple verification receipts against the Merkle audit tree') and even the underlying endpoint, which cleanly separates it from the singular affix_merkle_audit sibling. It is clear but does not explicitly name the sibling or explain the difference beyond the word 'batch'.

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 batch auditing versus affix_merkle_audit, affix_merkle_verify_proof, or affix_verify_receipts, and no stated prerequisites. The agent must infer usage purely from the name and the word 'batch'.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only that pagination is supported; it says nothing about auth requirements, rate limits, or the leaf count/shape. With annotations carrying the burden, a 3 is warranted.

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?

Two short sentences, front-loaded with the operation and followed by the pagination note. No filler, though the second sentence is thin enough that it borders on restating the schema.

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 read-only list tool with an output schema absent, the definition is minimally viable but leaves the free-form query object unexplained (no pagination key names) and gives no hint about what a Merkle leaf record contains. Given the sibling merkle tools, more routing context 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 coverage is reported at 100%, so the baseline is 3. The description's note that pagination parameters are supported hints at the query object's purpose, but the query schema is a free-form additionalProperties bag with no named pagination keys, and the description does not supply any of them (offset, limit, cursor).

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 and resource (list leaves of the Merkle audit tree), which cleanly separates it from affix_merkle_root (root) and affix_merkle_proof (proof generation). It stops short of naming those siblings, but the noun 'leaves' is specific enough for an agent to route correctly.

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 no when-to-use guidance and never references the numerous sibling merkle tools (affix_merkle_audit, affix_merkle_audit_batch, affix_merkle_proof, affix_merkle_root). An agent gets no signal for choosing this over affix_merkle_audit.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false). The description adds no further behavioral context such as return format, pagination, authentication needs, or rate limits, so it does not enrich what structured data already provides.

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 wasted words. It is appropriately sized for a simple retrieval 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?

For a simple two-parameter read tool with full schema coverage and rich annotations, the description covers the basic purpose. However, it omits any indication of how the proof is used or how it relates to sibling tools like affix_merkle_verify_proof, and it does not clarify the generic optional query parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds only that the digest is a 'receipt digest', which marginally clarifies the required parameter beyond the schema's generic 'Path segment `digest`' label, but it does not explain the optional query 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 states a specific verb (Get) and resource (Merkle inclusion proof) and scopes it to a receipt digest. It does not differentiate from sibling tools like affix_merkle_verify_proof or affix_merkle_root, so an agent cannot easily tell them apart.

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 when-to-use guidance, no mention of alternatives, and no prerequisites are given. The description merely restates the tool's function without helping the agent choose between this and sibling Merkle 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the value is account-scoped and 'current' (implying it changes as receipts accrue), but says nothing about whether it is a snapshot, how it is consumed, or any caching/rate considerations.

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 front-loaded sentence with no filler, which is the right shape for a simple read. It is arguably too terse for a tool sitting in a crowded Merkle family, but nothing in it is wasted.

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?

Annotations cover the safety profile and the lack of an output schema is partly mitigated by 'root' being self-describing. Still, no guidance on how this relates to the other Merkle endpoints leaves an agent guessing in exactly the situation where disambiguation matters most.

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 nominally 100%, but the single 'query' parameter is an opaque pass-through object with no named properties, and the description never references it. Baseline 3 applies since the schema technically documents the parameter, though neither source explains what query keys are meaningful.

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 and resource (get the Merkle audit-tree root) and scopes it to the account's proof receipts, so the agent knows exactly what is returned. However, with five Merkle siblings (affix_merkle_audit, affix_merkle_audit_batch, affix_merkle_leaves, affix_merkle_proof, affix_merkle_verify_proof) it makes no attempt to distinguish itself from them, leaving ambiguity about which Merkle endpoint to pick.

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 when-to-use guidance, no prerequisite, and no mention of alternatives, despite a dense cluster of similar Merkle tools. The agent must infer that this is the lightweight root-only call versus the full audit endpoints.

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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the POST endpoint noted in the description is consistent with readOnlyHint=false, so there is no contradiction. However, the description adds no behavioral context beyond that structural hint: it says nothing about authentication, whether the proof is consumed/witness state changes, or what a verification failure looks like.

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 front-loaded sentence with the endpoint in parentheses; nothing is wasted or buried. The terseness is a completeness problem, not a conciseness one.

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 cryptographic verification tool with an unspecified request body and no output schema, the description is too thin: it never explains what the body must contain or what the verification result conveys. The agent cannot construct a correct call from this definition alone.

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 a single 'body' parameter whose only schema text points at an external OpenAPI resource, so the actual field contract is opaque. With nominally 100% schema description coverage the baseline is 3, and the description contributes nothing about the required proof/root fields the caller must supply.

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: 'Verify a Merkle inclusion proof against the audit root', which is far more precise than the bare title. It implicitly distinguishes itself from siblings like affix_merkle_proof (generate) and affix_merkle_root (fetch root), though it never names those alternatives explicitly.

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 when-to-use guidance is offered beyond the endpoint path. There are several verification-flavored siblings (affix_merkle_proof, affix_proof_ref_verify, affix_circuit_verify, affix_aggregate_verify) and the description gives the agent no basis for choosing among them.

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?

Annotations already declare readOnlyHint=false, openWorldHint=false, destructiveHint=false, idempotentHint=false, so the safety profile is partly covered. However, the description adds nothing about behavior — no mention of what parsing yields, whether checksum/digit validation occurs, or error handling for malformed MRZ. There is also a mild tension: 'parse' reads as a pure read operation while readOnlyHint=false and idempotentHint=false imply non-read, non-repeatable processing, which the description never explains.

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 front-loaded sentence that names the operation, the input domain, and the endpoint with no filler. It is efficient, though so terse that it borders on under-specification rather than optimal 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?

There is no output schema, so the description should carry the burden of explaining what a successful parse returns (parsed fields, normalized values, validation results), and it does not. For a POST-based tool with no output contract and a schema that defers to an external resource, the definition is not complete enough for confident 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 reported at 100%, so the baseline is 3. The single body parameter is described only as 'JSON request body. See the AffixIO OpenAPI schema resource for the contract,' which is a pointer rather than real documentation; the description adds no field-level detail such as which MRZ formats or line lengths are accepted.

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 (parse) and resource (machine-readable zone / passport / ID card MRZ string), plus the underlying endpoint. It is clearer than most siblings, though it does not explicitly distinguish itself from the similarly named affix_aamva_parse (driver's-license barcode parsing).

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 affix_aamva_parse or other verification tools, no prerequisites (e.g., input must be a raw MRZ string of correct line length), and no exclusions. The agent is left to infer usage entirely from the name.

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?

Annotations already declare the safety profile (readOnlyHint=false, destructiveness=false, idempotency=false), and the description adds nothing behavioral beyond an HTTP path. It does not say what a successful or failed verification returns, what auth is needed, or whether verification has side effects despite readOnlyHint being false.

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 sentence, front-loaded with the action and resource, with the endpoint as a compact parenthetical. Nothing is padded, though the endpoint string is only marginally useful to the agent.

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 at least characterize the verification result, yet it says nothing about return values, failure modes, or required inputs. The body contract is pushed to an external resource, leaving the agent under-informed for a verify 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?

There is a single optional 'body' parameter whose schema description defers the entire contract to an external OpenAPI resource. With 100% schema description coverage the baseline is 3, and the description adds no field-level meaning beyond the generic reference-based framing.

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 gives a specific verb ('Verify') plus resource ('a proof by its reference'), and the phrase 'instead of its full payload' implicitly separates it from the payload-based verify siblings like affix_verify or affix_aggregate_verify. It never names those siblings explicitly, so an agent must infer the routing rule rather than read it.

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: it tells you the precondition (you hold a reference, not a payload) but gives no explicit when-to-use, when-not-to-use, or named alternative. The contrast clause is the closest thing to guidance present.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the danger profile is covered structurally. The description only restates the action and adds the HTTP route, with no new behavioral detail such as irreversibility, auth requirements, or what 'spent' means downstream.

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 tight sentence with the action front-loaded; nothing is padded. The endpoint suffix is arguably redundant with the tool name but harmless.

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 destructive one-parameter mutation with annotations covering the safety profile, the definition is minimally adequate. It omits the digest body's expected form and what revoking a spent proof affects, leaving real gaps the agent must fill from external docs.

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?

Only one parameter (body) exists and schema coverage is 100%, so the baseline is 3. The description adds nothing about the digest format or the request contract, deferring entirely to the OpenAPI schema resource.

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 ('Revoke / mark spent') and resource ('a proof digest'), clearly distinguishing it from affix_spent_status. It does not name siblings explicitly, but the action 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?

No guidance on when to use this versus affix_spent_status or other verification tools, and no prerequisites or exclusions. The agent must infer context entirely from the name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds the useful concept of single-use enforcement, but does not describe the result semantics (spent vs. unspent) or any failure/auth behavior, so it adds only modest value beyond the 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?

A single, front-loaded sentence with no filler; the purpose and the key semantic qualifier are stated immediately.

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 for a status-check tool the description never indicates what the check returns (e.g., spent/unspent flag) or what a negative result implies. The safety profile is covered by annotations, but the return-value gap leaves it only minimally 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 100%, so the schema documents both parameters, and the baseline is 3. The description adds nothing about the 'digest' format or the generic 'query' object, so it does not go 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?

States a specific verb ('Check') and resource ('whether a proof digest has already been spent'), and the parenthetical '(single-use enforcement)' clarifies the semantic meaning of 'spent'. It does not explicitly differentiate itself from the close sibling affix_spent_revoke, so it falls 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?

The phrase '(single-use enforcement)' hints at the use case (verifying a digest has not been consumed before accepting it), but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is 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?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, which tells the agent this is a non-idempotent write. The description adds only the HTTP path and nothing about what a 'token carrier' is, whether issuing requires authentication, token lifetime, or what a repeated call does. Given annotations carry the safety profile, the description contributes almost no additional 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?

A single short sentence with the purpose front-loaded and the endpoint parenthetically appended; nothing is redundant. It is efficient, though the brevity is partly under-specification rather than disciplined editing.

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 mutating tool with no output schema, the definition omits what the returned token is used for, required body fields, auth expectations, and how the result feeds affix_token_verify. An agent could call it, but only by guessing at the request contract.

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 a single optional 'body' parameter with 100% schema description coverage, so the baseline is 3. The description adds no parameter meaning at all, and the schema's own body description merely points to an external OpenAPI resource rather than documenting the contract inline.

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 (issue) and resource (verification token carrier) and even names the underlying endpoint (POST /v1/token/issue), so the operation is identifiable. It does not explicitly contrast itself with the sibling affix_token_verify, though the issue/verify pairing is strongly implied by the names.

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 issue a token versus calling affix_token_verify, no prerequisites (auth, prior enrolment, caller identity), and no stated conditions or exclusions. The agent must infer usage entirely from the tool name.

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?

Annotations do the disclosure work here (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description only confirms this is a POST. It says nothing about auth requirements, whether verification consumes the token, what failure looks like, or whether the call is idempotent beyond the annotation flag.

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; the endpoint in parentheses is compact and mildly useful. It is efficient, though the extreme terseness edges toward under-specification rather than elegant brevity.

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 token-verification mutation with no output schema and an externally-deferred body contract, the description leaves the agent unable to construct a valid request or predict the result. It is far too thin for the tool's role in the verify/issue pair.

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?

One parameter with nominally 100% description coverage, but the schema text is only a pointer ('See the AffixIO OpenAPI schema resource'), so the actual token body contract is defined nowhere the agent can see. Per the high-coverage baseline this anchors at 3, though the deferral adds no real semantic value.

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 (verify) and resource (verification token carrier) plus the exact endpoint, so the agent knows this validates a token rather than issuing one. It does not, however, distinguish itself from near-siblings like affix_verify, affix_aggregate_verify, or affix_agent_trust_verify.

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 when-to-use statement, no prerequisite/ordering hint relative to affix_token_issue, and no exclusions pointing to the other verify-family tools. The agent must infer everything from the name alone.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the notion of a 'remaining' quantity; it says nothing about auth requirements, how the trial is resolved, or behavior when quota is exhausted. Minimum viable given the annotation coverage.

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 front-loaded sentence with no filler; the verb and resource come first. It is efficient, though the brevity borders on under-specification rather than true economy.

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 read tool with no output schema and an opaque pass-through parameter, the description should explain what 'remaining quota' looks like and how to target a specific trial. Neither is present, leaving the agent unable to determine inputs or expected results.

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?

Although the coverage metric reads 100%, the sole parameter is a free-form 'query' object whose only documentation is the tautology 'Optional query parameters.' The description provides no information about which query keys are meaningful or how to identify the trial, so an agent cannot construct a correct call from either source.

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 and resource: checking remaining trial quota. It is clearly distinguishable from every sibling (none of the affix_* tools deal with trials or quotas), though it doesn't explicitly contrast itself with an alternative. The scope is narrower than a generic 'get status' tool, which helps.

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 on when to call this versus other affix_* verification/status tools, and no prerequisites stated. 'For a registered trial' implies the trial must already exist, but the description doesn't say how that registration is established or what happens if the trial is unknown or expired.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation profile is covered without description help. The description adds useful context by describing the return as a signed binary result with a proof receipt, but it omits side effects (e.g. whether a receipt record is persisted for affix_verify_receipts), auth requirements, and quota/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?

Two sentences, front-loaded with the action and followed by the endpoint and pointer to policy values. No filler, though the endpoint/policy note is dense and could be separated for scanning.

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 does explain the result shape (signed binary result plus proof receipt), which is the main missing piece. But the request body contract is entirely offloaded to an external resource, and no prerequisites or policy-value semantics are described, leaving the agent under-informed for a non-idempotent POST.

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 a single 'body' parameter at 100% schema description coverage, so the schema already documents it. The description adds only an indirect hint that policy values go in the body ('see /v1/verify/policies'), with the actual contract deferred to an external OpenAPI resource; this is baseline-level value.

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 gives a specific verb and resource: run an eligibility verification against the AffixIO API and return a signed binary result plus a proof receipt. It also names the concrete endpoint (POST /v1/verify), which grounds the purpose. It stops short of differentiating this from the many other verify tools (affix_verify_receipts, affix_aggregate_verify, affix_token_verify), so it is clear but not fully disambiguating.

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 the example ('e.g. over-18') and by the pointer to /v1/verify/policies for policy values, which tells the agent where to source inputs. However there is no explicit statement of when to use this tool versus the sibling verify/receipt/aggregate tools, nor any exclusion 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description's only added behavioral context is that the listed policies are the ones accepted by POST /v1/verify; it says nothing about return shape, whether the list is static or environment-dependent, or how query filtering behaves.

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 sentence with no filler, and the resource is front-loaded immediately after the verb. Nothing needs trimming or reordering.

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 carries the burden of hinting at return values, and it does not say whether the response is a flat list of policy identifiers or richer objects. For a no-argument read-only catalog call this is adequate but leaves an unnecessary gap an agent cannot fill elsewhere.

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 nominally 100% and the tool has a single optional parameter, so the baseline is 3. The description adds nothing about the free-form 'query' bag (unspecified property names, anyOf string/number/boolean), leaving the agent no guidance on what query keys are meaningful.

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 and resource ('List the supported verification policies') and adds scope by tying the result to the POST /v1/verify endpoint, which separates it from unrelated list tools. It does not explicitly distinguish itself from near-neighbors such as affix_verify_reason_codes, so it falls 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?

The phrase 'usable in POST /v1/verify' implies the correct moment to call this (discovering accepted policy values before invoking affix_verify), but no when-not condition or named alternative is given. Usage must be inferred from the endpoint reference.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one useful behavioral detail beyond the annotations ('with explanations'), indicating the response includes explanatory text rather than bare codes. It adds nothing about response shape, filtering, or ordering, so it clears the lowered bar but only modestly.

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 sentence that front-loads the resource and appends the one differentiating detail. There is no filler, hedging, or redundancy.

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 is responsible for hinting at the return value, and 'reason codes ... with explanations' does that at a high level. For a simple enumeration tool with a single optional passthrough parameter and full annotation coverage, that is nearly complete; only the absence of any note on grouping/pagination keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single generic 'query' passthrough object is technically documented. However, the description adds no meaning about what query options are meaningful for this endpoint, and the schema itself is a shapeless anyOf of string/number/boolean. High coverage with zero added semantic value yields the baseline 3.

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 names a specific verb (List) and resource (reason codes the /v1/verify endpoint can return), so an agent can immediately tell this is a reference-lookup tool. It separates itself from affix_verify, affix_verify_receipts, and affix_verify_policies by targeting error/reason codes rather than verification itself, though it never explicitly contrasts with 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 only implied: the agent can infer this is the tool to consult when interpreting a result from /v1/verify, but the description never says when to call it or what alternative to use instead. There are no exclusions or prerequisite conditions 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds that results are scoped to the account and that pagination is supported, which is modest but real extra context. It omits pagination mechanics, result limits, and what "recent" actually means.

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?

Two short sentences, front-loaded with the core purpose. No filler. The second sentence is somewhat vague ("pagination query parameters") but still earns its place by hinting at accepted input.

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 a catch-all query object, the description carries the burden of explaining what inputs are usable and what comes back. It mentions pagination but not the parameter names, result shape, or default limits, leaving meaningful gaps for an agent trying to page through receipts.

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 nominally 100%, but the schema only defines an open-ended query object with anyOf string/number/boolean, which names no concrete parameters. The description compensates slightly by saying the query supports pagination, but it never names the pagination keys or their formats, so an agent still has to guess. Baseline 3 for high coverage with minimal added value.

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: "List recent verification receipts issued to the account." An agent knows exactly what it returns without opening the schema. It does not, however, differentiate itself from verification-adjacent siblings like affix_verify or affix_aggregate_verify, so it falls 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 call this versus alternatives such as affix_verify or affix_verify_reason_codes, nor any stated prerequisites. Usage is only implied by the word "List."

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?

Annotations already state readOnlyHint=false and idempotentHint=false, so the write-ish, non-idempotent nature is covered structurally. The description adds only the HTTP endpoint, disclosing nothing about what the prepared witness is, whether it is persisted or returned, its lifetime, or any auth requirements — thin even against the lowered annotated bar.

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 that names the action, the artifact, and the endpoint with no filler. It is well-structured, though brevity here shades into under-specification rather than tightness.

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 non-idempotent POST into a complex cryptographic workflow, with no output schema and an opaque request body, the description leaves too much open: no input contract, no indication of the return artifact, and no pipeline context relative to the many affix_circuit_* and affix_proof_* siblings.

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 parameter ('body') whose schema description merely delegates to an external 'AffixIO OpenAPI schema resource' rather than documenting the contract. The nominal 100% coverage is therefore uninformative, and the prose adds nothing about the expected body shape for a POST endpoint.

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 and resource ('Prepare a witness') tied to a concrete domain object ('zero-knowledge circuit proof'), which an agent can distinguish from a bare 'witness' tool. It does not, however, differentiate itself from nearby siblings such as affix_circuit_prove or affix_circuit_verify, so the agent must infer where witness preparation sits in the proof pipeline.

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 when-to-use guidance, no statement of prerequisites (circuit id, inputs), and no mention of the sibling tools that consume or produce the witness. The description only says what the call is, not when to reach for it over affix_circuit_prove.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds no further behavioral context — it says nothing about what 'proof decisions' are returned, the result shape, pagination, or caching, so it contributes almost nothing beyond the title.

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 zero waste, which is appropriate for a lightweight catalogue tool. It is arguably terse to the point of under-specification, but nothing is padded or buried.

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 tool with no output schema, a free-form query object, and a large sibling set of related *_catalogue/*_check pairs, one sentence is not enough. An agent still cannot tell what a 'proof decision' entry contains or what query keys are accepted before calling 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?

The single 'query' parameter is an unconstrained map of arbitrary string/number/boolean keys, and neither the schema nor the description names any valid filter keys or their meaning. High nominal schema coverage is misleading here because the schema defines no real semantics, and the description does not compensate by listing filterable fields.

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 ('List') and resource ('Age Pass checks and supported proof decisions'), so the agent knows this is a discovery/catalogue endpoint. It does not, however, distinguish itself from the sibling age_check, which presumably runs a check rather than listing them — the differentiation is left to the agent's inference.

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 word 'List' plus the catalogue naming pattern implies this is the discovery step before invoking age_check, but the description never says when to use it versus age_check or what comes next. No explicit exclusions or prerequisites are given.

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?

Annotations already declare the safety profile (non-readOnly, non-idempotent, non-destructive, closed-world). The description adds one behavioral trait beyond them — data minimization — but does not explain why a 'check' is non-readOnly/non-idempotent, whether state is recorded, or what errors/auth are needed.

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; the privacy constraint is stated up front. It is efficient, though bordering on under-specification rather than tightness.

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 tool whose only input is an opaque body and which has no output schema, the description explains neither the request contents nor what a result means (pass/fail, thresholds, response shape). An agent cannot confidently invoke it from this text alone.

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?

With a single 'body' parameter and 100% schema description coverage, the baseline is 3. The description adds nothing about what the body should contain (subject age, policy id, gating context), and the schema itself only defers to an external OpenAPI resource.

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 and resource ('Check age-gated access'), which is clearer than the tautological title 'Run an Age Pass check'. However, it never distinguishes itself from the close siblings age_catalogue or shelf_check_age, so an agent must infer which age-related tool to pick.

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 prerequisites (auth, prior token issuance, catalogue lookup), and no exclusions. The privacy framing hints at a use case but does not tell the agent when this is the right call.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is covered. The description adds the notion that this is a catalogue/listing, but says nothing about ordering, pagination, filtering behavior, or what the returned checks/surfaces contain.

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 short sentence, so it is concise and front-loaded, but the terseness comes at the cost of decoding jargon rather than earning its place through clarity.

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?

No output schema, a nested free-form query parameter, and no explanation of what 'checks' or 'delegated checkout surfaces' are. With an open-ended catalogue of 60+ sibling tools, the description is not complete enough for an agent to know what it will get back 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?

Schema coverage is 100% and the single optional 'query' object is documented as 'Optional query parameters' with free-form string/number/boolean values. The description adds nothing about what query keys are meaningful (e.g., filtering by check type or surface), so the schema's permissive bag-of-values remains 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?

States 'List ... checks and delegated checkout surfaces', giving a verb and a resource, but 'Agentic Pay Kit checks' and 'delegated checkout surfaces' are internal jargon that an agent cannot map to concrete artifacts. Siblings like agentic_pay_charge and agentic_pay_reverify establish the domain, but the description doesn't differentiate this enumeration tool from them beyond 'List'.

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 when-to-use guidance, no exclusions, and no mention of alternatives such as agentic_pay_charge or agentic_pay_reverify. An agent must infer that this is the discovery step before calling the other two.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the agent knows this is a destructive, non-idempotent write. The description adds only the prerequisite of intent/permission checks; it does not elaborate on side effects, required auth, or what gets destroyed, which would be valuable given the destructive annotation.

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 a single, front-loaded sentence with no filler. It is appropriately sized but very sparse, which is efficient though not richly informative.

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 destructive, non-idempotent charge workflow with no output schema and minimal schema detail, the description is barely adequate. It mentions prerequisites but omits behavioral details like error handling, required permissions, or expected outcomes, leaving the agent under-informed for a high-stakes 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 description coverage is 100% for the single 'body' parameter, but the schema description itself is uninformative ('See the AffixIO OpenAPI schema resource'), so the description does not compensate for the lack of parameter detail. Baseline 3 applies because schema coverage is high, but the description adds no parameter 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 states a specific verb (run) and resource (Agentic Pay charge workflow), which is clear enough. It does not explicitly distinguish itself from siblings like agentic_pay_reverify or agentic_pay_catalogue, but the focus on running a charge flow is distinct.

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

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

The phrase 'after intent and permission checks are present' implies a prerequisite, but it doesn't say when to use this tool versus alternatives (e.g., agentic_pay_catalogue or agentic_pay_reverify) or what happens if prerequisites are missing. Usage context 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?

Annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false — meaning this is a state-changing, non-repeatable-safe, yet non-destructive operation. The word 'Reverify' suggests a passive check, which sits uneasily with a write-style annotation profile, and the description adds no auth requirements, no explanation of what state is mutated, and no failure semantics.

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 sentence, front-loaded with the verb and resource, and every word contributes. It is not padded, but it also stops before delivering the operational detail the caller needs.

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-path tool with no output schema, no readable body contract, and a write-leaning annotation profile, one sentence is far too thin. An agent cannot tell what to pass, what a success response means, or whether the call consumes a token/nonce given idempotentHint=false.

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 a single 'body' parameter whose schema description is only a pointer to an external OpenAPI resource ('See the AffixIO OpenAPI schema resource for the contract'), so the 100% coverage figure is nominal rather than informative. The tool description says nothing about what the request body must contain, despite 'reverify' implying at least an intent or delegation identifier.

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 gives a specific verb ('Reverify'), a specific resource ('delegated payment intent'), and a concrete moment ('before an AI agent completes a checkout action'). It is clearly distinct from agentic_pay_charge or agentic_pay_catalogue, though it never names those siblings to make the routing explicit.

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 the timing clause ('before ... completes a checkout action'), so an agent can infer when the call belongs. There is no statement of when NOT to use it, no prerequisites (e.g. prior charge/authorise step), and no named alternative among the many affix_*_verify 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, covering the full safety profile. The description adds essentially nothing behavioral on top of that: no pagination, no return shape, no indication of how the 'query' object is interpreted. It is consistent with the annotations but adds no new 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?

A single front-loaded fragment with zero filler. It is efficient, though the terseness borders on under-specification rather than pure 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 catalogue tool with no output schema, the description should at least convey what the listing contains and how the query object filters it. Neither is present, and with 0 required params the description is the only place an agent could learn what query keys are accepted. The gap is meaningful even for a low-complexity read 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 100%, so per the baseline the schema is presumed to carry parameter meaning, giving a floor of 3. In practice the single 'query' parameter is a free-form object with no defined properties, and the description offers no hints about supported keys, so the description does not compensate for the schema's permissiveness.

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 verb 'List' and the resource 'A-Level checks, tariff data' are identifiable, so an agent can tell this is a read/list surface. However, 'education proof surfaces' is opaque jargon and the description never distinguishes this catalogue from the sibling alevel_check_offer (the check action) or the many other *_catalogue tools. The purpose is only partially clear.

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 when-to-use guidance, no statement of prerequisites, and no mention of alternatives such as alevel_check_offer. The agent must infer from the name alone that this is a discovery/list tool rather than an evaluation tool.

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?

Annotations already declare readOnlyHint=false and idempotentHint=false, which is surprising for a tool named 'Check' and suggests it persists a result or audit record. The description never discloses that side effect, nor whether repeated checks create duplicate records, so it leaves a real behavioral question unanswered and mildly conflicts with the read-only framing implied by 'Check'.

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. It is efficient, though its brevity is as much under-specification as conciseness in places.

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 only a pointer-style body description, the agent gets no information about what a check returns (pass/fail, per-subject breakdown, reasons) or what inputs must be assembled first. For a validation tool in a large catalog this leaves the definition materially incomplete.

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 a single 'body' parameter whose schema description is nominally present (100% coverage) but only defers to an external OpenAPI resource. The description adds nothing about the shape of the body — how grades, subjects, or the offer are expressed — so it does not compensate for a contract that is documented elsewhere.

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 gives a concrete verb and resource: it checks whether an applicant's grades and subjects satisfy an offer. That clearly separates it from alevel_catalogue, but it doesn't distinguish itself from other '*_check' tools in the catalog or state the domain boundary explicitly.

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 when-to-use guidance at all — no prerequisite (e.g. needing an offer reference from alevel_catalogue first), no condition under which the check applies, and no named alternative. The agent must infer all of this from the tool name alone.

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?

Annotations already mark it as a non-read-only, non-idempotent, non-destructive, closed-world write. The phrase 'auditable ballot session' adds that votes are recorded for audit, but the description does not say what gets created, whether votes are revocable, or whether auth/session prerequisites 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?

One front-loaded sentence with no filler. It is appropriately sized for the definition, even if sparse.

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?

A non-idempotent write with no output schema and only a deferred body contract. The description omits session prerequisites, vote payload shape, and auth context, leaving invocation dependent on an external schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the only parameter's description points to an OpenAPI schema resource. The tool description adds no body field, format, or session-id detail, so the high-coverage baseline of 3 applies.

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 'Cast' and resource 'vote' with scope 'inside an auditable ballot session'. Distinguishes from generic ballot management, though it does not explicitly name ballot_session as the alternative.

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 when-to-use, when-not, prerequisites, or alternative guidance. 'Inside an auditable ballot session' implies prior session creation but does not state it or route the agent to ballot_session.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so safety is covered structurally. The description adds nothing beyond that: no indication of result shape, pagination, or what the listed 'checks and sources' contain, so it contributes no behavioral context of its own.

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 short, front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than disciplined compression.

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 an opaque free-form query parameter, the description is the only place usage and return content could be explained, and it explains neither. For a discovery/catalogue tool meant to feed downstream ballot_cast calls, this leaves the agent without enough to call it confidently.

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 nominal 100% coverage is misleading: the only property is a free-form 'query' object whose additionalProperties accept any string/number/boolean with no named keys. The description supplies no parameter meaning at all, so an agent has no idea which query filters are accepted or how to form them.

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?

It gives a verb ('List') and a resource ('Ballot Pass checks and sources'), which distinguishes it from the sibling action tools ballot_cast and ballot_session. However, 'checks and sources' is undefined jargon and the agent cannot tell what a Ballot Pass check or source actually is from this text.

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 when-to-use, when-not-to-use, or alternative is named. The catalogue-vs-check pattern (ballot_catalogue vs ballot_cast) is inferable from the sibling names alone, not from anything the description says.

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?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, closed-world mutation, so the safety profile is covered. The description adds nothing beyond that: it does not explain what a session represents, whether repeated calls create duplicate sessions (relevant given idempotentHint=false), what authorization is needed, or what the session produces.

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 short, front-loaded sentence with zero filler or repetition. Its brevity is efficient, though the same terseness is what leaves the tool under-explained elsewhere.

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 state-creating mutation with no output schema, the description should at least indicate what the resulting session is used for (presumably a prerequisite for ballot_cast) and what the caller must supply in the deferred body contract. None of that is present, so an agent cannot confidently sequence or invoke 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 reported at 100%, so the single body parameter is nominally documented, which sets the baseline at 3. The schema text itself only defers to an external OpenAPI contract ("See the AffixIO OpenAPI schema resource"), and the description adds no field-level meaning, so it sits at the baseline rather than above it.

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?

"Create an auditable ballot session" gives a specific verb (create) and resource (ballot session), so the basic action is identifiable. However, "auditable" is undefined and the description does nothing to separate this from the sibling ballot_cast or ballot_catalogue, leaving the agent to infer the distinction from names alone.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as ballot_cast or ballot_catalogue. The agent gets no indication of when a session is required versus when it can be skipped.

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?

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds the subject matter being listed, but does not disclose pagination, return structure, or other behavioral details beyond what annotations provide.

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 wasted words. It states the tool's action and object immediately, which is appropriately sized for a simple catalogue 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?

The tool is simple (one optional parameter, rich annotations, no output schema), and the description identifies what the catalogue contains. It sufficiently complements the structured fields, though it could clarify how the returned checks and sources relate to the clean_air_check and clean_air_data_sources siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single optional 'query' parameter is already documented in the schema. The description adds no parameter-level meaning, which is acceptable at the baseline when the schema does the heavy lifting.

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 ('List') and names the resources ('checks the clean air service performs and the sources behind them'). It clearly identifies a catalogue-style read operation, though it doesn't explicitly contrast itself with siblings like clean_air_check or clean_air_data_sources.

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: an agent can infer this is a discovery tool for clean air checks and sources. The description gives no explicit when-to-use guidance, no prerequisites, and does not name alternatives such as clean_air_check or clean_air_data_sources.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful behavioral nuance that this works in two modes — bare postcode (journey) or postcode plus vehicle data (exact vehicle decision) — but says nothing about result format or lookup failures for unrecognised postcodes.

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 covering scope, the required postcode anchor, and the optional refinements. Nothing is padded, though it spends its one sentence on inputs rather than on the routing information an agent most needs.

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 one-parameter nested-body read tool with full annotations and a fully described schema, the description covers inputs adequately. The remaining gap is sibling differentiation — the tool sits beside vehicle_check_clean_air and clean_air_zones with no stated boundary between them.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each field is documented with examples, so the schema carries the load. The description correctly names vrm, euro_status, and fuel_type as optional refinements that make the decision exact, which is a small but genuine addition over the schema's per-field text.

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 and resource — check clean-air-zone compliance for a vehicle or journey from a postcode — so the agent knows exactly what domain this covers. However, it does not distinguish itself from near-identical siblings such as vehicle_check_clean_air or clean_air_zones, leaving overlap unresolved.

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 says what the check is but never states when to choose it over siblings like vehicle_check_clean_air, clean_air_zones, or clean_air_catalogue. The only usage hint is that vrm/euro_status/fuel_type are optional for a more exact decision, which is parameter guidance rather than routing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and side-effect profile is fully covered elsewhere. The description adds only the scope of the resource and discloses nothing behavioral beyond that – no indication of what a 'source' record contains, how results are ordered, or whether pagination applies.

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 zero wasted words. It is appropriately sized for a simple list tool, though the brevity comes at the cost of the guidance noted in other dimensions.

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 is the only place a return shape could be hinted at, and it does not describe what a source entry looks like. For a trivial read-only list tool with complete annotations, this is minimally viable but leaves the query-parameter surface and result format unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single optional 'query' parameter, so the baseline of 3 applies. However, the parameter is an open-ended object with additionalProperties and no named keys, and the description does not enumerate any supported query fields, so an agent gets no help in constructing useful filters.

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 (List) and a specific resource (upstream sources used for clean air zone decisions), which is enough for an agent to distinguish it from clean_air_check, clean_air_zones, and clean_air_catalogue. It does not, however, explicitly distinguish itself from the parallel road_legal_data_sources or vehicle_data_sources siblings, relying on the name for domain scoping.

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 when-to-use guidance, no prerequisites, and no mention of the alternative sibling tools (clean_air_catalogue, clean_air_zones, clean_air_check) that an agent might confuse with this one. The description is purely descriptive, so usage must be inferred from the name alone.

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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that results include charges and rules, but says nothing about pagination, filtering behavior, or whether the free-form query is forwarded to the upstream service.

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 front-loaded sentence that communicates source, resource, and return content with zero filler. Nothing to trim.

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 tool returning charges and rules with no output schema and an arbitrary passthrough query object, the description should at least sketch what the zones record contains or what query keys exist. It leaves both the input contract and the return shape effectively unexplained.

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 reported as 100%, but the single parameter is an unconstrained free-form object accepting any string/number/boolean key, and the description does not name any supported query keys or formats. Baseline 3 applies since the schema nominally documents the parameter, but the description adds no real 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?

States a clear verb (List) and resource (UK clean air zones) plus the value-add content (charges and rules). It does not differentiate from close siblings such as clean_air_catalogue, clean_air_check, or vehicle_zones, so an agent cannot tell from the description alone which list-like tool to pick.

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 when-to-use guidance, no prerequisites, and no mention of alternatives despite several plausible competing list/check tools in the sibling set. The agent must infer usage from the name alone.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no return shape, no pagination, no size/rate behaviour for a listing endpoint.

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 short, front-loaded sentence with no filler. It is efficient, though the brevity here reflects under-specification rather than disciplined editing.

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?

No output schema exists, so the description must explain what the catalogue returns and how it pairs with clearance_check; it does neither. For a catalogue/list tool in a dense family of 70+ siblings, this is not enough for an agent to call it confidently.

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 reported at 100%, so per the baseline the schema carries the parameter documentation and a 3 is appropriate. However, the single query parameter is an unconstrained additionalProperties bag with no named keys, and the description does not hint at any accepted filter keys, so the practical guidance is thin.

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 names a resource (Clearance Pass) and a verb (List), so the general purpose is inferable, but "checks and guidance" is vague about what is actually catalogued and does not distinguish it from the sibling clearance_check or the parallel *_catalogue tools (drive_pass_catalogue, right_pass_catalogue). An agent cannot tell from this text whether it returns check definitions, guidance documents, or both.

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 when-to-use guidance at all. The most obvious question an agent faces — catalogue vs. clearance_check, and how the two compose — is left entirely unaddressed, as is whether any query keys are expected.

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?

Annotations declare readOnlyHint=false, openWorldHint=false, idempotentHint=false, destructiveHint=false, so the agent learns this is non-destructive but not read-only, yet the description says nothing about side effects, whether the check is recorded, permissions, or rate limits. A "Check" verb sitting on top of readOnlyHint=false is a tension the description should resolve but does not.

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 short sentence that is front-loaded and free of filler, which is good, but it is thin enough to read as under-specification rather than disciplined brevity for a tool in a crowded namespace.

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, an opaque pass-through body parameter, and dozens of adjacent *_check/*_catalogue siblings, the definition should carry the burden of explaining the request contract and result shape. It does not, leaving an agent unable to call this confidently versus alternatives.

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 nominally 100% (one body parameter), so the baseline is 3. However, the schema entry only says "See the AffixIO OpenAPI schema resource for the contract," so the description adds no real semantics about what the body must contain for this specific check.

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?

"Check clearance eligibility and guidance fit" gives a verb (check) and a resource (clearance), but "guidance fit" is undefined jargon and the phrasing does not separate this tool from siblings such as clearance_catalogue, drive_pass_check, or right_pass_check. An agent knows the general domain but not the specific 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?

There is no statement of when to use this versus the many other *_check tools, no prerequisites (e.g. an identifier or pass token required before calling), and no exclusions. The agent is left to infer routing entirely from the name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world, so safety is covered. The description adds nothing beyond that: it does not say what a catalogue entry contains, whether results are paginated or complete, or what 'proof surfaces' means. With no output schema, this is a real 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?

A single short sentence with the verb and resource front-loaded and zero filler. It is efficient, though its brevity shades into under-specification rather than tight concision.

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 listing tool with no output schema and a free-form query object, the description should at least explain what is returned and how to filter. Neither is covered, leaving the agent unable to predict results or construct a useful query.

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?

One optional parameter whose schema description is only the generic 'Optional query parameters', with additionalProperties allowing any string/number/boolean key. Nominal coverage is 100% but content-free, and the description offers no filter keys, formats, or examples, so an agent has no way to know what to pass.

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 ('List') and resource ('Drive Pass checks and proof surfaces'), but 'proof surfaces' is undefined jargon that an agent cannot resolve from the text. The sibling drive_pass_check implies a catalogue/check split, yet the description never names or contrasts with it, so differentiation is left to naming convention.

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 when-to-use statement, no condition, and no mention of the obvious alternative drive_pass_check (run a check) or right_pass_catalogue. The agent must infer from the name pattern that a catalogue lists rather than executes.

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?

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, which is a non-obvious profile for a tool whose description reads like a passive 'check'. The description never explains why a check is not read-only (e.g. does it log, consume quota, or issue a pass?) nor what a caller gets back. It adds almost nothing beyond the 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?

A single 11-word sentence, front-loaded with the verb and scope, with no filler. Brevity is a virtue here, though it is brevity at the cost of the missing guidance noted above.

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 tool with a stub request body, no output schema, and annotations indicating a non-idempotent, non-read-only operation, the description should say what inputs the body expects and what the check returns or mutates. None of that is present, leaving an agent unable to invoke it correctly without fetching external documentation.

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 single parameter is an opaque 'body' whose schema text only points at an external OpenAPI resource; no properties, no required fields, no enums. Although coverage is nominally 100%, the schema conveys no usable semantics and the description supplies none either, so an agent cannot know what to put in the body.

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 ('Check') and a concrete resource ('driving, route or zone eligibility with the Drive Pass service'), which is enough for an agent to know this tool evaluates eligibility. It does not, however, distinguish itself from adjacent siblings such as right_pass_check, road_legal_check, or clean_air_check, all of which are also '<domain>_check' eligibility 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?

There is no statement of when to use this tool versus drive_pass_catalogue (which presumably enumerates Drive Pass products) or versus the other *_check eligibility siblings. No prerequisites, no exclusions, no alternative named.

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?

Annotations declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is partly covered. The description adds nothing beyond that: it does not say whether state is mutated, what credentials are needed, or why a supposedly read-like 'audit' is flagged as not read-only. 'Proof-ready decision context' conveys no verifiable 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?

It is a single short sentence, so there is no bloat, but half of it is spent on the meaningless phrase 'proof-ready decision context'. Concise in form, under-specified in substance.

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 tool whose only input is an opaque JSON body deferred to an external schema, and with no output schema to describe the return value, the description should explain what is audited and what comes back. It leaves the agent unable to predict either the input contract or the 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?

There is only one optional parameter and the schema provides a description for it (100% coverage), so the baseline of 3 applies. However, that schema description merely defers to an external 'AffixIO OpenAPI schema resource' rather than defining the body contract, and the tool description does not compensate for that deferral.

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 is essentially a restatement of the title ('Audit an edge payload'), padded with the undefined jargon 'proof-ready decision context'. Neither 'edge payload' nor what the audit actually examines is explained, and it does nothing to separate this tool from edge_catalogue, edge_reject_pii, affix_merkle_audit, or affix_agent_trust_audit.

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 when-to-use guidance, no prerequisites, and no mention of any alternative. With four audit-flavored siblings and two other edge_* tools in the list, an agent has no basis for choosing this one over them.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only one piece of non-structured information: that the response contains the check schema, which is useful but 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?

A single short sentence, front-loaded with the verb, with no filler. It is efficient, though bordering on under-specified rather than genuinely concise.

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 must convey something about the return payload, and it does say the result includes checks and schema. However, it does not explain the shape of a check entry, how to feed a selected check into edge_audit, or what the loose 'query' filter accepts, which leaves real gaps for a catalogue/discovery 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 schema has 100% description coverage and only a single optional 'query' object, so the schema carries the burden. The description says nothing about the query parameter, its accepted filter keys, or valid values, so it adds no meaning 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?

States a specific verb (List) and resource (Edge Audit checks and schema), which matches the *_catalogue convention used by siblings like age_catalogue and ballot_catalogue. It does not explicitly distinguish itself from the paired action tool edge_audit, leaving the agent to infer that this one enumerates rather than evaluates.

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 statement of when to call this versus edge_audit, nor any prerequisite or ordering guidance. The agent must guess that the catalogue should be consulted before running a check.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false. The description adds the meaningful behavioral trait that the tool blocks unsafe material rather than passing it through, but says nothing about failure/rejection semantics, what happens on success, or whether the payload is forwarded automatically.

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 well-formed sentence with no filler and the action front-loaded. It is efficient, though borderline terse for a tool whose failure behavior matters.

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-param, mutation-flagged tool with no output schema, the definition is minimally adequate. It omits what a caller needs to know about the rejection response and forwarding behavior, leaving gaps beyond what the annotations cover.

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?

Only one parameter exists and its schema description has 100% coverage, so the baseline is 3. The description adds no syntax, format, or content detail about the body beyond what the schema already says (deferring to the OpenAPI contract).

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 pair (check/reject) and resource (payload PII) with a clear scope of operation ('before forwarding'). It is clear what the tool does, though it does not distinguish itself from sibling gate/check tools such as edge_audit or the various *_check 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?

'Before forwarding it' implies the usage context (an outbound/inline gate), but no alternatives are named and no conditions for when-not to use it are given. Usage is inferable 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?

Annotations already declare readOnlyHint/idempotentHint/non-destructive, covering the safety profile, so the bar is lower. The description nevertheless adds nothing beyond that: no return format, no pagination, no statement of whether the query object is required or what keys it accepts for a catalogue listing.

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 wasted words. It is efficient, though its brevity borders on under-specification for a tool with a free-form query parameter.

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 read-only catalogue lister with annotations covering safety and no output schema, the basic scope is conveyed. But the ambiguous free-form query object and the lack of any hint about returned content leave gaps an agent would have to probe at runtime.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is a single optional parameter, so the baseline is 3. The description adds no meaning about the free-form 'query' object, whose arbitrary string/number/boolean properties would benefit from explanation of accepted filter keys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.