DPX — Institutional Cross-Border Settlement

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

The description explains the instantaneous nature of registration, the GLEIF API verification call, and that no documents or manual review are involved. It also describes tier-specific caps and legal basis, adding meaningful context beyond the sparse annotations. No annotation contradiction exists (readOnlyHint=false, openWorldHint=true) and the description aligns with these 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 dense and information-rich, starting with the core concept and moving through tiers and legal reasoning. Every sentence adds value, but the single paragraph format could be improved with more structure (e.g., bullets or headings) for quicker scanning. It is appropriately sized given the 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?

The tool is complex with three tiers, a nested mandate object, and regulatory implications. The description covers all essential decision points: tier selection criteria, daily caps, verification process, and legal acceptance. It also leverages the schema for parameter details and the output schema for return values, making the description complete 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?

Although the input schema already covers all parameters with descriptions, the description adds crucial tier mapping: it explains how the presence or absence of ownerEntity, ownerEmail, and ownerLei determines the tier and associated caps. It also clarifies that the mandate is only for REGISTERED/VERIFIED and that caps are clamped to tier limits, which is not fully captured in the schema descriptions.

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 tool as the agent registration entry point under the KYA model, with a specific action (register) and resource (agent). It distinguishes itself from sibling tools like agent.kya_verify by detailing the three tiers and their requirements, making the tool's purpose 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?

The description provides explicit guidance on which parameters to use for each registration tier (name alone for ANONYMOUS, + ownerEntity/ownerEmail for REGISTERED, + ownerLei for VERIFIED), effectively telling the agent how to select tier options. It does not, however, name alternative tools or explicitly state when not to use this tool, so it lacks full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds useful behavioral context: the credential expires in 1 hour, must be refreshed, and is needed for /settle requests. This goes beyond the annotations without contradicting them.

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

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

The description is concise and front-loaded: the first sentence states the core purpose, the second lists return values, and the third gives usage instructions. Every sentence provides essential information without redundancy.

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

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

For a read-only verification tool, the description covers the purpose, returned fields, usage instructions, and expiration/refresh behavior. It is self-sufficient even without an output schema, and it aligns well with the sibling tool set (e.g., agent.kya_register).

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 covers the only parameter (agentId) with a description, achieving 100% schema coverage. The description does not add further parameter details beyond referencing agent.kya_register, so the baseline score 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 action: 'Verify a registered DPX agent and receive a signed 1-hour credential.' It clearly distinguishes from sibling tools like agent.kya_register (registration) and compliance.pep_screen (screening) by focusing on verification and credential issuance for DPX /settle requests.

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 clear context for when to use the tool: after registration and before settlement requests. It instructs how to use the credential (attach headers) and when to refresh ('Credential expires in 1 hour; call again to refresh before expiry'). It does not explicitly mention alternatives or exclusions, but the usage context is sufficiently clear.

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=false and destructiveHint=false, and the description aligns with these. It goes beyond annotations by revealing tier-dependent cap enforcement (REGISTERED agents clamped to $25K, VERIFIED agents no ceiling), the AP2 compatibility requirement, and the fact that it can create or update. This adds meaningful behavioral detail about how the mandate will be handled.

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: the first states the core action, the second lists the constraint fields, and the third covers agent-tier rules. Each sentence is dense with essential information and no redundancy, with the purpose 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 8 parameters and an output schema present, the description covers the non-obvious business rules (agent tiers, cap clamping, AP2 formatting) and the prerequisite that anonymous agents must register first. The output schema handles return values, so the description is complete for guiding invocation and expectation-setting.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that REGISTERED agents' caps are clamped to their tier limit, which directly affects the effective semantics of maxNotionalUsd and dailyCapUsd. It also maps the prose fields (counterparty whitelist, currency pairs, ESG floor, expiry) to schema properties, reinforcing their 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 opens with 'Create or update an AP2-compatible spend mandate for a REGISTERED or VERIFIED DPX agent' — a specific verb, object, and target. It enumerates the mandate fields and clearly distinguishes this from sibling tools like agent.kya_register and agent.kya_verify by focusing on settlement constraints rather than identity management.

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 clear eligibility context: mandates are for REGISTERED or VERIFIED agents, and ANONYMOUS agents are explicitly excluded with the directive to 'register with ownerEntity + ownerEmail first.' This is helpful but doesn't explicitly name the alternative tools (e.g., agent.kya_register) or state when not to use this tool beyond the anonymous case.

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 destructiveHint=false, so the safety profile is known. The description adds value beyond annotations by specifying this is 'live' and detailing the returned data categories (stability, ESG, fees, oracle health, settlement readiness), which helps the agent predict the response shape.

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

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

The description is two sentences: the first states the core capability and deliverables, the second gives use cases. It is front-loaded with the key phrase 'Get live DPX performance analytics' and contains no redundant or vague wording.

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

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

This is a zero-parameter, read-only overview tool with an output schema present. The description fully covers purpose, output contents, and intended use cases. No further context is necessary for an agent to select and invoke this tool correctly.

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

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

The tool has zero parameters and an empty input schema, so there are no parameter semantics to clarify. Per rubric, 0 parameters earns a baseline of 4. The description adds no parameter information because 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 uses a specific verb and resource: 'Get live DPX performance analytics.' It clearly lists the returned components (stability score, ESG composite scores, fee breakdown, oracle health, settlement readiness) and distinguishes this aggregate overview from sibling tools like dpx.metrics or oracle.stability.

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 explicitly states intended use: 'Use for dashboards, reporting, and AI-driven monitoring of protocol health.' This provides clear context for when to invoke the tool. It does not mention alternatives or when not to use it, but for a zero-parameter overview tool this is acceptable.

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?

Discloses valuable behavioral traits beyond the sparse annotations: concurrent execution, partial failure tolerance, response summary, and per-item mirroring of POST /settle. Annotations only provide false hints, so the description adds meaningful context, though it omits details like authorization or 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?

Three sentences, each earning its place: the first states the core purpose, the second explains concurrency and failure handling, and the third describes the return value and batch limit. Front-loaded and free of fluff.

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

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

For a batch operation with an output schema, the description covers all critical operational aspects: purpose, concurrency, partial failure, return summary, and maximum batch size. It does not mention sandbox usage or broader error handling, but these are not essential given the rich output schema and clear behavior description.

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 sole parameter 'settlements' is already described in the schema as 'Array of settlement request objects (same schema as the settle tool)', and the description additionally repeats the 50-item max (already in schema). No new semantic meaning is added beyond what the schema provides, so baseline 3 is appropriate.

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

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

Description opens with 'Submit multiple settlements in a single call', a specific verb and resource, and clearly distinguishes batch_settle from single-settlement siblings via concurrency, failure isolation, and a 50-item cap. This leaves no doubt about the tool's scope.

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

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

Clearly states the use case (multiple settlements in one call) and key behavior (concurrent execution, one failure not blocking others). However, it does not explicitly name alternatives or provide when-not scenarios, so it falls just short of full 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 and destructiveHint false, so there is no contradiction. The description adds useful behavioral context: it 'returns an optimal settlement plan', 'No settlement is executed', and 'Free', explaining the safe, non-executing nature of the call beyond what annotations capture.

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 front-loaded with the purpose, uses a compact example, and has no filler. Each clause (input, output, safety, usage sequence, cost) 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 planning tool with no output schema, the description explains the return plan elements (settle-vs-hold, stablecoin, fee), the input format, and the intended position in the workflow before card.settle. It is sufficient for an agent to select and invoke the tool correctly given the annotations 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?

The schema already covers both parameters at 100%, including an inline example for positions and a default note for settlementDate. The description's 'net positions per corridor' and currency examples reinforce the concept but do not add new parameter-level meaning beyond the schema.

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

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

The description says 'Plan treasury settlement for a crypto card program' with explicit input (net positions per corridor) and output (optimal settlement plan with corridors, stablecoin, fee). The phrase 'Call this before card.settle' and 'No settlement is executed' clearly distinguishes it from settlement execution 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?

It states 'Call this before card.settle to review the plan', giving direct when-to-use guidance. It lists what the tool returns and explicitly says 'No settlement is executed', signaling when not to use it (when execution is desired). It also mentions 'Free', which may help tool selection.

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?

Discloses beyond annotations: 'compliance-gated, oracle-priced, stablecoin-routed' adds operational context; notes sandbox behavior (no on-chain execution); states return type. No contradiction with annotations (readOnlyHint=false, destructiveHint=false). Still could mention idempotency or failure modes but solid coverage.

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

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

Three sentences precisely convey purpose, method, constraint, usage tip, and return. Front-loaded with key action. No redundant or filler content. Every sentence adds 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 moderate complexity, schema coverage is good, but no output schema exists. Description mentions per-corridor results and summary but lacks details on error handling, idempotency, or failure scenarios. Leaves some gaps for a settlement execution 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 descriptions already cover both parameters with high detail (100% coverage). The description reinforces that recipientAddress is required and echoes sandbox default, adding minimal new meaning. Baseline of 3 is appropriate as schema carries the load.

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

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

Description clearly states the verb 'Execute treasury settlement' and resource 'crypto card program.' Differentiates from sibling card.positions by noting it uses the same positions array but executes settlement via DPX batch. However, does not distinguish from batch_settle or other settlement tools, leaving some ambiguity.

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?

Provides a specific usage tip: 'Use sandbox:true for testing.' Implicitly suggests when to use (when executing treasury settlement for a card program) but lacks explicit 'when not to use' or alternatives beyond mentioning card.positions. No guidance on selecting between batch_settle or other settlement 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 this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context: the specific return fields, the risk-level classification, and the EDD obligation triggered by matches, which goes beyond the structured 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 four sentences, each sentence earns its place: defining the source, listing PEP categories, describing outputs, and stating the regulatory consequence. No wasted words or redundancy.

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

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

Given the read-only annotations, simple two-parameter schema, and presence of an output schema, the description fully covers the tool's purpose, inputs, outputs, and regulatory significance. Nothing material is missing for an agent to invoke and interpret results.

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

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

Schema description coverage is 100%, so the schema already fully documents the 'q' and 'country' parameters. The description reinforces that 'q' is a name and 'country' is an optional filter, but adds little semantic nuance beyond the schema.

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

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

The description uses a specific verb ('Screen') and a clear resource ('OpenSanctions PEP dataset'), then details the output and risk levels. This distinguishes it from other compliance tools by its focus on PEP screening and regulatory implications.

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 clearly implies when to use this tool: for PEP screening before settlement, and it explicitly notes that HIGH/MEDIUM matches require EDD per FATF. It does not name sibling alternatives, but the context is sufficiently clear for an agent to select it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety behavior. The description adds context about the output (upcoming/in-effect obligations, DPX alignment) beyond annotations. No contradiction.

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

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

The description is comprised of three concise sentences: what it returns, the event fields, and the DPX alignment section, plus when to use it. No redundant or extraneous content; every sentence earns its place.

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

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

Given the output schema exists, the description doesn't need to repeat return details. It fully covers the regulatory scope, event fields, DPX alignment, and intended use cases, making the tool well-contextualized for an AI agent.

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

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

The tool has zero parameters, so the schema provides no parameter information. The description compensates by explaining the structure of the returned data (framework, jurisdiction, requirement, effective date, impact level, article reference), which adds meaningful context even though no parameters 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 clearly states the tool returns a structured calendar of compliance obligations and lists specific regulations (MiCA, SFDR, CSRD, GENIUS Act, FATF). The verb 'Returns' plus the specific resource differentiates it from sibling compliance tools like pep_screen and ubo_chain.

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 usage guidance is provided: 'Use this before settlement workflow design, compliance gap analysis, or regulatory reporting.' This clearly indicates when the tool should be invoked and distinguishes it from alternative compliance 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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: the data sources (GLEIF, OpenSanctions), the traversal logic (SUBJECT → DIRECT_PARENT → ULTIMATE_PARENT), per-node sanctions status, LEI lapse flags, and the overall verdict types (CLEAR / REVIEW_REQUIRED / BLOCKED). This goes beyond the structured metadata and provides a clear picture of what the tool returns and how it behaves.

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

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

The description is three sentences and about 90 words, covering functionality, return structure, and use cases. It is dense but not bloated, and each sentence contributes unique information. Slightly longer than ideal but well-structured and front-loaded with the core action.

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 this complexity (multi-level chain tracing, sanctions screening, multiple output components), the description is thorough. It mentions the chain structure, sanctions status, LEI lapse flags, overall verdict, FATF attestation, and specific regulatory use cases. Since an output schema exists, the description does not need to enumerate return fields in detail. This is complete for an agent to decide when and how to 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 coverage is 100% with detailed descriptions for both parameters ('lei' and 'deep'). The tool description does not add parameter-specific semantics beyond what the schema already provides, so the baseline score 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 uses a specific verb ('Trace') and resource ('beneficial ownership chain'), with clear scope ('up to 3 levels deep') and explicit screening against OpenSanctions. It clearly distinguishes from sibling tools like compliance.pep_screen and ramp.compliance_screen by identifying a distinct compliance workflow (UBO chain tracing + sanctions screening).

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 explicit use-case contexts: 'Required for correspondent banking due diligence, FATF R.12/13 UBO identification, and MiCA Article 72 counterparty risk management.' However, it does not explicitly mention alternative tools or when not to use this tool, so it falls just short of full guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context: 'without running inference' and 'Free', which goes beyond the annotations and clarifies side-effects and cost characteristics.

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 with the first sentence front-loading the core purpose. Every sentence adds value: purpose, use case, and cost note. No filler.

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

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

For a simple 2-parameter tool with rich annotations and no output schema, the description sufficiently covers return values (best free model, strengths, speed tier, alternatives) and use context. It is complete for agent selection.

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 explains both parameters. The description doesn't add parameter-specific syntax or format details beyond what the schema provides. Baseline 3 is appropriate.

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

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

Description clearly states it gets a model recommendation for a task type without running inference, listing specific outputs (best free model, strengths, speed tier, alternatives). This distinguishes it from siblings like compute.models and compute.route.

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 when-to-use guidance is provided: 'Use this when an agent needs to select a model before committing to inference, or to surface model selection logic to a human.' It implies not for running inference but doesn't name specific alternative tools 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 and idempotentHint, and the description adds useful context: models are routed via OpenRouter, no token cost, and it lists the specific return fields (model IDs, provider, capability strengths, context window, speed tier). This goes beyond the annotations by clarifying the behavioral scope and output contents.

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 and front-loaded with the main purpose, but it repeats 'Free' twice ('free-tier' and 'Free.') and includes slightly redundant phrasing. Overall, every sentence provides useful information, so it earns a strong score, but the redundancy keeps it from a 5.

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 is present, but the description details the return fields (model IDs, provider, capability strengths, context window, speed tier) and gives usage context. For a parameterless list tool with good annotations, this is complete and self-sufficient.

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 are no parameter semantics to clarify. With 0 params, the baseline is 4, and the description provides a clear explanation of the tool's output, adding value despite the lack of 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 clearly states the tool lists all AI models available through DPX Compute, using the specific verb 'list' and the resource 'AI models'. It also distinguishes itself from the sibling tool compute.route by positioning itself as a precursor to route selection.

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 explicitly instructs to use this tool before compute.route to understand available models and pick the right one, providing clear when-to-use guidance and naming the alternative tool. It also states all models are free-tier, eliminating concerns about cost.

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 discloses several behavioral traits beyond the annotations: the automatic model selection logic, the free-tier nature with no token cost, the per-call USDC payment via x402, and that API keys are handled internally. It does not contradict annotations (readOnlyHint=false, destructiveHint=false), and adds meaningful context that helps an agent understand side effects and constraints.

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 four sentences and every sentence earns its place: purpose, model mapping, cost model, and usage guidance. The task-type mapping is presented compactly in a parenthetical list, keeping the description tight and front-loaded with the primary action and outcome.

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 moderate complexity (3 params, no output schema, action with side effects), the description adequately covers what it does, how models are chosen, the payment mechanism, and when to use it. It does not detail the response format (the completion text), but that is standard for an inference endpoint and implied by the schema; the description is complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, but the description adds value by mapping task types to specific models (reasoning → DeepSeek R1, code → Llama 3.3, etc.), which enriches the 'task' parameter semantics beyond the schema's generic 'Used for model selection.' It also aligns 'fast' with Llama 3.1 8B, reinforcing the preferSpeed parameter behavior.

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 verb ('Route') and resource ('a task... to the best available free AI model and run inference'), and distinguishes itself from sibling tools like compute.cost and compute.models by positioning itself as the inference execution tool. The model selection examples further clarify the exact scope.

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

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

The description provides an explicit usage context: 'Use this when an agent needs to delegate a subtask to a language model without managing model selection or API keys.' This clearly indicates when to invoke it, though it does not name specific alternative tools for model listing or cost estimation, so it stops short of full when-not-to-use guidance.

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

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

Annotations already declare destructiveHint=true and readOnly=false. The description adds meaningful context beyond annotations: 'DPX runs the full oracle gate → compliance screen → settlement flow' and 'Returns a receipt,' clarifying that this triggers a multi-step pipeline, not just a simple payment call. 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?

Three sentences with a front-loaded purpose and examples, followed by usage alternatives and execution flow. Efficient and well-structured, though there is slight redundancy between 'Call this instead of typing credentials into a UI' and 'Use whenever computer use encounters a payment...'

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, the rich input/output schemas, and a large sibling set, the description is quite complete: it covers the execution pipeline, return receipt, and the key distinction from manual credential entry. A short note on prerequisites or authorization would elevate it, but the current coverage is solid.

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

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

Schema description coverage is 100%, so the baseline applies. The main description mentions 'provide the amount and recipient' and 'Describe what you see on screen,' but these add little beyond the already-rich parameter descriptions in the schema. The useful alternative-tool hint for recipient_address is in the schema, not the main 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?

Specific verb 'Complete a payment' with clear context: identified on screen by computer use, with concrete examples (checkout form, wire transfer UI, invoice approval, vendor portal). Distinguishes from siblings by 'Call this instead of typing credentials into a UI,' 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?

Explicit when-to-use guidance: 'Use whenever computer use encounters a payment that would otherwise require human re-entry or approval.' Also provides an alternative: 'If only bank/email visible, use settlement.nl instead' (in schema), and tells agents to call this instead of typing credentials into a UI.

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 read-only, idempotent, non-destructive nature. The description adds valuable behavioral context: data is 'pulled directly from production telemetry,' 'No auth required,' and the tool is 'Free.' This goes beyond the annotations without contradicting them.

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

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

Three sentences densely pack all relevant information: what the tool does, what it returns, who it is for, and access requirements. No filler; each sentence contributes meaningfully.

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

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

For a simple read-only metrics tool with a single optional parameter, the description is complete. It explains the data source, scope, use cases, and authentication, and the output schema exists to document returns. There is no missing critical information.

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 (window) including enum values and default. The tool description does not add any additional parameter insight, so the schema already carries the burden. Baseline 3 applies due to 100% schema coverage.

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

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

The description clearly identifies the tool as returning live performance metrics for the DPX settlement infrastructure, enumerating specific data points (request volumes, error rates, growth trends, per-service breakdown, spike analysis). It does not explicitly differentiate from sibling tools like analytics.overview, but the specificity of resource and scope is strong.

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 clear usage context by stating the tool is 'designed for investor due diligence, analyst queries, and Standard Metrics / portfolio management integrations.' It does not mention when to avoid using it or contrast it with alternatives, but the intended audience and scenarios are 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 indicate read-only and non-destructive behavior. The description adds valuable context: the 50-entity batch limit, ranking order, and the performance trade-off of name resolution vs. direct LEI input. No contradictions 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 four concise sentences with no redundant text. It front-loads the core capability and each sentence contributes useful details about limits, inputs, output ranking, use cases, or performance.

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 an output schema present and annotations covering the safety profile, the description provides sufficient context including purpose, inputs, output ordering, use cases, and performance characteristics. It is complete for a batch screening 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 descriptions already cover both parameters at 100%, but the description adds meaningful nuance: LEIs are the fastest path and names require slower GLEIF resolution. This goes beyond the baseline schema 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 clearly states the tool screens up to 50 entities in a single call and returns results ranked by composite ESG score. It distinguishes itself from sibling tools by explicitly positioning it for batch/portfolio-level screening rather than single-entity lookups.

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 names specific use cases: portfolio-level compliance screening, supplier due diligence, and TMS pre-payment checks. It does not explicitly mention alternatives for single-entity checks, but the context is clear enough to guide the agent.

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

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

Annotations already convey the read-only, idempotent, and non-destructive nature. The description adds valuable behavioral context by detailing the return structure: Environmental (40%), Social (35%), Governance (25%), composite 0–100, fee surcharge tier, and per-source breakdown. It also clarifies the LEI resolution step, enhancing understanding 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 long, front-loaded with the primary action and purpose. The second sentence adds usage guidance without redundant statements. Every word earns its place, making it exceptionally concise yet informative.

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

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

Given the presence of an output schema and fully described parameters, the description provides a complete picture: what the tool does, when to use it, and what it returns. It covers the LEI resolution need, the composite score, fee tier, and data sources, leaving no significant gaps for an agent to make an informed decision.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond restating the lookup scope (company name, domain, ticker). It reinforces that 'q' is the lookup key but provides no additional format or syntax details.

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

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

The description uses a specific verb 'Resolve' and clearly identifies the resource: 'company name, domain, or ticker to a LEI via GLEIF'. It further states the tool returns the full ESG score, and the 'Use when you have a company name but not a LEI' phrasing distinguishes it from sibling ESG tools that may require a LEI.

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 explicitly states when to use: 'Use when you have a company name but not a LEI'. This provides clear context but does not name specific alternative tools or explicit exclusions, falling short of the full 5-level 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 and destructiveHint=false, so safety behavior is covered. The description adds valuable behavioral context: the 'up to 200 entities' limit, the 'one call' batch nature, and the specific list of returned portfolio-level metrics. No contradictions or hidden side effects are disclosed.

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 tightly packed sentences. The first sentence front-loads the action and immediately provides scale, method, and a comprehensive output list; the second sentence adds the use case. Every clause earns its place without fluff 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?

With a rich output schema and fully described parameters, the description adds the key contextual elements: batch scale, input method, output categories, and intended use case. The only minor gap is that all parameters are optional, and the description doesn't clarify what happens if no parameters are provided (e.g., whether an empty portfolio is allowed), but this is not a significant omission.

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%, with each parameter already described meaningfully (LEIs are 'fastest — no name resolution', names are 'GLEIF-resolved', label has an example). The description adds little beyond confirming that entities are identified 'by LEI or name', so it does not need to compensate for schema 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 opens with a specific action and resource: 'Score an entire counterparty portfolio in one call', clearly distinguishing it from single-entity scoring tools. It also enumerates concrete outputs (composite scores, tier distribution, fee impact, worst offenders, etc.) and closes with a clear positioning as 'the canonical pre-settlement compliance check', which differentiates it from sibling ESG tools.

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

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

The description gives clear usage context: a pre-settlement compliance check for treasury systems and TMS integrations, implying when to use it. It does not explicitly name alternative tools or state when not to use it, but the 'canonical' phrasing and portfolio-level scope provide enough guidance for selection among siblings.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds valuable context: it updates hourly from six institutional data sources and returns specific output components including the compliance-adjusted settlement fee percentage. This goes beyond the annotations and gives the agent a clear understanding of data freshness and output scope.

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 three sentences, each earning its place: purpose, return values, and data sources/use case. It is front-loaded with the core action and avoids redundancy.

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

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

For a simple read tool with one optional parameter, an output schema, and strong annotations, the description is complete. It covers what is returned, how often data updates, where data originates, and why it is used (compliance). No critical information 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?

The schema has 100% parameter description coverage (the single 'address' parameter is fully described). The description's mention of 'for a wallet address or the protocol default' adds marginal value by contextualizing the optionality, but it does not introduce any new syntax or format details beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool gets a live ESG-denominated counterparty risk score for a wallet address or protocol default. The verb (Get), resource (counterparty risk score), and scope (wallet address or default) are specific, and the detail about returning individual E/S/G scores, composite average, and fee percentage distinguishes it from sibling ESG tools like esg.batch, esg.portfolio, and esg.trend.

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 clear context for when to use the tool, noting it is required for EU SFDR Principal Adverse Impact reporting and CSRD financed emissions disclosure. It does not explicitly name alternative tools or state exclusions, but the compliance use case is a strong implicit 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, idempotentHint, and destructiveHint, so the description only needs to add context beyond those. It explains that data accumulates each time the entity is scored and mentions return values (trend direction, delta), which adds useful behavioral detail without contradicting annotations.

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

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

The description is three sentences with no fluff: what it does, what it returns, and data accumulation/use cases. Each sentence earns its place, and the most important information is 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?

Given the tool's moderate complexity, two parameters, and presence of an output schema, the description is complete. It covers purpose, return values, data source, and use cases. It omits pagination or edge cases, but these are likely handled by the output schema. Overall, 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?

Schema covers 100% of parameters with clear descriptions. The description adds minimal extra meaning by referring to 'requested window' (matching days) and delta, but relies on the schema for parameter definitions. This meets the baseline for high schema coverage.

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

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

The description opens with 'Get the historical ESG composite trend for a specific entity by LEI', using a specific verb and resource. It clearly distinguishes from sibling tools like esg.score or esg.lookup by emphasizing historical trend, and explicitly lists return values (score history, trend direction, delta).

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 concrete use cases: 'due diligence, MiCA Article 72 ongoing monitoring reports, and detecting counterparties whose ESG posture is degrading.' It implies when to use but does not explicitly contrast with sibling tools or state when not to use it. The note about data accumulation via esg.lookup/batch/portfolio adds helpful 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 only provide generic flags (not read-only, not idempotent, not destructive). The description goes far beyond by detailing the exact behavior: DPX checks daily, fires webhook on threshold shift, returns a watchId for status/cancellation, and includes previous/current score, delta, and tier change in the payload. No contradictions 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, three sentences, and front-loaded with the primary purpose. Every sentence adds substantive information: registration, daily checking mechanism, webhook trigger, return value, and payload contents. No filler or redundancy.

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

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

The tool has only 3 parameters and an output schema exists, so the description does not need to explain return fields in detail. It provides all necessary context: what the tool does, how it behaves, what it returns (watchId), and how to use it for regulatory compliance. The description is fully adequate for an agent to select and 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 100%, so each parameter is already described in the schema. The description repeats the thresholdPoints semantics ('fires a webhook when the composite score shifts by ≥ thresholdPoints') but does not add new meaning beyond the schema. It also does not elaborate on lei or webhookUrl beyond their schema descriptions, so it adds minimal value.

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

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

The description clearly states the tool's function: 'Register an entity for ongoing ESG monitoring.' It uses a specific verb ('Register') and resource ('entity for ongoing ESG monitoring'), distinguishing it from sibling tools like esg.score (one-off scoring) and esg.trend (historical trends). The mention of MiCA Article 72 also provides a clear regulatory context.

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

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

The description implies the intended use case: ongoing monitoring with daily checks and webhook alerts, rather than one-time lookups. It also mentions satisfying regulatory requirements, which helps an agent identify when to use this tool. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full 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 destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful behavioral context: it returns dollar savings at the current DPX all-in rate (~2.035%) and includes GENIUS Act and MiCA compliance status for each competitor. No contradictions 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 and front-loaded, immediately listing competitors and rates, then shift to return behavior. Every sentence provides concrete, actionable information without redundancy or 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?

The description covers the comparison scope, competitor list, output details (savings and compliance), and the current DPX rate. An output schema exists, so return structure is already documented. A minor gap is that optional parameters like esgScore and hasFx are not explained in the description, but the schema covers their semantics.

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 covers all three parameters with descriptions (100% coverage), so the description doesn't need to compensate. The description adds no parameter-specific meaning beyond what the schema provides, which is acceptable given high schema coverage.

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

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

The description clearly states the tool's function: comparing DPX settlement costs against a specific list of competitors (Stripe, Wise, Ripple, etc.) and returning savings plus compliance status. This distinguishes it from sibling tools like fees.schedule and fees.verify, which likely handle schedule-only or verification-only concerns.

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 clear context for when to use the tool: when a comparison of DPX fees to competitors is needed, with specific competitor rates included. It doesn't explicitly name alternatives or exclusion criteria, but the detailed competitor list makes the use case obvious.

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, covering safety. The description adds what the returned schedule includes, setting expectations for data scope. No contradictions.

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

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

One sentence, front-loaded with the verb and object, then a well-organized list of inclusions. Every phrase adds information; no fluff.

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 an output schema present, return values are documented elsewhere. The description covers all major aspects of the fee schedule and is sufficient for a no-param read-only retrieval tool. It doesn't need to explain parameters or side effects.

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 baseline is 4. The description appropriately doesn't discuss parameters because there are none; the input schema is an empty object.

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 'Get the complete DPX fee schedule' – a specific verb and resource. It enumerates the exact contents (components, tiers, ESG table, scenarios, benchmarks), making its scope unambiguous and distinguishing it from fees.compare and fees.verify.

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

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

No explicit when/when-not guidance is given. The word 'complete' implies this is the go-to for the full schedule, but alternatives like fees.compare and fees.verify are not mentioned or contrasted. Usage is implied 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context by referencing the specific on-chain contract and the boolean return, but does not elaborate on error handling or mismatch behavior. This adds value beyond annotations without contradicting them.

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

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

Two sentences, front-loaded with the core purpose and including the crucial sequencing note. Every word earns its place; no fluff or redundancy.

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

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

For a simple verification tool with rich annotations, an output schema, and clear description of sequencing, the description is complete. It even names the contract and clarifies the expected return, leaving no critical gaps for the agent to infer.

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 all three parameters are documented in the input schema. The tool description does not add additional parameter-specific details beyond that, so a baseline score 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 a specific verb ('Verify') and resource ('off-chain fee quote matches what the on-chain DPXSettlementRouter contract will charge'), distinguishing it from sibling tools like fees.compare and fees.schedule. It also mentions the return value, making the purpose unambiguous.

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

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

Provides explicit timing guidance: 'Call after get_quote and before settle to confirm fee integrity.' This gives clear when-to-use context, though it doesn't mention alternatives or when-not-to-use scenarios, which would push it to 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context: parallel execution of checks, the unified go/no-go decision format, and the inclusion of a 'ready-to-use settleBody'—all beyond what annotations provide. 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 three sentences, front-loaded with the primary action, and every sentence adds value: purpose, workflow replacement, and return payload. No redundancy or 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 an output schema present (not shown but indicated), the description need not enumerate all return fields—yet it does. It covers what the tool does, when to use it, what it replaces, and what it returns. Combined with strong annotations and full schema coverage, this is fully contextualized for an agent.

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%, with each parameter (amount, from, to, address, lei) having a clear description. The tool description does not add param-specific details beyond the schema, but it does provide workflow context (e.g., 'settlement amount in source currency') that reinforces the purpose. Baseline of 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose with a specific verb+resource: 'Single pre-flight call before settling' that runs oracle check, compliance screen, and stablecoin routing. It distinguishes itself from the multi-step process by explicitly noting it 'Replaces the 3-step oracle → screen → route loop,' making its unique role unambiguous.

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

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

The description provides explicit context for when to use the tool: 'before settling.' It also names the alternative workflow it replaces ('the 3-step oracle → screen → route loop'), giving the agent clear guidance on choosing this tool over the sequential process or related sibling tools like settlement.execute.

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 destructiveHint=false, so the safety profile is clear. The description goes beyond annotations by specifying the number of windows (12), the sorting logic (by urgency, active first), and the content of each entry (affected commodities, severity, agronomic basis). This provides useful behavioral context without contradicting annotations.

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

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

The description is front-loaded with the core purpose and provides a compact yet informative list of examples and output characteristics. Every sentence adds value and there is no redundancy or 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?

Given the tool has no parameters, an output schema is available, and annotations cover safety, the description provides all necessary context for an agent to decide when and why to invoke it. It explains the content, ordering, and rationale sufficiently.

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 every aspect of input is already known. The description doesn't need to explain parameters; the baseline score of 4 applies. It does not introduce 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 clearly states the tool's function as a seasonal climate event calendar with commodity impact, listing specific example windows (hurricane season, corn pollination, etc.). It distinguishes itself from siblings like forecast.commodity_outlook or forecast.scenario by focusing on a fixed set of recurring climate windows.

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 alternatives. The description explains what it returns but does not mention when it is appropriate or what other tools would be better for different scenarios. There is no exclusionary or comparative language.

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, so the description adds value by disclosing cache behavior ('Cache: 4h'), the ability to bypass it via 'fresh', and a disclaimer about not being a financial recommendation. It also details the output structure (BULLISH/BEARISH/NEUTRAL, horizons, confidence score). This goes beyond the minimal annotation credit.

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 four sentences, with no fluff. It front-loads the core purpose and then logically flows to return values, scope, audience, disclaimer, and caching. Every sentence earns its place.

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

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

Given the tool's straightforward read-only nature, rich annotations, full schema descriptions, and an output schema, the description is complete. It covers scope, behavior, audience, and caveats, and clearly differentiates from siblings without needing to explain the output format (handled by output schema).

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

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

Schema coverage is 100% and both parameters have descriptions. The tool description's parameter-related content, such as the commodity list and cache time, largely duplicates the schema's own parameter descriptions. It adds no meaningful new semantic information about the parameters themselves.

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 a specific verb and resource: 'Climate-driven price pressure outlook for a commodity.' It clearly distinguishes itself from siblings like forecast.scenario or forecast.portfolio_stress by focusing on commodity-specific climate signals and listing the exact 11 commodities covered.

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

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

It clearly states the target audience and use case: 'Designed for institutional research teams evaluating commodity positions.' However, it does not explicitly name alternatives or state when not to use this tool, but the context is sufficiently clear for an evaluative decision.

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 destructiveHint=false. The description adds meaningful behavior: weights are normalized internally, the tool identifies stressed positions and hedges, returns a plain-language summary, and enforces a 20-position cap. This complements the annotations without 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?

Three sentences with no filler: first states the core function, second details inputs and outputs, third names the intended user. Every sentence earns its place, and the description is front-loaded with the primary 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 description covers the essential input constraints, normalization behavior, output components, and typical use case. An output schema exists, so detailed return values aren't needed in the description. Minor gaps like the symbol enum are already in the schema, making this adequate for tool 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 coverage is 100%: positions array and weight are both documented, including normalization and maxItems. The description adds 'percentages or fractions' to clarify weight formats but otherwise restates schema details. This is marginal added value, so a baseline 3 is appropriate.

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

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

Description clearly identifies the tool as a climate stress test for a multi-commodity portfolio, with a specific verb ('stress test') and resource ('portfolio'). It lists distinct outputs (portfolio score, stressed positions, hedges, summary), but doesn't explicitly contrast with sibling tools like forecast.commodity_outlook or esg.portfolio, so it falls short of full differentiation.

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

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

The description states a clear use case: 'useful for commodity fund managers evaluating aggregate climate exposure before rebalancing.' It also provides input constraints (up to 20 positions, normalized weights). However, it doesn't explicitly state when not to use this tool or name alternatives, so it gives context without 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context: the tool returns a ranking based on current climate risk scores and indicates risk levels, which is more detailed than just listing data. No contradictions 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 two sentences long, front-loaded with the primary function, and every word adds value. It efficiently conveys scope, output content, and intended use without 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?

Given the tool's simplicity (no parameters), the description is complete. It covers the output structure (regions, commodities, risk levels) and the purpose. An output schema exists (though not shown), so return value details are not the description's responsibility. There are no missing aspects for the agent to make a selection decision.

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, and the baseline for such cases is 4. The description compensates by explaining what the output contains (commodities, risk levels), which helps the agent understand the fixed report format. No parameter explanations needed since there are none.

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: it lists and ranks ~40 global commodity production regions by current climate risk score, specifying the output details (affected commodities and risk levels). This distinguishes it from sibling forecast tools like commodity_outlook or scenario by focusing specifically on production regions and climate risk.

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 a clear use case: 'Use to identify which geographic zones are under active climate stress and which commodities are most exposed.' It gives context for when to use the tool, but does not explicitly mention alternatives or when not to use it, so it doesn't warrant 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 declare readOnlyHint=true and destructiveHint=false. The description adds context that this is a 'what-if' analysis showing how signals shift, which aligns with read-only behavior. It does not disclose additional behaviors like latency or external dependencies, but the annotation coverage lowers the bar.

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

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

The description is four sentences and each contributes: a label, core functionality, the full scenario list, and a use-case note. The scenario list is somewhat redundant with the schema enum but serves as a quick reference. Overall, it is efficient and 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 description covers what, how, and when to use the tool, and the input/output schemas are rich enough to handle remaining details. It does not need to explain return values because an output schema exists. The mutual exclusivity of scenario vs. stressorOverrides is implied by 'or' and 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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the scenario list and the 'or' relationship between scenario and stressorOverrides, but it largely repeats the schema's own descriptions. It adds minimal new meaning beyond interpreting symbols as 'any subset of commodities.'

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 tool as 'What-if climate scenario analysis' and specifies that it applies named scenarios or custom stressor multipliers to commodity subsets. It distinguishes itself from siblings like forecast.portfolio_stress by focusing on commodities and climate scenarios rather than portfolio-level stress.

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

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

The description gives a clear use case: 'stress-test a commodity thesis before committing to a position.' However, it does not explicitly contrast with alternative tools (e.g., forecast.portfolio_stress) or state when not to use this tool, so it lacks explicit 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?

Given annotations already declare readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral context: sorting order (OPTIMAL → ADVERSE), the inclusion of stability tiers and regulatory flags, and the 'Free' cost note. This exceeds what the annotations alone 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 three sentences, each serving a distinct purpose: what it returns, how it's sorted, and when to use it. It is front-loaded with the core function and contains no redundant or filler content.

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

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

For a simple read-only list tool with a single optional parameter and an existing output schema, the description covers all essential aspects: scope, data fields, ordering, use case, parameter usage, and cost. Nothing critical is missing.

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

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

Schema coverage for the single 'from' parameter is 100%, with the schema already explaining it as an optional filter. The description repeats this ('Filter by source currency with the from parameter') without adding new semantic detail, so it meets the baseline but doesn't elevate it.

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

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

The description clearly states the tool returns all 60+ currency corridors with stability tier, volatility, and regulatory flags. The phrase 'compare corridors before choosing a payment route' distinguishes it from sibling tools like fx.rate or stability.corridor, which likely focus on single values or specific corridors.

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 explicitly says 'Use to compare corridors before choosing a payment route' and provides a concrete example. It doesn't name alternative tools or mention when not to use it, but the context is clear enough for an agent to infer the appropriate scenario.

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 discloses the x402 micropayment requirement and the specific output components (amount after rail fees, variance in dollars, stability overlay, execution window), which add behavioral context beyond the readOnlyHint annotation. There is no contradiction with annotations; the read-only nature is consistent with a quote 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?

The description is three focused sentences that front-load the tool's purpose, then detail the output, and finally answer the user's implicit question with a requirement. Every sentence adds value; no filler or redundancy.

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

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

Given the complexity of cross-border settlement cost and the presence of an output schema, the description is sufficiently complete. It covers the tool's purpose, the key output dimensions, and the payment prerequisite, while the schema and annotations handle parameters and safety.

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 100% description coverage, so the description does not need to explain parameters; the baseline is 3. The description adds no parameter-specific detail beyond the schema, though it clarifies that 'amount' refers to the amount sent in the example question.

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 'All-in settlement cost quote for cross-border payments' and details the output as exact amount received, FX cost variance, stability overlay, and execution window. This specific verb+resource phrasing distinguishes it from sibling tools like fx.rate (simple rate lookup) and fx.corridors (corridor data).

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 when a CFO-grade, all-in cost certainty quote is needed for cross-border payments, providing clear context. However, it does not explicitly state when not to use it or name alternative tools (e.g., settlement.quote) for comparison, so it lacks explicit 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. The description adds valuable behavioral context: data source (central bank rates via open.er-api.com), update frequency (hourly), no API key requirement, and cost (free). No contradictions 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?

Three sentences, front-loaded with purpose, then return fields, then sourcing/cost. Every sentence earns its place with no redundancy.

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

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

With an output schema providing return field details and annotations covering safety, the description additionally specifies data source, freshness, and authentication requirements. For a simple 2-param read-only tool, this is fully sufficient.

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?

Input schema covers both parameters (from, to) with clear ISO 4217 descriptions (100% schema coverage). The description adds minimal parameter meaning beyond saying 'any currency pair'—no new syntax or constraints—so it meets the baseline but does not exceed.

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?

Purpose is clear: 'Live mid-market FX rate for any currency pair' with specific outputs listed (mid rate, bid/ask spread, volatility, flags, freshness). However, it does not explicitly distinguish itself from sibling tools like fx.corridors or market.fx, so it misses the full 5 for 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?

The description implies when to use the tool ('Live mid-market FX rate for any currency pair') and adds practical context (free, no API key, hourly updates). It does not provide explicit 'when not to use' or name alternatives, so it 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?

Beyond the readOnlyHint/idempotentHint annotations, the description adds meaningful context: it mentions the specific USDC amount, chain, the transition from pending to verified, and the inclusion of a txHash and Basescan link. This enriches the agent's understanding of the polling 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 three concise sentences, front-loaded with the action ('Check the status'), and every sentence contributes value—explaining the mechanism, return values, and polling frequency.

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 polling tool with strong annotations and an output schema, the description covers the process, expected states, and usage cadence. It is complete enough for an agent to invoke it correctly without further clarification.

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 'id' is fully described in the schema as 'verificationId returned by integration.verify.' The description itself does not add extra information about how to use the parameter, so the schema carries the full semantic load.

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

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

The description clearly states 'Check the status of a DPX integration verification session' and details the specific behavior of returning 'pending' vs 'verified' with a txHash and explorer link. This distinguishes it from sibling tools like integration.verify.

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

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

It explicitly instructs to poll every 10–15 seconds after sending the payment and explains the condition for verification (receipt of $0.01 USDC on Base mainnet). However, it does not explicitly name integration.verify as the alternative or state when not to use this 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 explains the handshake flow: client sends $0.01 USDC on Base mainnet, returns treasury address and instructions, and requires status polling. This adds context beyond the annotations, which only indicate the tool is not read-only, idempotent, or destructive. It doesn't disclose failure modes or idempotency consequences, but annotations already cover the safety profile.

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 three clear sentences, front-loaded with the action and purpose, with no filler. Each sentence adds value: initiation, return, and follow-up.

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 initiation step, expected client action, network/currency, return value, and the follow-up polling step. With an output schema present, return values are further specified. It could mention failure/timeout scenarios but is quite complete for a simple initiation 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?

Both parameters are fully described in the schema (100% coverage), so the baseline is 3. The description doesn't add parameter-specific semantics beyond the schema, such as address format or API key handling, which are already covered in the schema descriptions.

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 it initiates a $0.01 USDC onboarding handshake for a new DPX integration, which is a specific verb+resource+scope. It also distinguishes itself from integration.status by noting that status polling is a separate step.

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 explicitly states this is required for all new integrations before production settlements and directs the user to call integration.status to poll for confirmation. This provides clear when-to-use and a related alternative, though it doesn't explicitly list when-not-to-use 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 behavior. The description adds rich behavioral context on wave timing, node status classification (rebounding, amplified pressure, structurally altered), which goes beyond annotation 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?

Every sentence adds value: purpose, wave breakdown, output insights, and companion ordering. The POST method note is mildly redundant but doesn't detract from the concise, structured format.

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 an output schema present, the description doesn't need to detail return formats. It covers the tool's purpose, input semantics, wave outputs, and workflow context, making it complete for an agent to invoke 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 covers all 5 parameters with descriptions (100% coverage), so the description doesn't need to compensate. It restates origin, eventType, magnitude, elapsedHours but adds no new meaning beyond what the schema provides.

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

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

The description clearly states the tool models secondary waves after a primary cascade event, with specific time horizons (0–72h, 1–4 weeks, 1–6 months). It names market.cascade as a companion, distinguishing its role in the workflow.

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?

Explicitly says 'run cascade first, then aftershock' which tells the agent exactly when to use this tool relative to market.cascade. It also describes what outputs to expect, helping the agent decide if this is the right intelligence 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?

With annotations already marking readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: the R-value interpretation (R < 1.0 vs ≥ 1.0), concrete return items (R trajectory, spread map, superspreader nodes, containment forecast, AI briefing), and a prerequisite call. This goes far beyond the structured 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 ~70 words across four sentences, front-loaded with the primary purpose. Each sentence adds substantive information (model, output, interpretation, prerequisite), though it could be slightly restructured for scannability.

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 an output schema and safety annotations present, the description provides a full picture: the model, domain coverage, R-value threshold, output items, and prerequisite call. This is more than sufficient for an agent to decide and invoke correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds a workflow hint (call listNodes first) and says 'POST with origin and magnitude', but does not add additional semantic meaning beyond the schema's parameter descriptions.

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 'simulates how a macro or financial shock spreads' — a specific verb and resource — and details unique aspects (30 nodes, 6 domains, R-value model), distinguishing it from sibling intelligence 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?

It explicitly instructs to 'Call /contagion/nodes first to discover valid origin IDs' and notes 'POST with origin and magnitude', providing a clear workflow. However, it does not name alternative tools for similar contagion simulations, so no explicit when-not-to-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 read-only, idempotent, and non-destructive behavior, lowering the bar. The description adds valuable context: live FRED feedback, data sources (WHO GHO, World Bank WDI, FRED), a 12h cache, and the transmission mechanism linking GBV to GDP drag and sovereign risk. These details go beyond the annotations and set clear expectations for data freshness and source reliability.

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 dense but every clause earns its place: it explains the core mapping, the two scores, their implications, additional features (live FRED, AI synthesis), data sources, cache, and input requirements. It is structured as a single informative block, front-loaded with the tool's purpose, and avoids filler. The length is justified by the conceptual 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?

Given that the tool takes no inputs, has a clear output schema (implied), and benefits from a rich annotation profile, the description fully covers the context needed for selection and invocation. It explains what the scores mean, how they relate to economic outcomes, what data is used, and the cache behavior. There is no ambiguity about the tool's scope or output semantics.

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, the rubric baseline is 4. The description explicitly states 'No input required', confirming the tool takes no arguments. That adds no further semantic meaning since the schema already shows an empty properties object, but it reinforces the fact. No parameter list exists to elaborate, so a 4 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 tool's function with specific verbs ('maps', 'returns') and distinct output (two scores: gbvRiskScore and opportunityScore). It explicitly distinguishes from sibling tools by focusing on gender-specific risk and opportunity across 18 countries, making its purpose 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?

The description provides strong context for when to use this tool—when assessing sovereign risk related to GBV prevalence, legal discrimination, and female labour force participation. It implies usage via the detailed data scope, but lacks explicit exclusion criteria or mention of alternatives. The 'No input required' clarifies invocation, but no direct comparison with sibling intelligence tools 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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond this: it specifies 'No input required — GET,' and details the exact return payload (per-signal phase angles, resonance clusters, amplification factor, system resonance score, historical comparison). This goes beyond the minimal annotation coverage.

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

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

The description is dense and front-loaded with the core purpose, then elaborates with a vivid analogy and a clear enumeration of outputs. While slightly long, every sentence contributes functional or contextual information, and the structure flows logically from purpose to behavior to output. The final GET note is economical.

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 and a rich output schema, the description is fully complete: it explains the conceptual trigger, the signal scope (28 signals, 5 domains), the amplification concept, the exact return fields, and the historical comparison references. The description leaves no material questions about when or how to 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?

The tool has zero parameters, so the baseline is 4. The description reinforces this with 'No input required — GET,' leaving no ambiguity about invocation. There is no schema-level parameter detail to compensate for, and the description adds sufficient clarity for a parameterless tool.

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 a specific verb-resource pair: 'detects when multiple independent macro forces are oscillating in phase,' clearly identifying what the tool does. It further distinguishes itself by contrasting a single shock with resonance and explicitly listing the output categories, making it distinct from sibling tools like intelligence.contagion or intelligence.aftershock.

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 usage for detecting systemic resonance ('detects when multiple independent macro forces are oscillating in phase'), and the phrase 'A single shock is manageable; resonance turns a bad quarter into a systemic crisis' gives conceptual context. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, leaving the comparative guidance 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?

The description adds meaningful behavioral context beyond the annotations, explaining that the webhook is edge-triggered (fires once on crossing) and checked hourly, and that it returns a subscriptionId for later management. This goes beyond the basic read-only/idempotent/destructive hints and provides useful operational detail.

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, with only four sentences: purpose, supported signals, trigger behavior, and use cases. It is well-structured, front-loaded with the main action, and every sentence provides useful information without redundancy.

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

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

For a webhook subscription tool, the description covers purpose, trigger behavior, supported signals, return value, and use cases. The output schema presumably handles return structure details. It lacks some advanced details like webhook authentication or retry behavior, but these are not essential for tool selection and invocation.

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

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

The input schema already provides full descriptions for all 5 parameters (100% coverage), so the baseline is 3. The description reinforces the threshold score range and signal types but does not add significant new meaning beyond what the schema already states.

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 ('Register') with a clear resource (webhook) and scope (DPX intelligence signal crossing a threshold). It also lists supported signals, which distinguishes it from sibling subscription management tools like intelligence.subscription.get and intelligence.subscription.delete.

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 explicitly names relevant use cases ('treasury alert systems, TMS integrations, or autonomous agent monitoring loops'), providing clear context for when to use the tool. However, it does not explicitly contrast with alternatives or state when not to use it, so it falls 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 indicate destructive and idempotent behavior. The description adds valuable context beyond those annotations: it explicitly states the effect on webhook alerts and that the alert log is retained for audit purposes, giving users confidence about what is destroyed and what is preserved.

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 concise sentences, front-loaded with the primary action and followed by important behavioral details. No unnecessary words.

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

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

For a simple one-parameter delete operation with an output schema and informative annotations, the description covers key contextual aspects: what stops, what remains, and audit implications. It is complete enough for an agent to select and 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 input schema already provides full coverage for subscriptionId with a clear description ('UUID returned by intelligence.subscribe'), so the description adds no additional parameter meaning. 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 uses specific action verbs ('Cancel', 'Stops') and clearly identifies the resource ('intelligence subscription by ID'). It distinguishes from siblings like intelligence.subscribe and intelligence.subscription.get by specifying that it stops future webhook alerts.

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 it: when you want to stop future webhook alerts for a subscription. However, it does not explicitly mention alternatives or exclusions, though the context is clear and the sibling tools (subscribe/get) provide implicit contrast.

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 the safety profile. The description adds context about the return payload (signal score, last fired timestamp, alert count, configuration), which goes slightly beyond annotations. However, it does not disclose any additional behavioral aspects like pagination, auth requirements, or side effects. With annotations in place, a 3 is appropriate.

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, front-loaded with the core purpose, and includes only essential details. Every sentence earns its place: the first states the action, the second enumerates the return values and the usage context. No filler or redundancy.

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

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

For a simple read-only get operation with one parameter, an output schema, and clear annotations, the description is complete. It states the operation, usage context, and key return fields. There are no missing elements that would hinder correct tool invocation.

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

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

The schema has 100% coverage with a single parameter `subscriptionId` described as 'UUID returned by intelligence.subscribe.' The description's phrase 'by ID' is consistent with the schema but does not add extra meaning beyond what the schema already provides. Baseline 3 is correct because 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 opens with a specific action and resource: 'Check the status of an intelligence subscription by ID.' It clearly identifies the operation and distinguishes it from sibling tools like subscribe/delete by focusing on status retrieval. It also enumerates the return fields, reinforcing its 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?

The description provides explicit context on when to use the tool: 'Use after intelligence.subscribe to verify a subscription is active.' This tells the agent the typical workflow placement. It does not explicitly list alternatives or exclusions, but there are no obvious alternative tools for this specific status check, and the guidance is clear enough.

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 beyond this by specifying the HTTP method (GET), confirming no input, and detailing the returned artifact (per-node stress state, rupture sequence, horizon timeline, AI synthesis briefing). No contradictions 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 packs comprehensive information into a compact paragraph: purpose, data model, comparison with sibling, output, and invocation details. Every sentence adds value, and there is no tautology or superfluous text.

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 intelligence tool with an output schema, the description covers domain (5 domains, 22 fault lines), key data points (stress, accumulation rate, threshold, years to rupture), output structure, and the contrast with market.cascade. It is sufficient for an agent to decide whether to invoke and what to expect.

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 an empty schema, the description explicitly states 'No input required — GET,' removing any ambiguity about hidden parameters. This exceeds the baseline for 0-parameter tools by explicitly confirming that no input 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 defines the tool as mapping slow-moving structural stress across 22 fault lines in 5 domains, with the specific verb 'maps' and resource 'structural stress.' It distinguishes itself from sibling market.cascade by contrasting acute shocks with latent pressure, and from other intelligence tools by focusing on structural domains.

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?

Provides explicit usage guidance by contrasting with market.cascade: 'Where market.cascade traces an acute shock, tectonic surfaces latent pressure before it ruptures.' This signals when to choose this tool (latent/structural risk) versus an alternative. The statement 'No input required — GET' also clarifies invocation.

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 minimal annotations (all false hints), the description carries the main transparency burden. It adds meaningful behavioral context: the invoice expires after ttlSeconds (default 24h) and the tool returns an invoiceId and payUrl. This goes beyond the annotations but does not cover potential side effects or failure modes, so a 4 is appropriate.

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 and front-loaded: the first sentence states the core purpose, followed by the workflow, return values, and expiration. Every sentence adds distinct value with no redundancy or fluff.

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 gives a complete workflow context for a tool with 7 parameters and an output schema: it explains the agent-to-agent payment flow, the return values, and the expiration behavior. The schema fills in parameter details and the output schema defines return structure, so the description does not need to repeat that. Minor edge cases (e.g., currency behavior or callbackUrl) are not detailed, but that's acceptable given the schema's 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?

All 7 parameters have schema-level descriptions (100% coverage), so the schema already provides parameter semantics. The description only mentions the ttlSeconds default, which is also in the schema, and adds no new meaning for the parameters. 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 action ('Create an agent-to-agent invoice') and the resource it acts on, with a clear statement of the caller's role ('Agent A calls this to request payment from Agent B'). It explicitly positions the tool against sibling tools by referencing invoice.pay as the settlement step, making its purpose unambiguous.

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

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

The description clearly specifies when to use the tool ('Agent A calls this to request payment from Agent B') and the complementary use of invoice.pay for the payer. However, it does not explicitly mention when to avoid using this tool (e.g., when an invoice already exists, use invoice.get), so it stops short of a perfect score.

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 value beyond annotations by specifying return fields (status, amount, currency pair, payUrl) and the practical implication that the invoice must be OPEN for payment, enriching the behavioral context.

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

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

The description is two concise sentences, front-loaded with the core action and resource, followed by useful return-value details and usage guidance. Every sentence earns its place with no filler.

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

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

The tool is simple (one required parameter, one resource) and the description covers what it does, what it returns, and when to use it. Combined with strong annotations and full schema coverage, no essential information 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?

The input schema already provides 100% coverage for the single parameter 'invoiceId', describing it as 'Invoice UUID returned by invoice.create'. The description does not add further parameter detail, so the baseline score 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 uses the specific verb 'Retrieve' with the resource 'agent-to-agent invoice by ID', and explicitly lists what it returns (status, amount, currency pair, payUrl). This clearly distinguishes it from sibling tools like invoice.create and invoice.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?

The description provides explicit usage guidance: 'Use before calling invoice.pay to confirm the invoice is still OPEN.' This tells the agent when to invoke it relative to a related action. It could be clearer about when not to use it, but for a simple retrieval tool this is sufficient 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?

The description richly details behavior beyond sparse annotations: it retrieves the invoice, calls POST /settle, and marks the invoice PAID. It explicitly states the side effect (state change) and mode-dependent return values (simulated receipt vs. execution parameters). This fully informs an agent of the tool's runtime 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 two sentences with zero wasted words. The first sentence states purpose and steps; the second covers mode behavior. Information is front-loaded and every sentence earns its place.

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

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

Given the tool's low complexity (three params, output schema available), the description covers core behavior and output differences. However, it omits preconditions (e.g., invoice must be in a payable state, recipientAddress may be optional) and does not reference the output schema. Slightly incomplete but generally sufficient.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-level details beyond what the schema already provides (e.g., sandbox default, invoiceId UUID, recipientAddress condition). No additional usage context or format hints are given.

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 purpose: pay an agent-to-agent invoice by ID. It explains the multi-step process (retrieve, settle, mark paid) and distinguishes between sandbox and live modes. However, it does not differentiate from sibling tools like settlement.execute or batch_settle that might handle similar payment logic.

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 (e.g., settlement.execute, card.settle, ramp.settle). It does not state prerequisites (e.g., invoice must exist and be unpaid) or scenarios where another tool would be preferable. The sandbox/live distinction is helpful but addresses environment not tool selection.

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 description is not responsible for safety disclosure. It supplements by explaining the aggregated output and its chronological nature, adding behavioral context beyond annotations. No contradictions exist.

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, starting with the primary action and result, then adding supporting output details and use cases. Every sentence contributes value with no redundancy or 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?

No output schema exists, so the description appropriately explains what is returned (total USD moved, transaction count, chronological list). For a simple read-only tool with one parameter and strong annotations, this description fully covers purpose, output, and applicable contexts.

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

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

Schema coverage is 100%; the only parameter 'session_id' is clearly described in the schema as 'Session or task ID — the same ID used in receipt.create calls'. The description does not add further parameter-level detail, which is acceptable given the schema's sufficiency, so baseline 3 is appropriate.

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

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

The description starts with a specific verb 'Get' and clearly defines the resource as 'the aggregated payment graph for a multi-agent session'. It enumerates exact outputs (total USD moved, transaction count, chronological list) and explicitly contrasts with use cases like cost accounting and audit, distinguishing it from siblings such as receipt.create and compute.cost.

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 explicit use cases: 'Use for cost accounting, audit, or to show a human what an agent run spent.' This gives strong contextual guidance, though it does not explicitly name alternative tools or state when not to use this tool, so a perfect score is not warranted.

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 known. The description adds valuable behavioral context beyond this: it describes the modeling approach (shock propagation, time-ordered cascade, attenuated signal strength, AI synthesis), the coverage (24 nodes, 4 domains), and explicitly states what it does NOT do ('no settlement or stablecoin mechanics'). This goes beyond what annotations convey.

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 dense but well-structured. It opens with the core function, then provides a complete enumeration of nodes and domains, and ends with a clear scope delimiter. While it is lengthy, each sentence adds relevant detail (especially the node list, which is crucial for usability). The front-loaded core function makes the purpose immediately clear, and the final sentence disambiguates from settlement tools.

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 (5 optional parameters, an output schema, and multiple sibling intelligence tools), the description is remarkably complete. It explains what the tool does, the domain coverage, the output format (time-ordered cascade chain, AI synthesis briefing), and how to discover valid origin IDs via listNodes. The presence of an output schema means return values need not be spelled out, and the description covers all essential usage aspects.

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%: each of the five parameters includes a detailed explanation with examples in the input schema. The description itself does not add much parameter-level meaning beyond reiterating the origin event and magnitude score. With full schema coverage, the baseline of 3 is appropriate; the description neither compensates for gaps nor presents conflicting 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 clearly states the tool's function with a specific verb ('models how a shock propagates') and a well-defined resource (macro domain cascade intelligence). It enumerates the 24 nodes across 4 domains, uses concrete examples, and explicitly distinguishes itself from settlement/stablecoin tools with the closing phrase 'Purely macro intelligence — no settlement or stablecoin mechanics.' This makes the tool's purpose unmistakable and distinct from siblings.

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

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

The description provides usage guidance through the parameter descriptions (e.g., 'Call market.cascade with listNodes:true first', 'Use 24 for immediate cascade, 720 for full 30-day view') and the scope statement 'no settlement or stablecoin mechanics' gives an exclusion. However, it does not explicitly compare this tool to alternative sibling intelligence tools like intelligence.contagion or intelligence.aftershock, leaving the 'when to use vs alternatives' guidance implicit rather than explicit.

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