RunOnProof — Payment Decision and Agent ID

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the term 'Free:' which might imply no cost or no restriction, but this is ambiguous and not a substantive behavioral disclosure. It does not contradict annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. 'Free: list all capabilities and prices' immediately conveys the tool's purpose and any caveat about cost.

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

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

Given the tool's simplicity (zero parameters, read-only, idempotent), the description is mostly adequate. The phrase 'capabilities and prices' implies the return format (a list with prices). However, it lacks domain context (e.g., what types of capabilities) and there is no output schema to clarify, but the low complexity reduces the need for more detail.

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

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

The tool has zero parameters, so there is nothing for the description to explain. Per the baseline guidance, a 0-parameter tool receives a 4. The description adds no parameter information, but none is needed.

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

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

The description clearly states the tool's function with a specific verb ('list') and resource ('all capabilities and prices'). It distinguishes itself from sibling tools, which are all action-oriented (e.g., 'approve', 'verify'), making this the only listing/query tool.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions or alternative tools for related tasks like 'build_uk_company_capability_passport'. Usage context is only implied by the function itself, not explicitly 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?

The description adds a key security detail beyond annotations: private keys are generated and retained locally, and the tool never accepts them. This is important behavioral context not present in the readOnlyHint, idempotentHint, or destructiveHint annotations. It also notes the challenge is 'free', which implies no payment side-effect. This adds value without contradicting 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?

Two concise sentences with no filler. The primary action is front-loaded, and the security clarification follows immediately. Every word earns its place.

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

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

Given the tool's complexity (13 parameters, nested objects, enums, no output schema), the description is far too minimal. It does not explain how to select parameters for different purposes, what the challenge response contains, or how the local key generation relates to the challenge. Even with annotations covering safety, the agent lacks the information needed to correctly invoke this 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 description mentions no parameters at all. With 13 parameters, 0% schema description coverage, and several enums and nested objects, the agent has zero guidance on which parameters are required for which purpose. The description does nothing to compensate for the sparse schema.

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

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

The description states a specific verb ('Issue') and resource ('challenge'), and clearly scopes it to 'Agent ID enrollment or key lifecycle'. This distinguishes it from sibling tools like get_agent_id_bootstrap or export_agent_identity, which serve different purposes. The 'free' qualifier also adds useful context.

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

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

The description gives a clear context (enrollment or key lifecycle) but does not explicitly compare to alternatives or state when not to use this tool. It implies usage but leaves the agent to infer the boundaries versus sibling tools. No exclusions or alternative routing are provided.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds the valuable context that the result is portable, public, and bound to a point in time ('status-as-of limitation'). This is genuine behavioral information beyond the annotation fields, although it does not detail the bundle contents or return 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?

The entire description is one dense sentence that front-loads the action, names the output, states the purpose, and flags the key limitation. There is no filler or repetition of the tool name.

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 export with strong safety annotations, the description covers the essential purpose and a key limitation without over-explaining. It could be more complete about what the identity bundle contains or how the status-as-of limitation is surfaced, but an agent has enough context to invoke the tool and interpret its result at a high level.

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

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

The input schema has one required parameter (agent_id) with zero description coverage, and the tool description provides no information about the parameter or how to supply it. The parameter is self-descriptive by name and the schema gives a pattern, but the description itself adds no semantic guidance, so it fails to compensate for the 0% schema coverage.

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

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

The description uses a specific verb ('Export') and names a concrete resource ('portable public identity bundle'), with a clear purpose ('offline cryptographic verification') and a distinguishing time limitation. It does not explicitly differentiate itself from siblings such as get_agent_identity_jwks or get_agent_identity_status, but the export-bundle framing is clear enough to identify what the 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?

It states the intended use case ('offline cryptographic verification') and implicitly warns that the bundle carries a 'status-as-of limitation', which tells an agent not to use it when a live current identity is required. It gives clear context but stops short of naming when-not-to-use or sibling alternatives explicitly.

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, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral detail that it returns exactly two items and is free, which is useful beyond annotations.

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

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

The description is very brief and front-loaded, with no filler. However, the cryptic terminology ('exact x402 resource') and the unusual 'Free:' prefix reduce its effectiveness despite the 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?

Without an output schema, the description must explain what the tool returns, but 'commercial solution' and 'exact x402 resource' are undefined domain terms. An agent cannot reliably predict the response format or semantics from this description 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?

The tool has zero parameters and the schema is fully covered by an empty properties object, so there is no parameter documentation burden. The description does not need to add parameter semantics.

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

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

The description specifies a verb ('return') and two concrete result items ('1 commercial solution' and '1 exact x402 resource'), but neither term is explained. It does not distinguish itself from sibling tools like 'capabilities' or 'quote'.

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

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

No guidance is given about when to use this tool versus any of the many sibling tools. The leading 'Free:' may imply a cost advantage, but it does not state conditions, alternatives, or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context about what the tool resolves (the free Agent ID contract) and what it covers (next request, local-key rules, supported interfaces), which is useful but does not disclose return format or failure behavior. No contradiction with annotations.

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

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

The description is a single sentence that front-loads the core action ('Resolve the free RunOnProof Agent ID contract') and then lists the covered aspects. It is concise and information-dense, though the list of covered aspects is a bit compressed.

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 zero-parameter, read-only, idempotent tool, the description is mostly complete. It explains what the tool does and what it covers, but it does not describe the output shape or how the result relates to sibling tools like get_agent_identity_status. Given the absence of an output schema, a bit more detail on what 'resolve' returns would improve completeness.

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

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

The tool has zero parameters, so the schema is trivially complete. The description adds meaning by explaining what the tool resolves and what aspects it covers, which is valuable context for a no-input tool. Baseline 4 for zero params 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 names a specific verb ('Resolve') and a specific resource ('the free RunOnProof Agent ID contract'), and lists the aspects it covers ('exact next request, local-key rules and supported interfaces'). It is clear about what the tool does, though it does not explicitly differentiate from siblings like get_agent_identity_status or resolve_agent_intent.

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 a bootstrap/resolution use case ('exact next request, local-key rules and supported interfaces') but does not explicitly state when to use this tool versus alternatives like resolve_agent_intent or get_agent_identity_status. There is no when-not-to-use 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 destructiveHint false, so the safety profile is established. The description adds context beyond annotations by specifying that the operation resolves public, non-enumerating verification keys for one agent, which signals a privacy-preserving, targeted read.

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 well-structured sentence that front-loads the action and resource while adding the key scoping constraint. No redundant or filler content exists.

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, read-only, idempotent lookup with a clear purpose, the description is complete: it identifies what is resolved, for whom, and what the operation does not do. The absence of an output schema is not harmful because 'public verification keys' and RFC 8037 communicate the expected return.

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 0% schema description coverage, the description must carry parameter meaning. It explains that agent_id is an opaque Agent ID and that the operation targets exactly one of them, adding semantic value beyond the raw schema pattern. It does not restate the required/format constraints, but there is only one parameter and its role is clear.

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, 'Resolve', names the exact resource, 'RFC 8037 public verification keys', and scopes it to 'one opaque Agent ID'. The clause 'without enumerating identities' differentiates it from bulk identity operations, making the purpose unambiguous.

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

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

It clearly conveys that this tool is for a single opaque Agent ID and not for enumerating identities, which gives an agent a selection cue. It does not explicitly name a sibling alternative or list when not to use it, but the scoping language is sufficient for a simple lookup 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 convey the read-only, idempotent, non-destructive profile, so the description gets no credit for those. 'Explicit freshness semantics' promises added behavioral detail but never explains what freshness means or how it is represented, leaving the tool's actual behavior largely undisclosed.

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 active sentence with the purpose front-loaded, which is efficient. But the key new idea, 'explicit freshness semantics,' is vague fluff until its actual semantics are specified, so the concision costs real content.

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

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

There is no output schema and no mention of what the return payload contains, how freshness is reported, or how key status and identity status relate. For a tool named 'get_agent_identity_status,' the description still leaves the agent guessing at the outcome.

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 required parameter, agent_id, has a strict pattern but no schema description, and coverage is 0%. The description mentions 'Agent ID' but does not clarify whether the parameter is the current agent, a target agent, or how 'current' relates to it, so the parameter's meaning is underdetermined.

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

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

The description states a specific action ('Resolve') and resource ('current Agent ID and key status'), so the tool's general job is visible. However, it does not differentiate it from sibling tools like get_agent_id_bootstrap or get_agent_identity_jwks, and 'freshness' is named but never defined.

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 such as verify_agent_signature or get_agent_public_profile. The description provides no conditions, exclusions, or hints about the situation where this particular identity-status lookup is the right 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 provide readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds a meaningful behavioral detail that no directory or enumeration is provided, which sets expectations about scope. However, it does not disclose what happens for invalid or unknown IDs, nor explain what 'key lifecycle' entails.

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

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

The description is short and front-loaded with the primary action, and the second clause adds a scoping caveat. However, it relies on the unexplained term 'key lifecycle', and the brevity actually contributes to the ambiguity. It is compact but not sufficiently clear for a new reader.

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

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

Given that there is no output schema, the description should at least summarize what a 'minimized key lifecycle' contains or how to interpret the result. It also does not explain how this tool relates to the more than a dozen sibling identity tools, leaving an agent to guess the difference. The mention of 'no directory or enumeration' is useful but insufficient for a complete picture.

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 schema description coverage at 0%, the description must compensate, but it only calls the parameter an 'opaque Agent ID'—already apparent from the parameter name. It does not describe the format pattern, why the ID is opaque, how to obtain one, or any other semantics that would help an agent fill the parameter correctly.

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 'Resolve one opaque Agent ID to a minimized key lifecycle' which gives a verb and resource, but 'key lifecycle' is an unusual and undefined term that obscures what the returned data actually is. It distinguishes only by saying 'no directory or enumeration is provided', which does not adequately differentiate from sibling tools like get_agent_identity_jwks or export_agent_identity. An agent cannot confidently infer what this tool returns or how it is different.

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 only usage guidance is the negative statement 'no directory or enumeration is provided', implying that this tool works with a single opaque ID rather than lists. There is no explicit guidance on when to choose this tool over the many agent identity-related siblings, no mention of expected caller context, and no when-not-to-use conditions.

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, and non-destructive behavior. The description adds value by disclosing the cost aspect ('Free') and the specific output dimensions (resolvability, coverage, confidence, price), which are not present in annotations. This extra context goes beyond the structured safety hints.

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

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

The description is a single 12-word sentence, front-loaded with the key differentiator 'Free', and contains zero redundant words. Every word earns its place.

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

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

For a simple one-parameter tool with robust annotations, the description adequately covers the purpose and expected output dimensions. It lacks a detailed output format, but no output schema exists and the estimate is conceptually clear, making the description sufficient for this complexity level.

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

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

The input schema fully describes the only parameter ('cnpj' as a Brazilian CNPJ, 14 digits) with 100% coverage. The description simply uses the same term without adding new syntax or format details, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb ('estimate'), the resource ('CNPJ'), and the scope ('resolvability, coverage, confidence and price') with a temporal context ('before paying'). It differentiates from sibling tools like 'quote' by emphasizing 'Free' and the pre-payment nature, making the tool's unique role 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?

The context 'before paying' clearly indicates when to use this tool, and 'Free' suggests an economical pre-check. However, it does not explicitly mention alternatives or exclusions, so the guidance is clear but not exhaustive.

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 says 'atomically consume' a challenge, which indicates a mutating, state-changing operation. This directly contradicts the annotation readOnlyHint=true. While it does add useful contextual details (detached proofs, no private key), the contradiction invalidates the transparency benefit and warrants a score of 1.

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 main verb and resource, and every word contributes. 'Submit detached local proofs and atomically consume an Agent ID challenge' is compact and informative, and the second sentence adds a crucial security constraint without padding.

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 complex: a nested proof object, multiple optional signatures, and a challenge ID, with no output schema and no schema descriptions. The description omits how the challenge is consumed (what the response is), what each signature is for, and what error or idempotency behavior to expect. It is not complete enough for an agent to call 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 0%, so the description needs to compensate by explaining the parameters. It conveys the general idea of 'detached proofs' and a challenge, but gives no meaning to the nested fields idempotency_key, context, or the various signature fields. The complex proof object remains largely undocumented.

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

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

The description states a specific action and resource: 'Submit detached local proofs and atomically consume an Agent ID challenge.' This clearly differentiates it from siblings like create_agent_identity_challenge (which creates challenges) and verify_agent_signature (which verifies signatures). The phrase 'No private key is accepted' further defines the tool's scope.

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 explicit when-to-use or alternative guidance is given. The phrase 'consume an Agent ID challenge' implied the tool is meant to be called after a challenge exists (likely from create_agent_identity_challenge), but this is left to inference. No exclusions or sibling comparisons are provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no meaningful behavioral context beyond that, leaving unclear what a quote entails or what output to expect.

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 extremely short, but it is under-specified rather than effectively concise. It doesn't earn its place because it omits critical information needed for correct use.

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 only one parameter and no output schema, the description should clarify enough for selection and invocation. It fails to do so, especially given the large set of sibling tools that include 'capabilities' and 'preflight', which could overlap in purpose.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'capability' as the parameter, offering minimal semantic value. It doesn't explain what a capability is, its format, or valid values.

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 it provides a quote for a capability, which is a specific action and resource. However, it is vague—'quote' is ambiguous and no scope or distinction from sibling tools is provided.

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

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

No guidance is given on when to use this tool versus alternatives. The phrase 'Free:' is unrelated to usage context, and there is no mention of scenarios or exclusions.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds meaningful context on top: the decision is 'Paid', replay is deterministic, and the tool does not execute supplier payment. These are behavioral details not inferable from annotations, and there is no 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?

The text is compact and front-loads the central purpose, but the very specific '0.79 USDC' and the dense stack of qualifiers add noise. A more general statement of the tool's capability would be clearer without losing 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 tool with 25 parameters, 24 required, nested objects, and almost no schema descriptions, the definition provides only high-level scope. It mentions US-only, FEDERAL_ONLY, deterministic replay, and non-execution, but omits fee mechanics, idempotency expectations, and any guidance on the large required payload. The output schema helps with return values but not with invocation requirements.

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 only 8%, so the description should compensate by explaining key parameters, but it does not. The only hint is 'signed BuyerPaymentMandate, signed Proof Capsule', which maps loosely to buyer_mandate and evidence references, while critical fields like idempotency_key, jurisdiction, coverage, and payout amounts go unexplained.

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

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

The description identifies a specific resource: a paid RunOnProof release-payment decision, limited to a US FEDERAL_ONLY context, and explicitly distinguishes itself from actual supplier payment execution. However, the hardcoded '0.79 USDC on Base' makes it read like a single transaction instance rather than a general tool, and no sibling tool is named for differentiation.

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 situation: use this when a release-payment decision is needed, and the closing statement 'RunOnProof does not execute supplier payment' provides a when-not boundary. But it never states explicit conditions for choosing this tool over siblings like preflight or quote, nor does it describe any alternative.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful context by stating that the tool makes no source call, incurs no charge, and supports honest negative selection. This clarifies the behavioral and cost profile 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?

The description is a single, dense sentence with no fluff, and the selected input modes are listed in a parallel structure. The leading 'Free:' is ambiguous and slightly confusing, detracting from clarity, but overall it is highly compact.

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

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

The tool has three mutually exclusive parameter modes and important behavioral claims ('free', 'honest negative selection'), yet the description does not explain what the response contains, what 'honest negative selection' means, or which mode should be preferred. Given the large sibling set and absent output schema, the description is under-specified for confident use.

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

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

The schema provides only parameter names with no descriptions, so the parameter semantics depend entirely on this description. It maps intent_id to 'canonical intent', problem_state to 'brandless problem state', and query to 'plain-language problem query', also noting negative selection. This gives meaning to all three parameters, though without formats or examples.

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 verb ('select') and the resource (canonical intent, problem state, or plain-language query), so it is not a tautology. However, 'resolve_agent_intent' as a purpose is never explicitly defined; 'Free:' is ambiguous and the description does not make clear what resolution implies or returns, so it is only a vaguely useful purpose statement.

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 hints at when the tool is relevant ('free', 'no source call, charge or settlement') but gives no explicit guidance on when to choose this tool over its many siblings, such as resolve_legal_entity or decide. There is no when-not guidance or alternative routing, so an agent must infer the intended use.

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 indicate readOnlyHint=true and idempotentHint=true, which the description aligns with by saying 'Verify'. However, the description adds no additional behavioral detail such as what the verification result looks like, whether it returns a boolean or a report, or any side effects. It does not contradict annotations but contributes minimal transparency beyond them.

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 short sentence, but it is not effectively concise—it is under-specified and uses vague terminology. It is not front-loaded with the primary action (verifying an agent signature); instead it lists abstract security properties. A concise description would state the core function clearly in one or two sentences, but this does not.

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

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

The tool has a complex input schema with a nested envelope object containing 13 required properties, and no output schema. The description provides none of the needed context: what the envelope is, how to generate a signature, what 'payload/context integrity' means in practice, or what the tool returns. It is completely inadequate for an agent to call this tool 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 0%, so the description is the only source of parameter meaning. Yet it mentions none of the parameters (envelope, payload, context, invitation_ref). It does not explain how to construct or interpret the envelope object, or what payload/context refer to. The agent is left with no guidance on how to populate the required 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?

The description says 'Verify' but the object is vague: 'cryptography, payload/context integrity, lifecycle interval, replay and temporal assurance' is a list of security properties, not a clear statement that this tool verifies an agent's signature on a payload/context. It does not distinguish from sibling tools like verify_passport or verify_receipt. The phrase 'for free' is extraneous and confuses rather than clarifies 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?

There is no guidance on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or scenarios for use. An agent would have no idea if this is the right tool for a given verification task.

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 and idempotentHint=true, but the description adds no further behavioral context, such as what verification entails, return format, or side effects. The prefix 'Free:' is ambiguous and does not contribute to transparency.

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

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

The description is very short and front-loaded, but the 'Free:' prefix is unnecessary and detracts from clarity. It is concise but under-specified, not striking the right balance.

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

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

With no output schema, the description should explain what the tool returns (e.g., a boolean, a verification report). It also fails to describe what a 'signed decision passport' is or how it is verified, leaving significant gaps for a tool with a nested object 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?

The schema has one param 'passport' with no description, and schema description coverage is 0%. The description only implies that the passport object should be a 'signed decision passport', but does not explain its structure or required fields, leaving the agent to guess.

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

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

The description clearly states the verb 'verify' and the resource 'a signed decision passport', making the core purpose evident. However, it does not differentiate this from sibling tools like verify_company_passport, though 'signed decision passport' is a distinct object type.

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, and no contextual cues. The description only gives a bare definition without any usage context.

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, and destructiveHint=false, so the safety profile is clear. The description adds no meaningful behavioral context beyond stating the action, such as what constitutes a signed decision receipt, what happens on failure, or any side effects. 'Free' is irrelevant to behavior.

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

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

The description is extremely short and has no fluff, but the prefixed 'Free:' is a distraction and the overall structure is an under-specified single clause. While concise, it lacks essential detail, making it more of a fragment than a well-structured explanation.

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 operates on a 'signed decision receipt' without any context about what that is, how to obtain one, or what verification entails. With no output schema and a single nested object parameter, the description is far too minimal to be contextually complete, especially alongside numerous sibling verification tools.

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

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

Schema description coverage is 0%, and the description provides no information about the structure or required fields of the 'receipt' object. The schema only specifies type 'object' with no properties, leaving the agent without any semantic guidance on what to pass. The description fails to compensate for this gap.

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

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

The description clearly states the tool's action ('verify') and specific target ('a signed decision receipt'), which is a unique resource among the sibling verification tools. It distinguishes itself from siblings like verify_company_status or verify_passport by focusing on decision receipts.

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. The description simply states what it does without mentioning use cases, prerequisites, or exclusions. Given the large number of sibling verify_* tools, the absence of contextual usage guidance is a notable gap.

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