RunOnProof

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

The annotations declare readOnlyHint=true and idempotentHint=true, but the description contradicts this by describing a 'Global RunOnProof tool' that 'preserves country-specific coverage, sources, freshness and limitations' - this sounds like a read operation, not a mutation. However, 'approve_supplier' as a name implies a write/approval action. The description is vague and doesn't clarify the tool's behavioral traits beyond what annotations imply.

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 (2 sentences) and front-loaded with the key country constraint. However, it's too terse given the tool's complexity (3 oneOf branches, many parameters). It could be more informative while still being 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?

Given the complex input schema with 3 country-specific branches and no output schema, the description is severely lacking. It doesn't explain the oneOf structure, what each country case requires, what the response contains, or how to choose between branches. The sheer number of sibling tools (30+) makes this lack of guidance even more harmful.

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

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

Schema coverage is 0%, so the description must compensate. It mentions countries (BR, GB, US) and that US tools are FEDERAL_ONLY, but barely explains the complex oneOf schema. The description adds almost no meaning to the parameters - it doesn't explain what cnpj, company_number, supplier, payee, policy details mean or how they relate to the tool's purpose.

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 'Global RunOnProof tool' and lists supported countries, but it doesn't explicitly state what it does with a specific verb and resource. The name 'approve_supplier' implies supplier approval, but the description is too abstract about 'preserving coverage, sources, freshness and limitations.' It doesn't clearly distinguish this from siblings like 'approve_uk_supplier' or 'run_uk_supplier_approval'.

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 tells which countries are supported (BR, GB, US) and mentions US federal tools are FEDERAL_ONLY, but it doesn't explain when to use this tool vs siblings like 'approve_uk_supplier' or 'run_uk_supplier_approval'. There's no guidance on when not to use this tool or what prerequisites exist.

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 context about it being 'Paid x402' and that claims are limited to official sources, which gives extra behavioral context. However, it remains vague about side effects, costs, or what 'claims' means, so it only partially supplements 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 very short with no verbose filler, which is good for conciseness. However, the text is cryptic ('x402', 'AVAILABLE', 'named official sources') and under-specifies the tool, making clarity suffer. It is concise but not effective communication.

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

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

Given the tool has 7 parameters, nested objects, an output schema, and many siblings, the minimal description is insufficient. It lacks usage context, behavior under failure, and does not clarify what 'paid' or 'claims limited' means operationally. An output schema exists, but this does not compensate for missing contextual guidance.

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 43%, and the description adds no parameter-level information. It does not explain fields like vat_number, eori_number, sanctions_subject_names, or the nested binding_evidence. With low coverage, the description was expected to compensate, but it does not.

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 'Paid x402 UK tool for gb.supplier.approve.v1 (AVAILABLE)' names a method but does not state what the tool actually does with a verb. It does not clearly say it approves, checks, or verifies a UK supplier, and it does not distinguish this tool from siblings like approve_supplier or run_uk_supplier_approval.

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 compared to alternatives. The phrase 'Claims are limited to the named official sources' hints at a constraint but does not explain when this tool is appropriate or when another tool should be chosen. Sibling tools offer many similar approval functions, but no differentiation is 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 readOnlyHint, idempotentHint, and non-destructive behavior. The description adds 'Claims are limited to the named official sources', which gives some behavioral context about output restrictions. However, it does not elaborate on what 'named official sources' means or describe other behaviors. 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 concise at two sentences, but it is not well front-loaded. The first sentence leads with 'Public no-charge' and a technical identifier instead of stating the tool's purpose. While there is no wasted wording, the structure does not prioritize the most important information.

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

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

Despite having an output schema and strong annotations, the description fails to explicitly state what the tool does. It leaves the core purpose ambiguous and does not explain how the tool is invoked or what context it uses (since there are no parameters). The vague 'LIMITED' and 'named official sources' add little clarity. Overall, the description is insufficient for confidently selecting the tool.

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

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

The tool has 0 parameters, so the baseline is 4. The description does not need to add parameter semantics because there are no parameters. The empty input schema with additionalProperties is not explained, but since parameter count is zero, this is not a significant 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 says 'tool for gb.invoice.authenticity_duplication.assess.v1', which essentially restates the tool name 'assess_uk_invoice_authenticity_duplication' in a technical form. It does not explicitly state that the tool assesses invoice authenticity and duplication. 'Claims are limited to the named official sources' provides some scope but does not clarify the core action.

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 only mentions 'Public no-charge' and 'LIMITED', which hint at conditions but do not explain appropriate usage or when not to use the tool. No sibling tools are referenced.

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 and idempotentHint. The description adds useful context about being public/no-charge and that claims are limited to named official sources, which is a meaningful constraint. However, it does not specify which sources or what 'limited' entails, leaving some ambiguity.

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 just two concise sentences with no filler, front-loading the tool's public/no-charge nature. The cryptic version string 'gb.source_evidence_freshness.assess.v1' introduces some noise but does not undermine overall 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?

Despite having no parameters and an output schema, the description lacks essential domain context. It does not explain what 'freshness' means, what the 'named official sources' are, or what kind of claims the tool produces, leaving the agent with significant ambiguity about the tool's actual 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?

The tool has zero parameters, and the input schema is empty, so there is nothing for the description to explain. The baseline of 4 applies, and the description adds no parameter-related information, which is acceptable.

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 tool name clearly indicates it assesses the freshness of UK source evidence, and the description references a specific model version 'gb.source_evidence_freshness.assess.v1'. It is distinct from sibling tools like assess_uk_invoice_authenticity_duplication, though the description does not explicitly define 'freshness' or 'source evidence' in plain terms.

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 offers no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The 'Public no-charge' note is a cost/access fact, not a usage guideline.

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=true, idempotentHint=true, destructiveHint=false. The description reinforces that this is a non-destructive operation (RunOnProof) and adds behavioral context about the US federal limitation. It does not contradict annotations. However, it does not fully explain what happens when the tool is invoked (e.g., it does not say it returns an authorization result). The country-specific behavioral notes are helpful.

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—only two sentences—but it is dense with important information (countries, response preservation, US federal limitation). It is front-loaded with 'Global RunOnProof tool' which is effective. However, it could be restructured to be more scannable, and the second sentence about US tools could be clearer. It earns its place but is not polished.

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 (three distinct country schemas with many nested objects), the description is woefully incomplete. There is no explanation of what 'RunOnProof' means, no guidance on how to select the correct schema variant, no description of return values (no output schema), and no mention of idempotency or the many required parameters. The description adds very little beyond what is in the 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?

The schema description coverage is 0%, so the description must carry the burden. The description does not detail any of the numerous parameters (e.g., idempotency_key, payee, supplier, etc.), which is a significant gap. However, the schema itself provides rich structure with nested objects and constraints, so the description adds no value beyond stating country choice. This is a major missed opportunity.

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 starts with 'Global RunOnProof tool' which gives a high-level purpose, then explicitly lists supported countries (BR, GB, US) and mentions that the response preserves country-specific details. However, it does not clearly state that this tool authorizes payments; the name 'authorize_payment' implies it, but the description focuses on response properties rather than the action itself. It distinguishes from siblings like 'authorize_uk_business_payment' by being multi-country.

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 indicates to choose a country from the three listed, which provides some guidance on when to use this tool (for BR, GB, or US payments). It also includes a caution about US federal tools being FEDERAL_ONLY and not asserting state good standing, which is an important when-not note. However, it lacks explicit guidance on when to use this versus sibling tools like 'authorize_uk_business_payment', and does not mention alternatives for other countries.

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, idempotentHint, and destructiveHint, so the safety profile is known. The description adds only the cryptic statement that 'claims are limited to the named official sources' without explaining what claims are or what the tool does, offering little behavioral context 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 short but cryptic. The phrase 'Paid x402 UK tool for gb.business.payment.authorize.v1 (LIMITED)' reads as an identifier, not an explanation. 'Claims are limited to the named official sources' is ambiguous and does not contribute meaningful understanding, making this under-specification rather than 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?

With a heavily nested 8-parameter schema and an output schema, the description is far too thin to be actionable. It does not explain the tool's purpose, prerequisites, or what constitutes a successful authorization, making it incomplete for a tool of 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 coverage is 50%, but the description provides zero parameter information. It does not explain the meaning or relationship of required fields such as company_number, supplier, invoice, payee, amount, currency, or idempotency_key, leaving the agent without additional semantic context.

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 the API version 'gb.business.payment.authorize.v1' and calls it a 'Paid x402 UK tool', but never states that it authorizes a UK business payment. The verb is only implied by the tool name, and it does not distinguish itself from similar siblings like authorize_payment or run_uk_payment_authorization.

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 second sentence about claims being limited to named official sources is a constraint, not usage direction, and no sibling tools or alternative conditions are mentioned.

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, covering safety. The description adds 'Paid' (monetary cost) and 'LIMITED' scope, but 'named official sources' is undefined and the meaning of 'Claims' is ambiguous, limiting extra behavioral insight. 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 only two sentences but is not front-loaded or clear. The cryptic phrasing and undefined terms don't earn their place; conciseness should support clarity, not obscure 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?

With a complex nested challenge object, 6 required parameters, and an output schema, the description is far too sparse. It fails to explain the tool's purpose, the meaning of 'LIMITED' and 'named official sources', or how it fits into the vendor payment change workflow, making proper invocation unlikely.

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 83% and already documents each parameter well. The description adds no parameter-level detail, so the baseline of 3 applies; it neither clarifies relationships nor compensates for any gaps.

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 restates the endpoint name in cryptic terms without stating the tool's actual action. 'Claims are limited to the named official sources' is vague and does not clarify what the tool does or how it differs from siblings like authorize_uk_business_payment or continue_vendor_authorization.

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. It does not mention prerequisites, exclusions, or relationships to related tools such as run_uk_vendor_change_continuous_authorization, leaving the agent without selection criteria.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds value beyond those annotations by disclosing that the response preserves country-specific coverage, sources, freshness and limitations, and it warns that US federal tools never assert state good standing or the OFAC 50 Percent Rule. This is extra behavioral context not present in 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 short and front-loaded, with no obvious filler, but the term 'RunOnProof' is presented without explanation and the core action is missing. It is concise but obscure, so the structure/resourceening alone does not justify a higher score.

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

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

For a tool with 11 required parameters, no output schema, and no parameter documentation, this description is severely incomplete. It does not explain how to construct prior_authorization, how to choose change_reason, what current_context should contain, or the nature of the vendor payment change. The description leaves out nearly all context an agent needs to invoke the 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% and the description provides no parameter semantics. It references 'country' only conceptually, but the schema already constrains country to 'US', so it adds no meaning. The rich nested objects like current_payee, proposed_payee, current_context, and prior_authorization are completely unexplained in the description.

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 does not state what the tool does; 'Global RunOnProof tool' is an unexplained label and never explicitly says 'authorize a vendor payment detail change' or names the operation's verb/resource. It mentions response characteristics and a US restriction, which are contextual, not a purpose statement. The actual operation can only be inferred from the tool 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?

"Choose country from US" provides an implied usage context: this tool is for the US country variant. However, it does not explicitly contrast it with the sibling authorize_uk_vendor_payment_detail_change or state when not to use it. The US federal FEDERAL_ONLY note gives partial exclusion context but not a full alternative-selection policy.

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 operation as read-only, idempotent, and non-destructive. The description adds useful behavioral context: it is metadata-only, requires authenticated HTTP operator access, and limits claims to named official sources. These details go beyond the annotations, though some terms like 'AVAILABLE' and 'claims' remain unexplained.

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, but the grammar is awkward and cryptic ('access required UK tool'). It could be restructured into clearer sentences without adding length, improving readability.

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 zero parameters and an output schema, less description is needed, but the tool still lacks operational context. It never explains what a capability passport is, what 'Metadata-only' means for a tool named 'build', or what counts as 'named official sources'. This makes it difficult for an agent to understand the tool's purpose and select it appropriately.

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

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

The tool has zero parameters, so the description cannot add parameter-level meaning. Schema coverage is 100% by default, and the baseline for zero-parameter tools is 4.

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

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

The description provides no clear verb or outcome; it merely references 'company.capability.passport.v1' which restates the resource implied by the tool name. 'Metadata-only' is ambiguous and does not explain what building the passport actually does, nor does it distinguish this tool from siblings like issue_company_passport or refresh_company_passport.

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 statement indicates when to use this tool versus alternatives, and no exclusions or alternative tool names are provided. 'Authenticated HTTP operator access required' is a precondition, not a usage guideline.

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, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context: the response preserves country-specific coverage, sources, freshness, and limitations, and details US federal-only behavior. This is meaningful behavioral context 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?

The description is extremely concise: two sentences with no filler. It front-loads the purpose ('Global RunOnProof tool') and then adds essential country-specific details. Every sentence contributes 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?

Given the complex oneOf schema, no output schema, and many sibling tools, the description is incomplete. It lacks guidance on input structure, return format, idempotency_key requirement, and how to differentiate country variants. Only the US limitation is addressed, leaving significant gaps for an agent to use the 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% and the description provides no parameter information. The schema is complex with oneOf variants requiring different parameters (cnpj, company_name, company object). The description does not mention any parameter names, required fields, or how to select the correct variant. Despite the baseline of 4 for zero parameters, the description fails to compensate.

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 'Global RunOnProof tool' and enumerates countries (BR, GB, US), making the verb+resource clear. It further specifies US federal-only limitations. However, it does not explicitly differentiate from sibling UK-specific tools (e.g., run_uk_company_check), leaving the agent to infer when to use this tool versus alternatives.

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

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

No explicit guidance on when to use this tool vs sibling tools. The description implies coverage for BR, GB, US, but fails to mention that UK-specific tools may be preferred for UK checks, or when to use which country variant. The US federal-only note is a limitation, not a usage guideline.

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 that the response preserves country-specific coverage, sources, freshness, and limitations, and clarifies that US federal tools are FEDERAL_ONLY and never assert state good standing or OFAC rules. This adds moderate behavioral context 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 two sentences and fairly short, but the first sentence uses unexplained jargon ('RunOnProof') and the second sentence is specific to US limitations. It is concise but not effectively front-loaded with the core purpose.

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

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

Given the tool's high complexity (multi-country oneOf schema, no output schema, many siblings), the description is woefully incomplete. It does not explain what the tool returns, how parameters differ by country, or how it relates to similarly named siblings. The agent cannot properly invoke this tool based on the 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?

Schema description coverage is 0% and the description does not explain any of the many nested parameters. The only parameter mentioned is 'country'. For a complex schema with oneOf shapes and dozens of fields, this is a critical gap. The description adds no meaning beyond the raw JSON structure.

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 'Global RunOnProof tool', which is jargon and does not clearly state the action or resource. It mentions country selection and response characteristics but fails to define what 'continue_vendor' actually does. The sibling 'continue_vendor_authorization' has a more explicit name, creating confusion.

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 tells the user to choose a country from BR, GB, US and notes US federal tool limitations, but it provides no guidance on when to use this tool versus its many siblings (e.g., approve_supplier, continue_vendor_authorization). No when-to-use or when-not-to-use context is 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 cover read-only, idempotent, and non-destructive behavior. The description adds useful context about being public, no-charge, UK-scoped, and claims being limited to named official sources, which gives the agent some behavioral expectations. No contradiction with annotations, but it doesn't elaborate on how claims are limited or any caveats.

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

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

The description is concise, consisting of two short sentences with no filler. It front-loads the public/no-charge/UK status and the API operation, then adds a constraint. Slight lack of plain-language clarity, but it is efficient.

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

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

Although an output schema exists, the description fails to state the core functionality in plain terms. A simple 0-parameter, read-only tool still needs a clear statement of what it does; the description only provides an API name and a limitation. This leaves the agent guessing the purpose, which is a substantial gap for a tool with no other 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 input schema has zero defined parameters and allows additional properties, but no parameter documentation is provided. Baseline for 0 parameters is 4, and the description adds no parameter information, so it does not detract. However, with additionalProperties true, a bit of guidance could have clarified what the tool accepts, but this is not required.

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 references 'vendor.authorization.continue.v1' which echoes the tool name in API format rather than explaining the tool's function in plain language. It fails to state what the tool actually does (e.g., 'continues a vendor authorization') and does not distinguish it from similar tools like 'continue_vendor' or 'run_uk_vendor_change_continuous_authorization'.

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

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

There is no guidance on when to use this tool versus alternatives. The description only notes that it is 'public no-charge UK' and that claims are limited, but does not specify suitable scenarios, prerequisites, or exclusions. No mention of sibling tools or when to prefer this operation.

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 'deterministic' (consistent results) and 'Paid (x402)' (cost implication), which are behavioral traits beyond the annotations. No contradiction with annotations is present.

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 phrase, which is concise, but it is under-specified for a tool with two parameters and nested objects. It is front-loaded but lacks necessary structure or elaboration, making it insufficiently informative for its 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 a tool with no output schema and a nested input schema, the description does not explain return values, prerequisites, or edge cases. It fails to convey what 'counterfactual analysis' returns or under what conditions it should be invoked, leaving the agent without critical context.

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

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

Schema description coverage is 0%, and the description provides no explanation of the 'subject' or 'counterfactual' parameters. The name 'counterfactual' and the schema field align, but the description doesn't clarify what the counterfactual object should contain or how the CNPJ is used, leaving the agent without meaningful parameter guidance.

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 'deterministic counterfactual analysis' provides a domain-specific noun phrase but lacks a clear verb+resource structure. It doesn't explicitly state what action is performed on the subject or what output is produced, distinguishing it from siblings only by its generic 'analysis' label. It is not a tautology but is vague about the tool's core function.

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 or alternatives are mentioned. The phrase 'Paid (x402)' hints at a cost condition, but it doesn't explain scenarios where this tool should be preferred over sibling tools like 'decide' or 'preflight'. There is no explicit guidance on excluding 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=true and idempotentHint=true, but the description adds little useful behavioral context. The term 'signed decision' is ambiguous (could imply producing a signed document), and 'Paid (x402)' is cryptic and potentially confusing, adding no clarity about side effects or expected 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 very short and front-loaded, but the opening 'Paid (x402)' is cryptic and not immediately informative. It is concise but sacrifices clarity, making it only minimally acceptable.

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

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

Given the tool has nested objects, no output schema, and an ambiguous action, the description is severely incomplete. It fails to explain what the decision output looks like, the meaning of 'signed,' or how the objective parameter influences the decision, leaving the agent under-informed.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. It mentions 'objective-based' but never explains the 'objective' parameter or the 'subject' object structure. The only parameter hint, 'cnpj' in the schema, comes from the schema itself, not the description.

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 'objective-based signed decision for a Brazilian company,' which vaguely indicates a decision-making action but lacks a clear verb or specific outcome. It does not distinguish this tool from sibling tools such as 'approve_supplier' or 'verify_company_status' beyond the geographic focus, which is insufficient.

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 guidance on when to use this tool versus alternatives. The only hint is the phrase 'Brazilian company,' which implies a geographic scoping relative to the UK-focused siblings, but no direct comparison or exclusion criteria 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 read-only, idempotent, non-destructive behavior. The description adds useful context about being no-charge and restricted to named official sources, which gives some behavioral detail beyond the schema. However, 'LIMITED' and 'claims' are ambiguous, so the added transparency is modest.

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 (two sentences) and avoids unnecessary words. However, its brevity comes at the cost of clarity, making it cryptic rather than efficiently informative. It is concise but not appropriately sized for the needed information.

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

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

Despite having an output schema and rich annotations, the description fails to explain the core detection behavior or the meaning of 'claims'. It leaves the agent uncertain about what constitutes a material change and how the output should be interpreted. For a tool with no parameters, the description should at least clarify the domain logic.

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 are zero parameters, so the baseline is 4. The description doesn't add parameter-specific meaning but none is needed; the empty schema with additionalProperties true is the only parameter-related concern, but it doesn't need explanation.

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 essentially restates the tool name via the API identifier 'gb.company.material_change.detect.v1' without explaining what 'material change' means or what the tool actually does. It adds a cryptic constraint about 'claims limited to named official sources' but fails to state the core purpose in plain language, making it barely more than a tautology.

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 mention of when to use this tool versus any of the sibling tools such as verify_uk_company_status or run_uk_company_check. The statement about being 'public no-charge' and 'limited to official sources' implies a cost/scope boundary but provides no situational 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, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns a fixed count of outputs (5 commercial solutions and 6 x402 resources), which is useful, but it does not explain the meaning of 'Free:' or any edge-case behavior. This is adequate but not rich.

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

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

The description is very short and scannable, with no wasted sentences. The 'Free:' prefix is cryptic and could be considered unnecessary, but overall the structure is appropriately minimal for a zero-parameter 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?

Although the tool has no parameters and read-only annotations, the description leaves important context unexplained: what 'Free:' means, what 'x402 resources' are, what 'commercial solutions' refers to, and why an agent should invoke this tool. The lack of an output schema further increases the need for descriptive context, which is not provided.

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

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

With zero parameters and 100% schema coverage, the schema imposes no burden, and the description is not expected to explain parameters. The baseline of 4 applies because there are no parameters to document.

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 ('return') and resource ('5 commercial solutions and 6 exact x402 resources'), and this clearly distinguishes it from the many sibling tools focused on UK supplier, payment, and company verification. However, the phrase 'Free:' is ambiguous and 'x402 resources' is unexplained jargon, which slightly reduces clarity.

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 indication of when to use this tool versus the many alternatives. It does not mention conditions, prerequisites, or any explicit routing guidance, so an agent has no basis for selecting it from the sibling 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, destructiveHint=false, and idempotentHint=true, so safety is covered structurally. The description adds useful behavioral context about the response — country-specific coverage, sources, freshness and limitations — and the FEDERAL_ONLY contrast sets expectations about what US federal tools do not assert. But it does not disclose the divergent BR vs GB input behavior or the response shape of rewards in any detail, so transparency is partial.

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 the country-picker/response-preservation sentence is reasonably front-loaded. Structurally it puts the branded 'Global RunOnProof tool' placeholder first, which wastes the opening slot on jargon, and the US federal sentence describes other tools rather than this one. Every line has some intent, but the early keyword placement is not optimal.

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 0% parameter coverage, no output schema, and a large sibling set (verify_company_passport, refresh_company_passport, build_uk_company_capability_passport, run_uk_company_check, etc.), the description is incomplete. It points at the right country dimension and output qualities, but it never explains the BR/GB asymmetry reflected in the oneOf schema, never justifies the BR-only idempotency_key/execution_ids, and never distinguishes this from the many verity/refresh alternatives. The annotations in the schema carry most of the input structure, but the description does not fill the behavioral and navigational 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 0%, so the description must compensate. It only adds meaning to the country parameter — choosing BR or GB changes the country-specific response. It entirely omits the meaning of cnpj, execution_ids, and idempotency_key required in the BR branch, leaving the agent without semantic grounding for those genuinely opaque fields. Minimal compensation for the overall 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 opens with 'Global RunOnProof tool,' which is branded jargon rather than a statement of what the operation accomplishes; an agent unfamiliar with 'RunOnProof' learns nothing concrete from that phrase. The rest hints at the outcome — pick BR or GB and get country-specific coverage, sources, freshness and limitations — but never defines what 'issuing a company passport' means versus verifying, refreshing, or building one. The verb and resource only appear in the tool name itself.

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?

'Choose country from BR, GB' gives an explicit parameter-selection rule, and the US federal note supplies an implicit when-not (US federal-only queries with state good standing / OFAC 50 Percent Rule assertions). However, no sibling alternative is named and no explicit condition such as 'use verify_company_passport to confirm existing status' or 'freshness/refresh to update' is provided. An agent must infer applicability from context rather than being routed.

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 that the tool is 'paid' and limited to 'named official sources,' which are constraints beyond the annotations. However, it does not explain what 'LIMITED' means or what happens when sources are unavailable. Annotations already indicate read-only and idempotent behavior, so no contradiction exists.

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 (two sentences) but not front-loaded with the tool's purpose. It begins with 'Paid x402' which is a pricing detail rather than the core function. The structure is not ideal for quick understanding.

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 (nested object, multiple required parameters, output schema), the description is far too minimal. It fails to explain what 'matching' entails, what 'named official sources' are, or how this tool relates to the broader payment verification workflow.

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 says nothing about parameters. Schema coverage is 75%, with the top-level 'binding_evidence' parameter lacking a description. The description does not compensate for this gap or clarify how parameters should be used together.

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 does not clearly state that this tool matches a UK business payee against official sources. It references 'gb.business_payee.match.v1' and says 'Claims are limited to the named official sources,' but the verb and resource are not explicit. The intended action is only inferable from the tool 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 guidance on when to use this tool versus any of the sibling tools (e.g., verify_uk_bank_account_ownership or match_uk_invoice_to_company). It does not mention any prerequisites, exclusions, or alternative scenarios.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds a small behavioral note that 'claims are limited to the named official sources', which provides some context, but it does not disclose auth, rate limits, response details, or other meaningful traits 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 very short, but it is not well-structured or useful: 'Paid x402 UK tool for gb.invoice.company.match.v1 (AVAILABLE)' is largely endpoint jargon and does not earn its place. It lacks a clear functional summary, so brevity here is under-specification rather than effective 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?

Given the tool has nested objects, an output schema, and many closely related siblings, the description is severely inadequate. It fails to explain what the tool does, how it relates to invoice matching, or what limitations apply, leaving the agent to infer almost everything from the name and 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 description coverage is 80%, so the input schema already documents most parameters. The description itself mentions no parameter meanings, but it does not need to compensate heavily because the schema covers the key fields like company_number, vat_number, and idempotency_key.

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 only says 'Paid x402 UK tool for gb.invoice.company.match.v1', which essentially restates the endpoint/name without a plain-language verb or resource. It never explicitly states that it matches an invoice to a company; 'Claims are limited' is vague and does not clarify the core 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 siblings like match_uk_business_payee or verify_uk_invoice_and_payee. The description mentions availability and paid status but not any trigger conditions, prerequisites, or alternatives.

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

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

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?

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 convey safety (read-only, idempotent, non-destructive). The description adds valuable context beyond annotations: the operation is paid (x402) and incremental. This is meaningful additional disclosure, though it does not explain operational details like what data is refreshed or any side effects.

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 redundant words. It efficiently communicates the core purpose and cost, making every word count. It is appropriately sized for a tool with one 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?

Given the simple schema and annotations, the description is still incomplete. It lacks usage guidance, parameter semantics, and any indication of return values or behavior. The absence of an output schema increases the need for description-level context, which is not provided.

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

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

The schema has one parameter (passport_id) with 0% description coverage, and the tool description does not explain the parameter's meaning or format. The phrase 'passport/decision' hints at what the ID refers to, but it does not explicitly connect the parameter to the description, leaving the agent with minimal semantic information.

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

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

The description states a specific action ('incremental refresh') on a resource ('passport/decision'), which clearly indicates what the tool does. However, it does not distinguish from the sibling 'refresh_company_passport', and 'passport/decision' is somewhat ambiguous, so it misses the top score.

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 'refresh_company_passport' or verification tools. The description does not specify context, prerequisites, or exclusions, leaving the agent without decision support.

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

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

Annotations provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is already clear. The description adds one behavioral detail: 'unchanged valid claims remain reusable,' which is useful. However, the word 'Create' might ambiguously suggest a state change, though annotations indicate it is read-only. This is not a full 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 description is a single sentence that front-loads the main action ('Create a new immutable Passport version') and adds only necessary qualifiers. It is concise, though the use of jargon like 'declared fresh committed execution set' reduces 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?

Given the tool has no output schema and three required parameters, the description should explain what the new version contains, how to construct the inputs, and what 'execution set' refers to. It does not, leaving the agent without enough context to invoke the 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?

The schema has three required parameters (country, passport_id, idempotency_key) with 0% schema description coverage. The description does not explain any of these parameters, nor does 'declared fresh committed execution set' map to any of them. The description fails to help an agent understand what values to provide.

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 a specific action: 'Create a new immutable Passport version' on a company passport. This distinguishes it from siblings like issue_company_passport and verify_passport. However, the term 'declared fresh committed execution set' is technical and may obscure the intended operation.

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

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

The name and description imply this tool is for refreshing a passport by creating a new version, which gives some usage context. Yet there is no explicit guidance on when to use this tool versus alternatives such as 'refresh' or 'issue_company_passport', nor any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and idempotentHint. The description adds meaningful behavioral context by stating 'deterministic replay' and emphasizing that supplier payment is not executed, which clarifies the read-only nature beyond the raw annotations. No contradiction is present.

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 compact and front-loaded, with the core scope stated first and the non-execution clarification in the second sentence. It has no filler, though some terms like 'Paid RunOnProof' and 'Proof Capsule' are jargon-heavy for an agent without prior context.

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 high complexity of a 24-parameter, all-required tool with only 4% schema coverage, the description is too thin. It does not explain the release-payment decision workflow, the meaning of 'deterministic replay' for the caller, or how the many nested objects fit together. The output schema exists, but that does not compensate for the missing input-semantics context for an agent selecting among many sibling 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 only 4%, so the tool description carries the responsibility for explaining 24 required parameters. It mentions concrete artifacts like signed BuyerPaymentMandate and signed Proof Capsule, and gives example values (US, FEDERAL_ONLY, 0.79 USDC, Base), but it does not explain the meaning or purpose of most parameters such as idempotency_key, risk_policy, or evidence_references.

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 specifically identifies a US FEDERAL_ONLY release-payment decision for 0.79 USDC on Base, with signed BuyerPaymentMandate and Proof Capsule, and explicitly states that supplier payment is not executed. This makes the tool's role clear and distinguishes it from payment-execution siblings like authorize_payment.

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

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

The description implies use for US federal-only payment decisions and clarifies that RunOnProof does not execute the supplier payment. However, it does not explicitly state when to prefer this tool over siblings or mention exclusions, leaving the routing decision mostly 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 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 declare readOnly, idempotent, and non-destructive. The description adds useful context about preserving country-specific coverage, sources, freshness, and limitations, plus a warning about US federal scope. This goes beyond annotations but isn't very rich.

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

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

Two sentences, concise and without fluff. However, the first sentence is cryptic ('Global RunOnProof tool') and fails to clearly communicate the tool's purpose within that 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?

The tool has a complex conditional input schema and no output schema. The description doesn't explain per-country requirements, idempotency_key usage, or what the response contains beyond vague coverage/freshness. This is inadequate for reliable invocation.

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

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

Schema description coverage is 0%, and the description gives zero parameter guidance. The schema uses a complex oneOf structure with different required fields for BR vs GB, and the description only says 'Choose country from BR, GB'. This is a major gap requiring the agent to reverse-engineer the schema.

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

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

The name suggests resolving legal entities, but the description only says 'Global RunOnProof tool' without defining the action. It lists supported countries but not the resource type or what 'resolve' means. It also doesn't differentiate from sibling 'resolve_uk_legal_entity'.

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?

Tells the agent to choose country from BR or GB, and notes US federal tools are separate. However, it doesn't explicitly state when to use this versus alternatives, nor does it mention the UK-specific sibling 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?

The description adds minimal behavioral context beyond annotations. It mentions 'Claims are limited to the named official sources,' which hints at data source constraints, but it does not explain what 'claims' refers to, nor does it disclose costs, rate limits, or other operational behaviors. Annotations already cover read-only and idempotent hints, so the description adds little value.

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

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

The description is brief, but its conciseness comes at the cost of clarity. It is structured as a cryptic label containing a version identifier and an ambiguous phrase. While it is not verbose, the content is not self-explanatory, making it less effective than a clearer, slightly longer description would be.

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?

Despite having an output schema and a non-trivial parameter set, the description is far from complete. It does not mention what the tool returns, how to specify a legal entity (company number vs. name), or any usage context. This is a critical gap for a resolution tool that should guide the agent on when and how to 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?

The description does not explain any parameter semantics. Schema descriptions cover company_number and idempotency_key, but postal_code and company_name are left undescribed, and the tool description does not compensate for this gap. With 50% schema coverage, the description should clarify parameter usage but fails to do so.

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 does not clearly state what the tool does. It references 'gb.legal_entity.resolve.v1' and mentions 'Claims are limited to the named official sources,' but lacks a plain-language verb and resource. The tool name 'resolve_uk_legal_entity' provides more clarity than the description itself, which is vague and does not distinguish from siblings like 'resolve_legal_entity'.

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. It only notes that it is a 'Paid x402 UK tool' without stating use cases, prerequisites, or exclusions. No alternatives are mentioned, and no context is provided for choosing this over similar sibling 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 state readOnly, idempotent, and non-destructive. The description adds that the tool is paid and that claims are limited to named official sources, providing useful cost and scope context. 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 with no fluff, but it is cryptic and under-specified. It is concise in size but sacrifices clarity for 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?

Output schema may cover return values, but the description omits the core purpose of the check, the named official sources, and expected input semantics. For a paid tool with many siblings, more contextual detail is needed.

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 covers company_number and idempotency_key, but postal_code and company_name lack descriptions. The tool description does not explain these parameters or the anyOf requirement, leaving ambiguity.

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

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

The description states 'Paid x402 UK tool for gb.solution.company_check.v1 (AVAILABLE)' but does not define what the check does; it essentially restates the tool name with a version string. It also does not distinguish this from sibling tools like verify_uk_company_status.

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 guidance or alternatives are provided. The mention of 'Paid' and '(AVAILABLE)' implies cost and availability, but not selection criteria 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 and idempotentHint=true, and the description adds useful context: it is 'Paid', uses 'x402', and limits claims to official sources. This provides some extra behavioral insight, but important traits like rate limits, authentication requirements, or what 'LIMITED' means operationally are still missing.

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

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

The description is two short sentences with no waste—each sentence adds information and the main subject is front-loaded. However, the extreme brevity contributes to the overall lack of clarity, though the structure itself is efficient.

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

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

Given 8 parameters, nested objects, an output schema, and a complex domain (payment authorization), this description is severely under-specified. It does not explain what the tool returns, how payments are authorized, what the 'LIMITED' mode restricts, or any preconditions required.

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 none of the 8 parameters. With schema description coverage at 50%, the schema partially documents parameters, but the description does not compensate for the remaining gaps or offer any semantic guidance on how to use parameters like supplier, invoice, or vendor_change.

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 the tool as a 'Paid x402 UK tool for gb.solution.payment_authorization.v1 (LIMITED)' and mentions 'named official sources', which gives some domain context. However, it lacks a specific verb (e.g., 'run', 'submit', 'check') and does not clearly distinguish from sibling payment authorization tools, making the exact purpose vague.

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 description notes that it is 'LIMITED' and that claims are restricted to 'named official sources', but it does not explain when this limitation applies or when another payment authorization tool should be selected 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=true, idempotentHint=true, and destructiveHint=false. The description adds that it is a 'Paid x402' tool and that 'Claims are limited to the named official sources,' providing some extra context about cost and claim constraints. There is 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 brief but not effectively concise. The first sentence is a label-like phrase, and the second is an unexplained constraint. Each sentence is vague and under-informative, so the brevity reflects under-specification rather than well-structured completeness.

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

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

Given a 7-parameter tool with a nested object and an output schema, this description is far too sparse. It omits core semantics, usage context, and parameter rationale, making it inadequate for an agent to correctly select and invoke the tool.

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

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

Schema description coverage is only 43%, and the description adds no parameter information. It fails to clarify the meaning of company_number, policy_id, idempotency_key, or the nested payee object, leaving the agent without guidance on how to fill required inputs.

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 UK tool and solution version but lacks a specific verb or outcome. It essentially restates the tool name ('run_uk_supplier_approval' vs. 'gb.solution.supplier_approval.v1') without distinguishing it from many sibling tools like approve_uk_supplier or verify_uk_supplier.

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 any of the 40+ sibling tools. There is no mention of prerequisites, exclusions, or alternative tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false. The description adds that it is a paid tool and that claims are limited to official named sources, which provides some behavioral context (cost and scope). However, it does not describe any other side effects or limitations, so no contradiction and modest added value.

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

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

The description is very short, but the first sentence essentially restates the tool name/version without adding informative content. The second sentence about claims is cryptic and does not earn its place due to lack of clarity. It is under-specified rather than 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?

For a tool with nested objects, an output schema, and multiple sibling tools, the description is grossly incomplete. It does not explain what a 'change' comprises, what 'continuous authorization' means, or how this relates to other UK tools, so the agent has insufficient context 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?

Schema description coverage is only 50% at the top level (the 'change' object lacks a description), and the description adds no parameter-level detail. It does not explain the meaning of 'change', 'idempotency_key', or the nested challenge object, leaving the agent to rely solely on the schema.

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

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

The description does not state a clear verb or resource. It only identifies a service version (gb.solution.vendor_change_continuous_authorization.v1) and notes it is 'LIMITED', leaving the actual action of the tool ambiguous. The phrase 'Claims are limited to the named official sources' hints at verification but does not explain 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?

No guidance is provided for when to use this tool versus alternatives such as run_uk_payment_authorization or authorize_uk_vendor_payment_detail_change. The mention of 'LIMITED' and paid status implies constraints but no concrete selection criteria.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful beyond-annotation context: it is public and no-charge, and claims are limited to named official sources. This tells the agent about cost/access and data source scope, which is valuable behavioral information.

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, concise sentence that packs in the key qualifiers: UK scope, public/no-charge status, API version, availability, and source limitation. No 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 zero-parameter read-only tool with an output schema present, the description covers the important context: what the tool targets (UK restricted business party), access/cost, and source limitations. It does not explain the return shape, but the output schema handles that. It lacks explicit alternative guidance, but overall it is sufficiently complete for the tool's simplicity.

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 in its input schema, so the baseline is 4. The description offers no parameter-specific details, but none are needed in this case.

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 the tool as a UK tool for the restricted_business_party.screen.v1 endpoint and states that claims are limited to named official sources, which implies a screening function. However, it does not explicitly say what the tool does (e.g., screens a business party against UK restricted/sanctions lists) and relies heavily on the tool name. It distinguishes from sibling 'screen_restricted_party' only through the UK qualifier.

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 some context for when to use the tool: it is public, no-charge, and UK-specific. This implies it is for UK restricted-party screening at no cost. However, it does not give explicit exclusions or mention alternatives such as 'screen_restricted_party' for non-UK/global screening.

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=true, idempotent=true, destructive=false; the description adds that the response preserves country-specific coverage, sources, freshness, and limitations, which gives some behavioral context beyond annotations. However, it does not explain read-only rationale, response format, or any caveats about the screening results.

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

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

The description is concise at two sentences and front-loads the tool label, but the second sentence about US federal tools is tangential and does not directly pertain to this tool's usage. It is not verbose, but some content is off-focus.

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 schema is complex with a oneOf branching on country, and there is no output schema. The description does not explain the different input requirements for BR vs GB, nor does it clarify the actual screening purpose, response content, or limitations. This is inadequate for a non-trivial 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 0%, so the description must compensate, but it only repeats 'Choose country from BR, GB' and does not explain the oneOf structure where BR requires CNPJ and idempotency key while GB has no additional fields. No meaning is added for cnpj, aliases, legal_name, or idempotency_key.

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 does not state a verb or resource; 'Global RunOnProof tool' is a vague platform label, and 'screen_restricted_party' is not explained. The only hint is country choice and response qualities, which fails to clarify that this tool screens restricted parties.

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

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

The description implies use for BR/GB countries and suggests US federal tools are separate (FEDERAL_ONLY, no state good standing/OFAC 50% Rule), but does not explicitly say when to use this tool vs siblings or when to avoid it. The guidance is indirect 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?

The annotations declare the tool read-only, idempotent, and non-destructive. The description adds context beyond that: it is public/no-charge, UK-specific, and limited to named official sources. This gives useful behavioral disclosure about the tool's constraints, though it does not specify which official sources or any rate limits.

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

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

The description is only two sentences: it front-loads key qualifiers (public, no-charge, UK) and states the functional scope. Every clause earns its place with no filler or repetition.

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

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

Given the tool's simplicity (no parameters, read-only, output schema exists), the description covers basic constraints. However, it does not clarify what a 'business document' is, what 'claims' means, or which official sources are referenced, leaving some ambiguity for an agent deciding whether this tool fits the task.

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 defines no parameters (parameter count 0, schema description coverage 100%). Per the rubric, a 0-parameter tool gets a baseline of 4. The description does not add parameter details, but none are 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 identifies this as a UK tool for gb.business_document.validate.v1, indicating it validates UK business documents. The name and reference to validation make the purpose clear, though it leans on the version string rather than a direct statement. It provides some distinction from siblings by emphasizing 'LIMITED' and 'official 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?

The description offers no explicit guidance on when to use this tool versus the many sibling verification/validation tools. Phrases like 'Public no-charge' and 'LIMITED' hint at cost and scope, but there is no statement of alternatives, exclusions, or preferred use cases.

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 read-only, idempotent, and non-destructive behavior. The description adds critical behavioral details: 'current immutable' indicates a cached snapshot, and 'without source calls or charge' discloses cost and network behavior. This goes 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?

Single sentence, front-loaded with action and object, no redundant words. Every phrase contributes meaning.

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

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

The description covers the core purpose and key constraints but omits what the verification returns (e.g., boolean, status object) and does not position it against siblings like verify_passport. Given no output schema, this is a notable gap.

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

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

Schema description coverage is 0%, and the description does not mention country or passport_id at all. Although the schema includes an enum for country and a string passport_id, the description adds no semantic value beyond parameter names.

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

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

The description clearly identifies the action (verify) and the specific resource (Company Capability Passport), adding qualifiers like 'current immutable' and 'without source calls or charge' that help distinguish it from generic verify 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?

Clear context is provided: use this tool to verify the current passport without incurring source calls or charges. However, no explicit alternative tools are named, though the description implies a contrast with tools that do perform source calls.

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. The description adds context about the response preserving 'country-specific coverage, sources, freshness and limitations,' which is useful. However, the 'US federal tools' statement is tangential and could confuse the agent about this tool's own limitations. 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 only two sentences, but the second sentence about US federal tools is tangential and not directly relevant to this tool's operation. The front-loading is okay but not efficient; it does not clearly introduce the tool's purpose.

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

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

The tool has a complex oneOf schema with two country-specific variants, yet the description fails to explain the required parameters (cnpj vs. company_number) or the idempotency_key requirement. It mentions response characteristics but does not describe the return format or coverage details, leaving significant gaps for an agent to operate 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%, and the description provides no explanation of parameters such as cnpj, company_number, or idempotency_key. It only says 'Choose country from BR, GB,' leaving the agent to infer the required identifiers from the schema's oneOf branches. The description adds no value beyond what the schema constrains.

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 this as a 'Global RunOnProof tool' and lists countries BR and GB, but it does not explicitly state that it verifies company status; the verb 'verify' is only implied by the tool name. It distinguishes itself from US federal tools but is vague about its core function.

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

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

The description implies this tool should be used for BR or GB, and contrasts with US federal tools ('never assert state good standing'). However, it does not explicitly state when to use this vs. the sibling verify_uk_company_status or other verification tools, and provides no clear 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, implying a safe, read-like operation. The description adds that US tools are 'FEDERAL_ONLY and never assert state good standing or the OFAC 50 Percent Rule', which is useful behavioral context. However, it does not explain the 'RunOnProof' concept, rate limits, latency, or whether the tool returns structured results or raw data. The contradiction comment is false—no annotation contradiction found.

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

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

The description is two sentences and relatively brief, but the first sentence is opaque ('Global RunOnProof tool') and wastes space. It could be restructured to front-load the core purpose and add specific parameter context without becoming verbose.

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 zero schema description coverage, no output schema, a complex oneOf schema, and a large sibling set with overlapping tools (e.g., verify_uk_invoice_and_payee), the description is seriously incomplete. It does not specify what the tool returns, how to interpret the three distinct country-specific parameter sets, or how to handle errors. The description fails to equip an agent to use this tool correctly across all supported countries.

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

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

Schema description coverage is 0%, and the description does not explain any parameters beyond mentioning country choices. The oneOf branches are complex (e.g., BR requires cnpj, GB requires company_number, US requires policy_id and schema_version), yet the description offers no parameter guidance. For a tool with deeply nested required fields, this is inadequate.

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 starts with 'Global RunOnProof tool' which is cryptic and does not clearly state the tool's verb (verify) or resource (invoice payee). It mentions country coverage but fails to define the core purpose—verifying that a payee matches an invoice. It does not distinguish this tool from sibling tools like verify_uk_invoice_and_payee, which overlaps significantly for the GB variant.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, workflow position, exclusion criteria, or country-specific routing logic despite the complex oneOf schema. The mention of 'Global RunOnProof tool' is unhelpful jargon, leaving the agent without clear selection criteria.

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

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

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds meaningful context: 'SOURCE_CONDITIONED' and 'Claims are limited to the named official sources' clarify that results depend on official sources and are scoped. It also discloses the tool is public and no-charge. No contradiction with annotations; this exceeds the baseline by providing behavioral nuance beyond the structured 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 two short sentences, front-loaded with the key facts (public, no-charge, UK, purpose). It is concise with no filler. However, the technical identifier 'gb.bank_account_ownership.verify.v1' and 'SOURCE_CONDITIONED' introduce jargon that may reduce clarity for some agents, but overall it remains efficient.

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

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

For a tool with no parameters, rich annotations, and an output schema, the description covers the essential traits: public, no-charge, UK scope, source-conditioned claims. It does not explain what 'SOURCE_CONDITIONED' means in detail, but the explicit 'Claims are limited to the named official sources' provides sufficient context. Given the output schema exists, return value details are not required.

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 0 parameters, so the schema provides no parameter details and the description does not need to explain any. Baseline for 0 params is 4. The description adds no parameter semantics, but none are needed. The schema's additionalProperties: true suggests arbitrary properties might be accepted, but the description does not clarify; this is a minor gap but not critical given zero documented parameters.

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

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

The description identifies the resource (UK bank account ownership) and the action (verify via the API endpoint gb.bank_account_ownership.verify.v1). It adds scope (UK, public no-charge, source-conditioned) and distinguishes from sibling verification tools by name and resource. However, it relies on the tool name for the primary verb; the description itself does not explicitly state 'verifies bank account ownership' in plain language.

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 from the tool name and the UK-specific context; the description mentions 'Public no-charge UK tool' which suggests suitability for cost-sensitive UK checks. However, there is no explicit when-to-use or when-not-to-use guidance, nor are alternative sibling tools mentioned. The guidance is mostly implicit.

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, so the description's addition of 'Public no-charge' and 'Claims are limited to the named official sources' provides some extra context about access and scope. However, it doesn't describe the actual verification behavior or output details, leaving room for improvement.

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 plus a short clause, so it is concise in length. However, the first sentence focuses on the version reference rather than the tool's function, making it less effective than it could be. It is not misleading, but the wording is awkward.

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 presence of an output schema means return values need not be explained, and zero params simplify input. Yet the core purpose is still ambiguous, which is a significant gap for an AI agent trying to decide whether to invoke this tool. The description does not sufficiently clarify what 'verify' entails or what limitations apply.

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

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

The tool has zero parameters, so the description carries no burden to explain parameter semantics. Baseline 4 is appropriate; the description adds nothing about inputs, but there is nothing to add given the simple 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 references the tool's version string and says it's for 'gb.beneficial_ownership_control.verify.v1', but it never explicitly states that the tool verifies beneficial ownership control. This is essentially a restatement of the tool name without adding functional clarity.

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 the many sibling verification tools (e.g., verify_uk_company_status, verify_uk_business_licence). It mentions 'LIMITED' but does not explain under what circumstances this tool is appropriate or preferred.

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. The description adds 'SOURCE_CONDITIONED' and 'Claims are limited to the named official sources', which informs the agent that output is strictly constrained to authoritative sources and not open-world. This is useful extra context 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 entire description is one sentence, front-loaded with key attributes (public, no-charge, UK tool), and contains no redundant words. Every clause contributes meaningful information, making it highly concise and well-structured.

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

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

Given the tool has no parameters, an output schema exists, and annotations cover safety, the description is largely complete. It adds cost, access, and source-conditioning information. However, it does not explain what 'SOURCE_CONDITIONED' means or list the specific official sources, which could confuse an agent without external knowledge.

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 empty (additionalProperties true), so schema coverage is trivially 100%. Per the rubric, 0 parameters earns a baseline of 4. The description adds no parameter details because none exist.

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 refers to the endpoint gb.business_licence.verify.v1 and names it a 'UK tool', implying the verification of UK business licences, but it never explicitly states 'verifies a UK business licence'. This is clearer than a tautology but still relies on the tool name and endpoint reference for meaning.

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 sibling verification tools such as verify_uk_company_status or verify_uk_tax_registration. The description mentions it is public and free but gives no conditions, prerequisites, or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it is 'Paid' and that 'Claims are limited to the named official sources', which is useful behavioral context about scope and cost. However, it does not disclose failure modes, output shape, or latency.

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—two short sentences. It front-loads the tool's paid nature and service identifier. The phrase 'x402' and '(AVAILABLE)' are somewhat cryptic, but the overall size is minimal and every sentence adds some information.

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

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

Given the tool has an output schema, the description need not explain return values. It covers cost and source limitation, but in the context of many sibling verification tools, it lacks usage context and clear differentiation. It is minimally complete but not rich.

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 both parameters (company_number, idempotency_key) have detailed descriptions. The tool description adds no extra parameter semantics, so the schema carries the burden. 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 references 'gb.company.legal_status.verify.v1' and the tool name 'verify_uk_company_status', which together imply verifying UK company legal status. However, it never directly states 'verifies UK company status' in plain language, relying on the service identifier. It does distinguish somewhat from siblings like verify_uk_business_licence or verify_uk_tax_registration, but the wording is cryptic.

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 the many sibling verification tools. The description mentions 'Paid' and 'Claims are limited to the named official sources' but does not explain prerequisites, alternatives, or contexts where this should be preferred.

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 read-only, idempotent, and non-destructive behavior. The description adds that the tool is paid and limited to named official sources, which provides useful context about cost and scope. However, it does not elaborate on what claims are made or how limitations affect 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 a single short sentence, which is efficient but lacks substance. It conveys some metadata (paid, version, limited) but is closer to under-specification than effective 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?

Given the complex nested schema and the need for usage context, this description is severely incomplete. It doesn't explain the verification workflow, what 'claims' means, or how the tool relates to 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?

The description contains no parameter information. With only 33% schema description coverage, the description does not clarify any parameters, including nested objects like payee and invoice, leaving the agent without additional guidance.

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 lacks a clear statement of what the tool does. It references a solution identifier and mentions limitations, but does not explicitly say it verifies UK invoices and payees. The name implies it, but the description itself is vague.

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 the many sibling verification tools. There are no exclusions, prerequisites, or alternative suggestions.

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 valuable behavioral context beyond the annotations: it discloses the tool is free, public, UK-specific, and 'SOURCE_CONDITIONED' with claims limited to named official sources. This explains the tool's constraints without contradicting the readOnly, idempotent, and non-destructive hints. It does not detail failure modes or source behavior, but the annotation coverage lowers the burden.

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, concise sentence that front-loads key facts: public, no-charge, UK scope. Every clause earns its place, and there is no redundant information. It is appropriately sized for the tool's simplicity.

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 zero-parameter schema, existing output schema, and annotations, the description provides sufficient context for basic usage. It clarifies source conditioning and official-source limitations, which are important for trust. It lacks explicit instructions on input handling, but the simplicity of the tool and output schema compensate. It could be more complete with an explicit 'when to use' statement, but overall it is adequate.

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

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

The tool has zero parameters in the schema, and the description adds no parameter details. This aligns with the baseline of 4 for zero-param tools. The schema allows additionalProperties, so input might be passed via context or arbitrary fields, but with no explicit parameters and 100% schema coverage, the description doesn't need to compensate.

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 tool name clearly indicates verification of UK tax registration, and the description references the specific operation 'gb.tax_registration.verify.v1'. This distinguishes it from sibling verification tools like verify_uk_company_status or verify_uk_business_licence. However, the description doesn't restate the purpose in plain language, relying on the name and version string.

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 guidance is given on when to use this tool versus other verification tools. It states it is 'Public no-charge UK tool' but does not mention when to prefer it over siblings or exclusions. The context of UK tax registration is implicit from the name, but the description lacks direct usage direction.

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