Regent Protocol

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description meaningfully extends that with the gating/escalation model, the retry-with-same-idempotency_key execution rule, and the assurance that the credential never reaches the agent. It stops short of describing what a successful response contains or how destructive operations behave against existing remote state.

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

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

Two tight sentences, front-loaded with the action and target, followed by the operational caveats. No filler; the escalation and idempotency details are load-bearing rather than padding.

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

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

With no output schema, the description still covers the key outcome an agent needs (ESCALATION_REQUIRED parking and how to execute after approval). For a generic proxy over arbitrary paths, the behavioral picture is largely complete, though response shape and failure modes beyond escalation are unstated.

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 86%, so the schema already explains path, body, facts, intent, user_token, and idempotency_key. The description reinforces idempotency_key's retry role but adds no new meaning for the remaining parameters, so the baseline of 3 applies.

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

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

The description states a specific verb set (create, change, pay) against a named resource (https://api.agentmail.to via Regent) and enumerates the HTTP methods involved. The '· write' title and method list make it distinguishable from the agentmail_read sibling, though the description never names that alternative explicitly.

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

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

It gives real usage context: calls are gated under a spend limit, unapproved payments are parked as ESCALATION_REQUIRED, and retries must reuse the same idempotency_key. However, it never says when to choose this tool over siblings like pay, stripe_demo, or agentmail_read, so routing is left to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely new behavior: Regent evaluates the policy, injects the credential, and the key never reaches the agent. It still omits what happens on a policy denial or how the call is authenticated for the user_token path.

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?

Three front-loaded sentences with no filler: the target and method constraint come first, then credential handling, then the safety guarantee. 'Nothing is changed and no money moves' partly restates the readOnly annotation, a minor redundancy.

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

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

Covers the safety profile, credential flow, and method limits for a 5-parameter tool with a nested facts object and no output schema (so return values need not be explained). Gaps are minor: no guidance on required 'path' format beyond the schema, or on failure when the policy denies the call.

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

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

Schema description coverage is 80%, so the schema already documents path, facts, intent, and user_token; the description adds only indirect meaning ('policy' hints at facts, and intent's audit role is implied but not restated). Baseline 3 is appropriate since the schema carries the parameter semantics.

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

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

States a specific verb (read) and specific resource (https://api.agentmail.to), and pins the allowed methods to GET/HEAD/OPTIONS, which the _read naming pairs with the plain `agentmail` sibling as the write path. It does not explicitly name that sibling, so the differentiation is implicit rather than stated.

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

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

Clear context for use: read-only access routed through Regent, method-limited to GET/HEAD/OPTIONS, with 'Nothing is changed and no money moves' confirming the scope. There is no explicit when-not rule or named alternative for cases needing a write, so it stops short of a 5.

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 establish readOnlyHint/idempotentHint/non-destructive, but the description adds the state machine that governs this tool and its consequences — most notably that a repeat call with the same idempotency_key executes the purchase, which is exactly the side-effect boundary an agent could otherwise get wrong.

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?

Three sentences, zero filler, and the precondition is front-loaded before the outcome-to-action mapping. The arrow structure makes the decision tree scannable at a glance.

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 one parameter, no output schema, and full schema coverage, the description supplies exactly what is missing: the three possible return states and the required follow-up for each. Nothing an agent needs to call and act on this tool correctly is absent.

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

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

Schema description coverage is 100% and there is only one parameter (ref), whose meaning ('escalation ref from the refusal, esc_…') is already documented in the schema. The description mentions 'the same idempotency_key' and 'the same id', which refer to the execution call rather than this tool's parameter, adding no real meaning beyond the schema. Baseline 3 applies.

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

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

The description states a specific purpose: reporting whether a person approved a parked payment after an ESCALATION_REQUIRED. It clearly separates this status-check from the sibling execution tool (pay) by describing what to do once approval is granted. It does not name a sibling tool explicitly, so it stops short of a 5.

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

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

The trigger condition is explicit (after ESCALATION_REQUIRED), and each possible outcome carries an unambiguous next action: 'approved' → repeat the call with the same idempotency_key, 'denied' → tell the person and stop, 'pending' → wait and do not repeat. This is a complete when-to-use and what-to-do-next contract.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value by bounding the response to four states and noting that an approved result carries a mandate id, but it says nothing about lookup failures, unknown ids, or auth needs.

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

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

A single front-loaded clause listing the possible outcomes, with no filler. Slightly terse for a fragment, but every word carries information.

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

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

With no output schema, the description usefully enumerates the returned states, but it omits the input's origin, error behavior for invalid or unknown request ids, and how this differs from approval_status. Adequate for a simple lookup, not fully self-contained.

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

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

There is one required parameter with 0% schema description coverage, and the description never mentions request_id or says where the caller obtains it (presumably from request_budget). The only id referenced (mandate id) is an output, not the input, so the description fails to compensate for the coverage 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?

Names the resource (budget request), the operation implied (checking its standing), and enumerates the four possible states, so an agent knows exactly what comes back. It stops short of distinguishing itself from the similar-sounding sibling approval_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 when-to-use guidance, no prerequisites, and no mention of alternatives such as approval_status or how this relates to request_budget. The agent must infer that this is a follow-up call after requesting a budget.

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

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

Annotations already cover the read-only/idempotent/non-destructive profile, so the bar is lower. The description adds genuine behavioral context beyond them: it discloses a second return signal (whether a card is already stored) and a security/PII rule about never soliciting card details in chat.

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 first sentence is a run-on that buries the action behind a descriptive clause and an extraneous purpose aside ('so you can shop at real stores within your budget'). The operational instructions are present but not ideally 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?

With no output schema, the description steps in by stating both what is returned (the link) and the status flag, which is enough for an agent to call it correctly. It is essentially complete for a zero-parameter link-retrieval 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 takes zero parameters and schema coverage is 100% (vacuously), so there is nothing for the description to compensate for. Baseline 4 applies with no parameter 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 makes clear this returns the owner's Agentcard Vault page link and also reports whether a card is already stored. However, it opens with a noun phrase ('The owner's own page...') that reads as a resource description rather than a verb, and it never names or contrasts itself with payment siblings like stripe_demo or pay.

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

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

It gives explicit direction on when to use it ('Give the person this link') and a hard exclusion ('never ask for card details in the chat'). It stops short of naming alternative tools for related flows, so it is clear context but not full when/when-not/alternatives 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?

Goes well beyond the annotations (readOnly/destructive/openWorld/idempotent) by disclosing the gating model: every call is a spend-limited decision, unapproved payments are parked with ESCALATION_REQUIRED, and they execute only on retry with the same idempotency_key. It also states the credential never reaches the agent, covering the auth surface that annotations omit.

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?

Three dense sentences, front-loaded with the verb/resource and target URL, then the behavioral contract. Every sentence carries information, though the middle sentence packs gating, escalation, and idempotency into one clause chain.

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

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

No output schema exists, so the description carries return-shape burden, and it does name the key terminal state (ESCALATION_REQUIRED) and the credential-handling behavior. It does not describe the general success/failure response shape or other error conditions, leaving a modest gap for a 7-parameter write 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 coverage is 86%, so the schema already documents parameters like idempotency_key, intent, and user_token. The description restates the idempotency_key retry semantics rather than adding new meaning, and says nothing about path, body, facts, or method beyond the method list already in the schema. Baseline 3 applies.

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

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

States specific write verbs (create, change, pay) and the resource (the counterparty API reached through Regent) with the exact HTTP methods it proxies. It reads clearly as the write counterpart to counterparty_check_read, but it never names that sibling or explicitly draws the read/write boundary, so differentiation is inferred rather than stated.

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

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

Usage is implied: write operations go through this tool and are gated under the agent's spend limit, with payments escalating to the owner. There is no explicit when-to-use/when-not guidance, no mention of when to prefer counterparty_check_read, pay, or budget_request_status, and no prerequisites stated for the caller.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value beyond them: Regent performs policy checks and injects the credential so 'the key never reaches the agent,' which is meaningful auth-flow context. It stops short of describing rate limits, error behavior, or policy-denial handling.

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?

Three short sentences, front-loaded with what the tool reads and the allowed methods, with zero filler. Every sentence carries distinct information (endpoint, credential handling, safety assurance).

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

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

For a read-only wrapper with full annotation coverage and no output schema, this explains the endpoint, method restrictions, and credential model adequately. Slightly incomplete on what a response or a policy rejection looks like, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 80%, so the schema largely documents path, facts, intent, method, and user_token. The description only reinforces the method enum restriction (GET, HEAD, OPTIONS) and adds nothing about fact shape or token usage, so baseline 3 applies.

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

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

States a specific verb and resource ('Read from http://demo-counterparty-api:8000 through Regent'), constrained to GET/HEAD/OPTIONS. The closing line 'Nothing is changed and no money moves' implicitly contrasts it with its write sibling, though counterparty_check is never named outright.

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 method constraint and read-only framing imply when this tool is appropriate, and the 'nothing changed' line hints the write variant exists. However, it never explicitly says when to call this versus counterparty_check, so selection still requires 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?

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing the escalation workflow: parked calls execute on retry with the same idempotency_key, and the credential never reaches the agent. These are non-obvious behavioral traits an agent needs to plan around.

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?

Three dense sentences, front-loaded with the operation and base URL, then escalation behavior. No filler, though the URL and method enumeration make the opening slightly heavier than necessary.

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

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

For a mutating proxy with no output schema and an escalation path, the description covers the key mechanics (gating, parking, retry, credential isolation). Minor gaps remain around what facts are policy-keyed on and error surfaces, but annotations and schema carry the safety profile.

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 86%, so the schema already documents path, body, facts, intent, user_token and idempotency_key. The description reinforces idempotency_key retry semantics but adds little beyond what the schema fields already convey, so the baseline 3 applies.

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

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

States a specific verb set (create, change, pay) against a named resource (gigtickets.aqylorda.kz/api) and the mutation methods it accepts. It is clearly the write counterpart to the sibling gigtickets_read, though the description is deliberately generic about which sub-resources are touched.

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?

Explains the gating context (calls count against the spend limit, unapproved payments are parked as ESCALATION_REQUIRED), which implies when calls will succeed versus be deferred. It never explicitly routes the agent to gigtickets_read for non-mutating work or states what must not be done here.

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 readOnlyHint, idempotentHint, destructiveHint and openWorldHint, so the bar is lower, yet the description adds real context: Regent performs a policy check and injects the credential, and the key never reaches the agent. 'Nothing is changed and no money moves' reinforces the safety profile in terms the payment-oriented surrounding toolset cares about. It stops short of explaining policy-denial or error 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?

Two tight sentences, front-loaded with the action and the method constraint before the safety guarantees. Both sentences carry weight, though 'nothing is changed and no money moves' slightly overlaps the destructiveHint/readOnlyHint annotations.

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

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

For a gateway/read tool with no output schema, the description covers the target, the method restriction and the credential-handling model, which is what an agent needs to call it safely. It could say more about how the 'path' is composed or what happens when policy denies a request.

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% with 5 parameters, so the schema already documents path, facts, intent, method and user_token adequately. The description adds nothing about parameter usage, so the baseline 3 for high coverage is appropriate.

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

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

States a specific verb (read) and resource (the gigtickets.aqylorda.kz API), plus the allowed HTTP methods, so an agent knows exactly what this does. The name 'gigtickets_read' versus the 'gigtickets' sibling implies a read/write split, but the description never names the write sibling or explicitly says how they differ.

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 parenthetical '(GET, HEAD or OPTIONS only)' implicitly tells the agent this tool cannot perform writes, which is useful routing guidance. However, there is no explicit statement of when to prefer this over 'gigtickets' or the other read siblings, and no prerequisites beyond the implied read-only nature.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses the escalation flow: unapproved payments are parked with ESCALATION_REQUIRED and execute on retry with the same idempotency_key. It also states the credential never reaches the agent, which is real auth context. It stops short of saying what state a parked/mutated resource leaves behind, but the disclosure is well above the annotation baseline.

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?

Three tightly packed sentences with zero filler, front-loading the operation and endpoint before the escalation semantics. Slightly dense in the second sentence but every clause 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 7-parameter write tool with no output schema, the description covers the critical behavioral surfaces: spend gating, pre-approval parking, retry idempotency, and credential isolation. It omits what a successful response returns and which sibling to poll for approval status, so it is strong but not fully closed.

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 86%, so the schema already documents body, path, facts, intent, method, user_token, and idempotency_key. The description reinforces only the idempotency_key retry semantics, which the schema also states, adding no new per-parameter meaning. Baseline 3 is appropriate where the schema does the heavy lifting.

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

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

The description states concrete verbs (create, change, pay) and the exact target endpoint (frankfurter.dev/v1/latest), with the HTTP methods enumerated. The opaque tool name and URL-as-resource mean an agent must read the description to know what is being written to, but the write/read split against lst-637408c1b10f_read is inferable from the '· write' title. Clear purpose, though not differentiated from money-flow siblings like pay.

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 through the gated-decision/spend-limit framing, which tells the agent this is the write path for a spend-controlled API. However, it never says when to prefer this over sibling write tools such as pay, stripe_demo, or lst-a23997bcffc7, nor when to consult approval_status. The alternative-selection guidance is left to inference.

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

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

Annotations already establish readOnlyHint, idempotentHint and destructiveHint=false, so the bar is lower. The description still adds genuine context beyond them: Regent checks policy and injects the credential so the key never reaches the agent, and the explicit 'nothing is changed / no money moves' reassurance for what is an FX-rate endpoint.

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

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

Two tight sentences, front-loaded with the concrete endpoint and method restriction, with no filler. The closing 'Nothing is changed and no money moves' slightly restates destructiveHint=false but reads as deliberate assurance rather than padding.

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

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

For a 5-parameter proxy read tool with no output schema, the description covers the essential behavior (credential injection, safety, allowed methods) and the base URL needed to interpret the path parameter. Parameter semantics for facts/intent/user_token rest on the schema, which is acceptable at 80% coverage.

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 schema already documents path, facts, intent, method and user_token. The description only indirectly explains path by stating the base URL; it adds no format or syntax detail beyond the structured fields, so the baseline 3 applies.

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

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

The description states a specific verb (Read) and resource (the frankfurter.dev /v1/latest endpoint) proxied through Regent, and constrains the allowed methods to GET/HEAD/OPTIONS. It is clear this is the read-only variant of the paired sibling, though it never explicitly names lst-637408c1b10f to draw the contrast.

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 'GET, HEAD or OPTIONS only' clause is an implicit usage constraint telling the agent what class of operation is permitted. However, there is no explicit when-to-use guidance, no prerequisites, and no routing to alternatives such as the non-_read sibling or the other lst-* 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?

Adds substantial behavior beyond the annotations: gating under the agent's spend limit, the ESCALATION_REQUIRED parking flow, the requirement to retry with the same idempotency_key after approval, and the security note that the credential never reaches the agent. It does not elaborate on what the destructiveHint=true actually destroys or what a successful response contains, so not a full 5.

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

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

Two dense sentences, front-loaded with the operation and host, then the escalation constraint. Every clause carries information, though the embedded idempotency detail slightly duplicates the schema.

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

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

Covers the important lifecycle (gate, escalate, retry) for a 7-parameter destructive write tool, but leaves the 'facts' policy-keying object, method-selection guidance, and return behavior unexplained, and there is no output schema to compensate.

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 86%, so the schema already carries most parameter meaning, including the idempotency_key retry note that the description largely repeats. The description adds no field-level syntax or format guidance beyond the schema, which is the expected baseline at high coverage.

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

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

States a specific set of verbs (create/change/pay) and the HTTP methods (POST, PUT, PATCH, DELETE) against a named base URL through Regent, so the write scope is clear even though the tool name is an opaque hash. It does not explicitly differentiate itself from the read sibling lst-a23997bcffc7_read or the other payment siblings, so it stops short of a 5.

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

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

The description explains the escalation/approval mechanics but gives no when-to-use guidance and never names alternatives such as pay, stripe_demo, or lst-637408c1b10f, all of which appear to overlap in the payment space. An agent has to guess when this generic write proxy is preferred over the dedicated payment 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 and destructiveHint=false, so the safety profile is covered. The description earns credit for adding genuinely new context: policy evaluation happens inside Regent, the credential is injected proxy-side and never exposed to the agent, and no side effects or fund movement occur.

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?

Three short sentences, zero padding, with the target URL and allowed methods front-loaded ahead of the credential-handling and no-side-effect notes.

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 5-parameter proxy tool with no output schema, the description covers the transport, allowed methods, credential flow and side-effect profile adequately. It omits error/authorization-failure behavior and the meaning of the nested 'facts' object, but the schema carries most of that.

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 parameters are largely self-documented and the baseline is 3. The description only restates the method allowance (already an enum in the schema) and adds nothing about 'facts', 'intent', or 'user_token' 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?

States a specific verb (read) and an explicit resource (the koleso.kz API via Regent), and constrains the operation to GET/HEAD/OPTIONS. An agent can tell it apart from the non-'_read' sibling lst-a23997bcffc7, though no sibling is named or contrasted directly.

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 read-only framing and method whitelist imply when the tool applies, but there is no explicit statement of when to reach for this versus lst-a23997bcffc7 or the other *_read siblings, nor any stated prerequisites for supplying facts/user_token.

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 the description reinforces this with 'Nothing changes.' Beyond that, it adds genuinely useful behavioral context not in the annotations: the remaining amount is 'a portion, not the ceiling' and the output may include a pending budget request and a stored-card flag. It stops short of describing format or freshness of the data.

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

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

It is one dense enumerating sentence followed by two short directive/behavioral sentences, so the critical 'what you get' content is front-loaded. The enumeration is long but each clause maps to a distinct output field, so the length largely 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?

With no output schema and no parameters, the description must carry the whole burden of communicating return values, and it does: it walks through mode, currency, per-currency remaining budgets, seller caps, pending requests, thresholds, and card storage. An agent knows exactly what it will learn and why to call 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 tool takes zero parameters, which per the rubric sets the baseline at 4. There is no parameter surface for the description to clarify further, so it cannot score higher on this dimension.

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 specific resource (this agent's own spending situation) and enumerates its scope in detail: sandbox/live mode, home currency, per-currency budgets and remaining amounts, seller caps, pending request, approval threshold, stored card. This is far more specific than a status tool that shares the budget/approval space, letting an agent distinguish it from siblings like budget_request_status and approval_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?

It gives explicit trigger conditions — 'Call it before shopping or when a purchase was refused' — and states the goal (explain and pick the right currency or seller). It does not, however, explicitly rule out or name the sibling tools (budget_request_status, approval_status) that an agent might otherwise reach for.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that: the four gates (identity, mandate limit, behavior policy, risk) and the outcome states ('pending' settled via webhook, 'denied', 'escalated'). It stops short of spelling out irreversibility or the retry semantics the idempotency_key param implies.

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 dense, front-loaded sentences; the core action leads and the gating/return-state detail follows. The telegraphic gate list ('identity · mandate limit · behavior policy · risk') is compact and earns its place.

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

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

With no output schema, the description appropriately names the three possible return states and the webhook settlement path, and all 7 params are documented. Complete enough for an agent to call and interpret results, with only minor gaps around retry/irreversibility.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters including currency/mandate matching and the idempotency_key resume handle. The description adds only the implicit 'spend mandate' requirement, not new syntax or format detail, so baseline 3 applies.

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

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

States a specific verb+resource with scope ('Pay from THIS agent's Custodian custody wallet'), which is clear and disambiguates whose wallet is charged. It doesn't distinguish itself from payment-adjacent siblings like request_budget or card_link, but no sibling performs this exact 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?

Prerequisites are given (active wallet + spend mandate) and the gate conditions are listed, implying when the call can succeed. However there is no explicit guidance on when to choose pay versus alternatives such as request_budget or card_link, so usage is only implied.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lowered. The description nonetheless adds real context beyond the annotations: the receipt is 'signed,' it is publicly verifiable without Regent, and the token should not be surfaced to the user — a useful sensitivity warning absent from the structured fields.

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, both earning their place, with the core resource definition front-loaded and the handling directive trailing. The first sentence is dense with nested clauses but stays readable and avoids filler.

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

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

With no output schema, the description responsibly describes the returned contents (payment details, recipient, terms version, verify URL). It omits only edge cases such as an unknown or non-completed decision id, which is a minor gap for a single-record read.

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% and there is one parameter, so the description must carry the load. It identifies the argument as a decision id with the 'dec_…' prefix and ties it to 'one of your completed payments,' giving format and provenance that the bare schema string 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 names a specific verb+resource ('the signed receipt of one of your completed payments') and enumerates what it returns (what was paid, to whom, terms version, verify page), so an agent can tell exactly what it retrieves. It does not explicitly differentiate itself from siblings such as approval_status or pay, but the resource is distinctive enough that confusion is unlikely.

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

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

It gives clear context implicitly (fetch for a completed payment by decision id) plus an explicit behavioral directive: 'Show the person the verify link rather than the token.' That tells the agent how to handle the result, though it names no alternative tools or when-not-to-use conditions.

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

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

Annotations only say it is a non-idempotent, non-destructive, closed-world write with no read-only hint. The description adds crucial behavior annotations miss: nothing is granted synchronously, a human owner must see the request in Approvals and e-mail and sign it, and the result arrives asynchronously. This is exactly the extra context an agent needs.

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?

Three dense sentences, front-loaded with what the tool does, then what happens and when to use it. Slightly packed but no sentence is wasted; the human-approval caveat is well placed.

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

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

For a mutating request tool with no output schema and thin annotations, the description covers outcome (approval e-mail/Approvals queue), timing (async, retry later), and follow-up tooling. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and the schema itself documents each field richly (currency ISO code, seller 'match' semantics, caps). The description summarizes the same fields but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (ask) plus resource (spend budget/mandate) and scopes it to THIS agent, clearly separating it from siblings like my_budget (existing budgets) and budget_request_status (tracking). An agent can identify the tool's role without opening the schema.

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

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

Gives explicit trigger conditions ('after a refusal that names a currency you have no budget in ... MANDATE_NOT_FOUND with currency=…') and names the follow-up path ('retry the purchase later, or check budget_request_status'), routing the agent to the correct sibling.

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

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

Adds substantial context beyond the annotations: spend-limit gating on every call, silent parking of unapproved payments for owner approval with a defined retry protocol, and the guarantee that the credential never reaches the agent. That is exactly the behavioral disclosure a destructive, non-idempotent mutation proxy needs.

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?

Three sentences, front-loaded with the verb/resource statement, followed by the escalation rule and the credential guarantee; nothing is padding. The middle sentence is dense but every clause carries operational weight.

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 7-parameter open-ended proxy with no output schema, the description covers the key unknowns: gating, escalation/retry, and credential handling. It stops short of describing what a call returns or how ESCALATION_REQUIRED is surfaced to the agent, which would close the last gap.

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

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

Schema coverage is 86%, so the schema already documents path, body, facts, intent, user_token, and idempotency_key; the baseline applies. The description's idempotency_key retry guidance largely repeats what the schema field already says, and it adds no meaning for `facts` or `intent`, which are the policy-relevant 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?

States a specific verb set (create/change/pay) and resource (https://api.stripe.com) with the allowed HTTP methods, which cleanly separates it from the *_read siblings. It does not, however, distinguish itself from other write-path siblings such as pay or stripe_demo, leaving that routing to the agent.

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 throttle/escalation flow is described (parked for owner, ESCALATION_REQUIRED, retry with same idempotency_key), which is real usage context. But the description never names an alternative tool or states when *not* to use this raw proxy (e.g. when `pay` or a purpose-built tool is preferable), so usage selection is only implied.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the bar is lower, and the description still adds substantial non-obvious behavior: the call is policy-gated by spend limit, unapproved payments are parked and re-executed on retry with the same idempotency_key, and the credential never reaches the agent. It omits failure/timeout behavior and what an unparked-but-denied call returns, and the openWorldHint=false annotation sits oddly against an explicit external api.stripe.com call.

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?

Three tight sentences, front-loaded with the action and target before the gating flow and credential note, with virtually no filler. Minor redundancy: the inline '(POST, PUT, PATCH or DELETE)' duplicates the method enum already in the schema.

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

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

For a 7-parameter mutation tool with no output schema, the description supplies the critical control-flow facts an agent needs (gating, escalation, idempotent retry, credential isolation) while the schema covers most parameter detail. It would be stronger if it characterized the success/parked response shape or stated limits on path scope, but nothing essential to a correct invocation is missing.

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

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

Schema description coverage is 86%, so the schema already documents path, body, facts, intent, method, user_token and idempotency_key in detail. The description restates the method set (already an enum) and the idempotency retry rule (already in the idempotency_key description), adding no new parameter meaning; the baseline of 3 applies.

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

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

The description names concrete operations (create, change, pay) against a concrete target (https://api.stripe.com) and enumerates the HTTP verbs used, so the agent knows this is a generic write proxy to the Stripe API. It falls short of 5 because it never names or contrasts with the obvious sibling stripe_demo_read, leaving the agent to infer the split from the title suffix.

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

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

It explains the operational flow (spend-limit gating, ESCALATION_REQUIRED parking, retry with the same idempotency_key after approval), which is genuinely useful context for calling it. However, it gives no tool-selection guidance against siblings such as stripe_demo_read, pay, or card_link, nor any preconditions for choosing this tool over them.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real value beyond them: the policy check, credential injection by Regent, the fact the key never reaches the agent, and the audit trail (reinforced by the intent param). It does not mention rate limits or error behavior, so it stops short of a 5.

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

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

Two sentences, no filler, with the core purpose and method restriction front-loaded and the safety guarantee ('Nothing is changed and no money moves') closing it out. Every clause 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 read-only proxy tool with full annotation coverage and no output schema, the description supplies what an agent needs: the base URL, allowed methods, credential-handling model and audit behavior. The one gap is that it never distinguishes this tool from the other *_read siblings in the set.

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 80% and the schema already documents path, facts, intent and user_token. The description only touches the method constraint (GET/HEAD/OPTIONS) and adds no format or semantics for the remaining parameters, so it sits at the baseline for well-covered schemas.

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

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

States a specific verb (read) against a specific resource (https://api.stripe.com) with an explicit method constraint (GET, HEAD or OPTIONS only), which cleanly separates it from the write-oriented 'stripe_demo' sibling. It never actually names the write sibling or any other tool, so the differentiation is inferable rather than 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 method enumeration ('GET, HEAD or OPTIONS only') implies this is for non-mutating requests and that mutations belong elsewhere, but the description never says when to pick this over stripe_demo or the other *_read siblings. Usage is implied by the read-only constraint rather than 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 readOnly/idempotent/non-destructive, but the description adds genuinely new context: Regent enforces the policy and injects the credential so the API key never reaches the agent. It stops short of describing what happens when policy denies the call or how responses are shaped.

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

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

Two tight sentences with zero filler, and the core scoping constraint (read-only, GET/HEAD/OPTIONS) is front-loaded before the credential-handling note.

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 5-parameter policy-gated proxy with a nested `facts` object and no output schema, the description covers the safety model and credential handling well. It leaves out denial/failure behavior and what a response looks like, which would matter for an agent composing policy-keyed `facts`.

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 schema already carries the parameter semantics (path, facts, intent, user_token, method enum). The description only restates the method restriction, adding no new meaning beyond the enum; baseline 3 applies.

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

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

States a specific verb (read) and a specific resource (https://api.stripe.com) plus the allowed method set, so an agent knows exactly what this tool does. It does not name the `stripe` sibling as the write counterpart, relying on the sentence 'Nothing is changed and no money moves' to draw that line implicitly.

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 strongly implied: use this for GET/HEAD/OPTIONS against Stripe, and anything that changes state or moves money belongs elsewhere. However, the alternative is never named (e.g. `stripe`), and no prerequisites about policy approval or denial handling are 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 read-only, idempotent, closed-world behavior, so the bar is lower. The description still adds real context the annotations don't carry: the fixed-address nature, that the page prompts for a passkey before proceeding, and the anti-phishing constraint about forwarding only this link.

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?

Front-loads the core identity of the resource (the owner's verification page) and then adds the operational constraints. It is slightly dense and would read better as two or three shorter sentences, but every clause carries 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?

For a zero-param, no-output-schema tool with rich annotations, the description covers what it returns (a fixed address plus verification status) and the safety rule for handling the link. Missing only minor detail such as whether the status check is a separate value in the response.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the tool takes no input, which matches the empty schema.

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

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

The description states a specific resource: the owner's verification page on Regent, plus a secondary behavior (reports whether the owner is already verified). It is clear what the caller gets, though the dual purpose (URL vs. status read) is packed into one long sentence rather than cleanly separated.

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?

Explicit routing guidance: give this fixed address to the person when verification is needed, with the precondition that real-money purchases and card storage require it. It also states a hard exclusion ('Never relay any other verification link'), which is exactly the when-not guidance an agent needs.

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

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

With annotations already declaring destructive and open-world behavior, the description adds meaningful context: Regent reads price/asset/recipient from the 402, decides under the owner's USDC budget, signs from the connected wallet, and checks the transfer on chain. It does not cover failure modes or returned results, but it substantially exceeds what the 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?

Four sentences, front-loaded with purpose and key scope, each carrying useful information about the payment flow and test-network restriction. It is slightly dense but has no obvious filler.

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

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

For a destructive, open-world payment tool with no output schema, the description covers the payment flow, trust model, budget decision, and network restriction. It could mention response shape or budget-rejection behavior, but is largely sufficient 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 83%, so the schema already documents most parameters. The description reinforces the path format as <host>/<path> but adds little beyond the schema for facts, intent, idempotency_key, or method. This justifies the baseline score.

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

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

States a specific verb and resource: fetching a web resource that charges per request via HTTP 402 through Regent. It also scopes hosts and network type. It does not explicitly contrast with the sibling 'pay' tool, so it stops short of full sibling differentiation.

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

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

Gives useful constraints: any public host, test networks only, and the agent never holds a wallet or sets the price. However, it never says when to choose x402 over the sibling pay tool or when not to use it; usage is implied from the resource-charging scenario.

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