Provider Trust — Verify a Source or Provider

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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior, so the description's additional 'privacy-safe' and 'historical' context earns some credit. However, it does not explain what data is consulted, how results are scoped, or what privacy guarantees mean in practice.

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

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

One short sentence with no filler and the key behavior front-loaded. It is concise, though it could have used an extra clause to explain the hours parameter or expected result.

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

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

With no output schema and an openWorldHint, the description leaves key invocation context unstated: what 'trust evidence' means, how the response is shaped, and what role hours plays. The annotations cover side-effect safety, but not enough for a confident call beyond the default arguments.

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, hours, with 0% description coverage, and the description never mentions it. There is no explanation of how hours controls the lookup window or how it relates to 'historical', so the description fails to compensate for the schema 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 names a specific action and resource: it checks historical trust evidence, which distinguishes it from sibling tools that check identity, payment, or status. 'Privacy-safe' adds a qualifier, though 'trust evidence' remains somewhat generic.

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 about when to use this tool instead of check_identity, check_status, compare_providers, or verify_provider. The historical aspect is implied, but no explicit criteria or exclusions are given.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds the 'live' aspect, suggesting real-time or current data, but does not disclose what is returned, whether results vary, or any other behavioral details. 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?

A single sentence with no filler or repetition. The core action and subject are front-loaded, making it easy to parse quickly.

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

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

The tool is simple (no parameters) and the annotations cover safety and idempotency, but the description does not explain the return value or how this differs from verify_provider and other check_* siblings. It provides the core purpose but leaves contextual 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?

The tool has zero parameters and schema coverage is 100%, so the schema fully documents the input surface. The baseline of 4 applies; the description does not need to add parameter-level detail.

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 clear action ('Check') and a specific resource ('live provider identity evidence'). It is understandable, but it does not differentiate from the sibling verify_provider, and 'identity evidence' is somewhat 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 about when to use this tool versus alternatives like verify_provider or check_status. The description implies a read-only identity check but provides no context, prerequisites, or exclusions.

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

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

Annotations already declare the operation as read-only, idempotent, non-destructive, and open-world. The description adds useful behavioral context by emphasizing 'live', indicating that results reflect current external contract state and readiness rather than cached or static data. It does not contradict the annotations and gives the agent a better sense of what the tool actually does.

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, focused sentence with no filler. It front-loads the core behavior ('Check live x402 contract') and then lists the key result areas concisely, making it easy for an agent to parse quickly.

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

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

For a no-input, read-only tool, the description covers the main purpose and key evidence categories. It could add more detail about return format or what 'readiness' specifically entails, but given the low complexity and strong annotations, it is nearly complete.

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

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

The input schema has zero parameters, so there is no parameter documentation burden on the description. With 100% schema coverage and no required inputs, the description has nothing to add about parameter semantics; the baseline of 4 applies.

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

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

The description names a specific verb ('check') and a specific resource/domain ('live x402 contract, readiness, and settlement evidence'), which clearly distinguishes it from sibling tools like check_history, check_status, and verify_provider. It goes beyond the tautological title 'Check Payment' and tells the agent exactly what aspect of payment is being inspected.

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

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

The description implies when to use the tool: whenever the agent needs live payment contract, readiness, or settlement evidence. However, it does not explicitly state when not to use it or point to a specific alternative, so the usage guidance is implied rather than explicit.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description doesn't need to repeat safety traits. It adds a small behavioral nuance with 'authoritative', implying this hits the source of truth rather than a cached view, but gives no further details such as response behavior or potential 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 a single sentence with no waste. Every word earns its place, and the core action and target are front-loaded.

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

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

The tool is simple, parameterless, and protected by annotations, but there is no output schema and the description gives no hint of what a status response looks like. An agent knows what the tool does but gets little context about the meaning or format of the status result, leaving some ambiguity given the sibling health/identity/payment checks.

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 schema coverage is trivially 100%. With no parameters to document, a baseline of 4 is appropriate; the description doesn't need to explain parameter syntax or semantics.

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

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

The description uses a specific verb ('Check') and resource ('authoritative backend status'), clearly indicating this tool checks overall backend status. It distinguishes from sibling tools like check_history and check_identity by using the qualifier 'authoritative backend status', though it doesn't explicitly name any sibling.

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 like check_history, check_identity, or verify_provider. The word 'authoritative' hints that this is the canonical status check, but no explicit when-to-use or when-not-to-use conditions 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 convey read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context by explicitly stating the output will not fabricate a winner or composite score, which informs the agent's expectations 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 one concise, front-loaded sentence with no filler. It states the action, object, and a key behavioral constraint efficiently.

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

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

The tool is simple, has one parameter, and annotations cover safety and idempotency. However, the description omits the exact meaning of targets and does not describe what the comparison output looks like, so an agent may need additional context to invoke it confidently.

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

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

The only parameter, targets, has no schema description coverage, so the description carries the full burden of explaining it. 'Compare provider evidence' hints that targets refer to providers, but it does not clarify what form targets should take (names, IDs, URLs), 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 uses a specific verb and resource: 'compare provider evidence side by side.' It clearly distinguishes this tool from the sibling verification/checking tools by emphasizing side-by-side comparison, and the phrase 'without a fabricated winner or composite score' adds useful non-evaluative intent.

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

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

The description implies the tool is for comparing provider evidence side by side, but it does not explicitly say when to use it over verify_provider or the check_* tools, nor does it mention any exclusions. Usage is inferable but not stated.

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

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

The annotations already indicate readOnly, idempotent, openWorld, and non-destructive. The description adds a useful behavioral nuance beyond those flags: 'Live evidence only; unknown stays unknown.' This tells the agent the tool does not fall back to stale data or fabricate a result, which is valuable behavioral context for a verification tool.

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

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

Two short sentences carry the full meaning with no filler. The primary instruction is front-loaded, and the behavioral constraint ('Live evidence only; unknown stays unknown') is tightly packed and memorable.

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

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

The tool is simple and its annotations cover safety and world semantics, but with no output schema and no parameter documentation, the description should explain what the result looks like or what 'verify' returns. The 'unknown stays unknown' line hints at the outcome, but the agent still lacks a clear picture of the return value and target format.

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 only has one parameter, target, but schema description coverage is 0% and the description does not explain what 'target' should contain (e.g., an address, ID, URL, or name). The tool name and description imply provider identification, but the agent is left to guess the exact format and semantics.

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

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

The description clearly states a specific action ('verify') and a resource ('a provider'), and adds a timing constraint ('before using it'). It does not explicitly name or contrast sibling tools, so it misses the top tier for sibling differentiation, but the purpose is unmistakable.

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?

'Verify a provider before using it' gives an explicit context for when to call this tool. It does not enumerate when not to use it or name alternatives like check_history or check_status, but the 'before using it' guidance is a clear enough trigger for an agent.

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