DPX — Institutional Cross-Border Settlement

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

The description goes beyond the annotations by explaining the actual runtime behavior: DPX calls the public GLEIF API, checks ACTIVE status, grants tiers instantly, and requires no documents or manual review. It also discloses the legal basis and cap limits, which helps an agent anticipate side effects. It does not, however, describe failure modes (e.g., invalid LEI) or authorization requirements, so it is not a perfect 5.

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

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

The description is long, but every sentence adds functional value about tier characteristics, caps, or compliance rationale. It uses clear labels (ANONYMOUS, REGISTERED, VERIFIED) and a logical progression from simple to complex tiers. The length is justified given the regulatory complexity, though it could be slightly more scannable with explicit bullet points.

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, a nested mandate object, and an output schema, the description provides a comprehensive overview of the tool's behavior, including caps, legal basis, and verification process. It does not explain the return value structure (but the output schema likely covers that) and omits edge-case behavior, but for a registration tool with this complexity, it is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds significant semantic meaning by mapping parameters to tier requirements: ownerEntity and ownerEmail are required for REGISTERED, ownerLei grants VERIFIED, and name is the only mandatory field. It also clarifies that mandate caps are clamped to tier limits for REGISTERED agents, which is not evident from the schema alone.

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

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

The name 'agent.kya_register' plus the description's detailed explanation of the three-tier KYA registration model make the tool's purpose unmistakable: registering an agent under KYA. It explicitly describes the outcome of registration (instant tier grants, caps, compliance inheritance) and is easily distinguished from the sibling 'agent.kya_verify', which presumably checks KYA status rather than creating it.

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 guidance on when to use each registration tier: ANONYMOUS for instant low-cap registration, REGISTERED for higher caps with self-attested entity info, and VERIFIED for institutional caps via LEI. However, it does not explicitly state when not to use this tool or directly compare it with alternative tools like kya_verify, leaving room for ambiguity for an agent deciding between registration and verification.

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 substantial behavioral context beyond the annotations. It explains the credential's 1-hour expiry, the exact headers to attach, and the downstream effects (mandate enforcement, audit trail, FATF attestation). This is valuable and does not contradict the readOnlyHint=true annotation.

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 structured logically: purpose, return values, usage instructions, and expiry. It is detailed but every sentence provides necessary information. It is slightly long, but not wasteful, so a 4 is fitting.

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

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

Despite having an output schema, the description nonetheless enumerates the key return fields, gives clear usage instructions, and covers the credential's lifecycle. It fully equips an agent to invoke and apply the result correctly, and it aligns with the tool's 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?

The input schema already fully describes the single parameter (agentId) with 100% coverage, including its format and origin. The description adds only implicit context (the agent must be registered), providing marginal added value beyond the schema. 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 the tool's verb ('verify'), resource ('registered DPX agent'), and outcome ('receive a signed 1-hour credential'). It goes beyond a simple label to define the tool's function, and it is distinct from the sibling tool 'agent.kya_register', which handles registration. The listed return values further clarify the purpose.

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

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

The description explicitly states when to use the tool: before DPX /settle requests, with instructions to attach the returned headers. It also says to call again before expiry to refresh. However, it does not name alternatives or explicitly state when not to use it, so it falls short of a perfect 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 are generic (readOnlyHint false, etc.), so the description carries the burden. It discloses key behaviors: anonymous agents are blocked, registered agents have caps clamped to $25K, verified agents have no ceiling, and mandates are AP2-formatted. It does not explicitly state overwrite behavior for updates, but it does add meaningful context beyond annotations.

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

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

The description is a single dense paragraph that leads with the primary purpose and then efficiently lists settable constraints. It is not overly verbose, though it could be more structured with line breaks. Every sentence contributes useful information.

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

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

Given the tool has an output schema (not shown) and 8 parameters with full schema descriptions, the description covers the essential context: eligibility, tier-based limits, and AP2 interoperability. It does not detail return values, but the output schema covers that gap. It is complete enough for an expert to use 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 coverage is 100%, so baseline is 3. The description adds value by tying parameters to the agent tier system (e.g., caps clamped vs. no ceiling) and clarifying the purpose of whitelist, currency pairs, ESG floor, and expiry. This enriches the schema descriptions without repeating them verbatim.

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 creates or updates an AP2-compatible spend mandate for registered or verified DPX agents, with a specific verb and resource. It lists the constraints it sets, distinguishing it from sibling agent registration/verification 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 provides clear context on when to use the tool: only for REGISTERED or VERIFIED agents, and explicitly states ANONYMOUS agents cannot hold mandates, requiring registration first. It implies alternatives (agent.kya_register) but does not explicitly exclude 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 readOnlyHint=true and destructiveHint=false. The description adds behavioral context by specifying it returns 'live' data 'across all data sources' and lists specific metrics, giving agents a picture of output scope without contradicting annotations.

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

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

Two sentences: the first identifies the verb and resource, the second lists outputs and use cases. No filler or redundancy; front-loaded with 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?

With an output schema present and read-only annotations, the description fully covers purpose, output content, and use cases. Given it has no inputs, the description is complete for an agent to select and invoke the tool.

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

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

The tool has zero parameters, so the empty input schema is fully covered and the description cannot add parameter-level detail. Baseline for zero-param tools is 4.

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

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

Description clearly states 'Get live DPX performance analytics' with a specific verb and resource, and enumerates returned metrics (stability score, ESG composite, fee breakdown, oracle health, settlement readiness). This distinguishes it as a high-level overview aggregator from more specific siblings like dpx.metrics and esg.score.

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

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

Explicitly states use cases: 'Use for dashboards, reporting, and AI-driven monitoring of protocol health.' This provides clear context for when to select the tool, though it does not mention alternatives or exclusions.

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

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

No annotations convey behavior beyond read-only/destructive hints (all false), so the description carries the burden. It discloses concurrency and partial-failure semantics ('one failure does not block others'), the return summary format, and the 50-item limit. This goes beyond the schema's maxItems by explaining runtime behavior, though it does not mention idempotency or reversibility.

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 clear lead purpose, followed by behavioral and limit information. No wasted words; each sentence contributes distinct 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?

Description covers the core purpose, concurrency behavior, failure isolation, response summary structure, and batch limit. Given the presence of an output schema and simple single-parameter input, this is sufficient context for an agent to invoke correctly. It could be strengthened by explicit guidance on when to prefer it over a single settle call, but overall is complete.

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

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

The schema already covers the single 'settlements' parameter with 100% description coverage, including item structure. The description adds the 50-item batch ceiling (also in schema as maxItems) and references the settle tool's schema, but no additional field-level meaning 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 states 'Submit multiple settlements in a single call' with a specific verb and resource, clearly identifying a batch operation. It distinguishes itself from single-settlement siblings by calling out batching and referencing 'per-item results mirroring what POST /settle would return.'

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 multiple settlements need to be processed together via a single API call, with a clear batch context. It does not explicitly name single-settle alternatives or state exclusions, but the batching purpose is unambiguous.

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, open-world, and non-destructive behavior. The description adds valuable context: the exact output fields (confidence, role, nationality, entities, risk level), the risk-level categories, and the FATF policy implication. 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 four sentences covering purpose, definitions, outputs, and policy. It is front-loaded with the main action and all sentences provide useful information. Slightly verbose in listing PEP categories, but each 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?

The description covers the tool's purpose, input parameters, output contents, risk-level semantics, and policy implications. Combined with the rich annotations and output schema, it fully enables an agent to select and invoke the tool correctly. 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 already provides full descriptions for both q and country (100% coverage). The description only adds 'Optionally filter by country,' which is minimal additional meaning. Baseline 3 is appropriate since the schema carries the parameter semantics.

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

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

The description clearly states the tool screens an individual by name against the OpenSanctions PEP dataset, listing specific types of PEPs and returning risk levels. This distinguishes it from other compliance tools like compliance.ubo_chain or compliance.regulatory_calendar, making the 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 clear context for when to use the tool (PEP screening) and even specifies that HIGH/MEDIUM matches require Enhanced Due Diligence before settlement. It does not explicitly contrast with sibling tools, but the unique PEP dataset and policy trigger make usage expectations 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?

The annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral context by detailing the output fields (framework, jurisdiction, effective date, etc.) and the DPX alignment section, giving agents a clear expectation of the return value. It does not mention auth requirements or rate limits, but those are less critical given the read-only nature.

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 earning its place: the core result, detailed output fields, the DPX alignment section, and specific use cases. It is front-loaded with the verb and resource, avoids redundancy, and is appropriately sized for the complexity of the tool.

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

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

Given the tool has no parameters, clear annotations, and an output schema (as indicated), the description is complete. It covers all necessary aspects: what the tool returns, what data is included, and when to use it. There is no missing information that would leave an agent uncertain about 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 tool has zero parameters and an empty input schema, so the baseline for parameter semantics is 4. The description appropriately does not need to explain any parameter meaning, and it does not attempt to, which is correct given the schema coverage is 100%.

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 across specific named regulations (MiCA, SFDR, CSRD, GENIUS Act, FATF). The verb 'returns' and the resource 'structured calendar' are explicit, and the listing of frameworks distinguishes 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?

The description explicitly says to 'Use this before settlement workflow design, compliance gap analysis, or regulatory reporting,' providing clear context for when to invoke the tool. It does not state when not to use it or mention alternative tools, so it lacks the full exclusion and alternative guidance seen in top-tier descriptions.

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 substantial behavioral context: the 3-level depth, data sources (GLEIF, OpenSanctions), output structure, verdict types, and FATF attestation. This goes well beyond the annotations.

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

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

The description is a dense paragraph but well-structured: first sentence describes the action, second lists return values, third lists compliance contexts. It is appropriately sized for a complex tool and every sentence adds value, though slightly long for the simplest consumer.

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?

Even with an output schema present, the description fully explains what the tool returns: chain structure, per-node sanctions status, LEI lapse flags, overall verdict, and FATF attestation. It also covers data sources, depth, and use cases, making it complete for a compliance 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?

The input schema already covers both parameters with 100% description coverage: 'lei' and 'deep'. The description mentions 'up to 3 levels deep' but does not directly clarify the 'deep' parameter beyond what the schema states. Baseline 3 is appropriate since 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 uses a specific verb ('Trace') with a clear resource ('beneficial ownership chain') and adds the screening component. It clearly distinguishes itself from sibling tools like compliance.pep_screen by focusing on entity chains and GLEIF data rather than individual PEP 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 explicitly states when the tool is required: correspondent banking due diligence, FATF R.12/13 UBO identification, and MiCA Article 72 counterparty risk management. It provides clear context but does not explicitly mention alternatives or 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by noting it runs 'without running inference,' returns strengths/speed tier/alternatives, and is 'Free.' No contradiction with annotations.

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

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

The description is two sentences, front-loaded with the main purpose. Every sentence adds value: what it returns, when to use it, and that it's free. No wasted words.

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

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

For a simple read-only tool with two parameters and no output schema, the description covers the return contents (best free model, strengths, speed tier, alternatives) and usage context. 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%, so parameters are fully documented in the schema. The description does not add extra meaning beyond the schema (e.g., task examples are in schema). 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's function: 'Get a model recommendation for a task type without running inference.' It specifies the resource (model recommendation), the action (get), and distinguishes from inference tools. The phrase 'best free model' and listing of alternatives adds specificity.

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 when-to-use guidance: 'Use this when an agent needs to select a model before committing to inference, or to surface model selection logic to a human.' It does not explicitly name alternative sibling tools like compute.models or compute.route, but the context is 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is covered. The description adds meaningful behavioral context by specifying that all models are free-tier, routed via OpenRouter, and by detailing the fields returned. This goes beyond basic annotations, though it omits potential details like pagination or rate limits, which are not critical for a simple list operation.

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 main action, followed by cost/routing details, return fields, and usage guidance. Every sentence provides valuable information 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?

For a simple, parameterless list tool, the description fully covers what is returned, the routing context, the cost implication, and how to use it before compute.route. It is complete given the lack of params and 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?

There are zero parameters, and schema coverage is 100% (no params to document). The description therefore cannot add parameter semantics, but the baseline for zero-param tools is 4. The description does enrich understanding of what the tool outputs, which partially compensates for any lack of param info.

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 and resource: 'List all AI models available through DPX Compute.' It clearly distinguishes this tool from siblings like compute.route (routing) and compute.cost by focusing on model discovery and providing details like 'model IDs, provider, capability strengths, context window, and speed tier.'

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 compute.route to understand what models are available and pick the right one for a task.' This names a specific sibling and gives a clear when-to-use directive. It also notes that models are free-tier, which affects cost-related decision-making.

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 readOnly=false and idempotent=false, but the description adds valuable context: it calls OpenRouter, has a payment mechanism in USDC via x402, and returns the completion. These details go beyond the annotations and help the agent understand side effects and costs.

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 every sentence adds value. It covers purpose, model selection logic, external call, cost, and usage context without wasting 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 tool that invokes an external AI service with payment, the description is remarkably complete. It explains the routing algorithm, the external service (OpenRouter), cost model (free-tier but pay per call in USDC), return value, and appropriate use case. No output schema exists, but the description adequately covers what the agent needs to know.

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 good descriptions for each parameter, giving a baseline of 3. The tool description adds extra semantics by mapping task types to specific models (e.g., 'reasoning → DeepSeek R1') and explaining that preferSpeed overrides this. This enriches parameter 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 uses a specific verb and resource ('Route a task to the best available free AI model and run inference'), clearly distinguishing this from siblings like compute.cost and compute.models. It explains exactly what the tool does, including model routing and execution.

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 the tool: 'Use this when an agent needs to delegate a subtask to a language model without managing model selection or API keys.' It provides clear context but does not explicitly mention when not to use it or name specific alternative tools, so it misses the full 'when/when-not/alternatives' bar.

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 context beyond the annotations by disclosing the multi-step flow: 'DPX runs the full oracle gate → compliance screen → settlement flow' and that it 'Returns a receipt.' This is useful behavioral detail. No contradiction with annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true) is present.

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

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

The description is compact, front-loaded with the core purpose, and every sentence earns its place: purpose, examples, key instruction, behavioral flow, and usage trigger. 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?

For a payment tool with output schema and annotations, the description covers the essential aspects: what it does, when to use it, what inputs to provide, the internal flow, and the return value. It could mention prerequisites (e.g., that it requires an active computer use session), but this is reasonably implied. The description is complete enough for an agent to select 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 coverage is 100%, so the baseline is 3. The description restates that the user should 'provide the amount and recipient' and 'Describe what you see on screen,' but does not add new meaning beyond the schema's already-detailed parameter descriptions (e.g., screen_context is 'Used for audit trail'). It does not compensate with additional semantic 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 opens with a specific verb+resource: 'Complete a payment' and immediately scopes it to computer use sessions with concrete examples (checkout form, wire transfer UI, invoice approval, vendor portal payment step). It also distinguishes this tool from typing credentials into a UI and from settlement.nl, making its purpose unmistakable among 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?

Explicit usage guidance is provided: 'Call this instead of typing credentials into a UI' and 'Use whenever computer use encounters a payment that would otherwise require human re-entry or approval.' It also gives an exclusion/alternative: 'If only bank/email visible, use settlement.nl instead.' This clearly indicates when to use this tool versus alternatives.

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

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

Annotations already declare read-only, idempotent, and non-destructive hints. The description adds valuable context beyond annotations: data source (production telemetry), live nature, and no-auth requirement. 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 concise, front-loaded sentences. First sentence states the purpose, second lists outputs, third covers use cases and auth. 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 metrics tool with a single optional parameter and an output schema, the description covers purpose, use cases, data source, auth, and pricing. It lacks mention of output structure, but that is covered by the output schema. Nearly complete.

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

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

Schema coverage is 100% with a well-described optional `window` parameter including enum values and default. The description does not add parameter-level detail, but the schema fully handles it, 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?

Clearly states it returns live performance metrics for the DPX settlement infrastructure, listing specific metrics (request volumes, error rates, growth trends, per-service breakdown, spike analysis). This distinguishes it from sibling tools like analytics.overview by focusing on DPX-specific production telemetry.

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 mentions target use cases (investor due diligence, analyst queries, Standard Metrics integrations) and states it requires no auth, providing clear context. However, it does not mention when to prefer this over alternatives or any exclusions, 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 read-only and non-destructive behavior. The description adds valuable behavioral context: the 50-entity limit, the ranking by composite ESG score descending, and the speed trade-off between LEI and name inputs. 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?

Three sentences, front-loaded with the core action. Every sentence adds information: the batch capability, input types, ranking, use cases, and performance caveat. 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 batch screening tool with an output schema, the description covers the main behavior, use cases, and trade-offs. It could mention that at least one of leis/names should be provided, but the schema already leaves both optional and the description implies either is acceptable.

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 document the two parameters well (LEIs fast, names resolved via GLEIF). The description adds meaning by clarifying the batch limit and the composite ESG ranking, which helps the agent decide how to use the parameters together.

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

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

The description clearly states the tool screens up to 50 entities in a single call, accepts LEIs or company names, and returns results ranked by composite ESG score. This specific verb+resource+scope distinguishes it from sibling tools like esg.lookup and esg.portfolio.

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 names use cases (portfolio-level compliance screening, supplier due diligence, TMS pre-payment checks) and provides a key caveat (name resolution is slower than direct LEI input). While it doesn't explicitly state when not to use it or name alternative tools, the context 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 this as read-only and non-destructive. The description adds valuable behavioral context beyond that: it specifies the resolution mechanism ('via GLEIF'), the exact pillar weights (40/35/25), and the return fields (composite score, fee surcharge tier, per-source breakdown). This transparency about what the tool returns and how it works is helpful and does not contradict any 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 consists of just two sentences: the first states the action and output, the second provides usage guidance. It is front-loaded, with no redundant or filler content. Every sentence earns its place, making it concise and well-structured.

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

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

Given that the tool has an output schema, the description does not need to detail return values, yet it still summarizes the key outputs (pillar scores, composite, fee surcharge tier, sources). It also addresses the context of when to use the tool and the purpose of the optional parameters. The description is complete for a lookup 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 description coverage is 100%, so the schema fully documents all three parameters. The description does not add any new meaning to the parameters beyond what the schema provides (e.g., the description does not clarify q's format or country's ISO-2 requirement; those are in the schema). Therefore, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Resolve a company name, domain, or ticker to a LEI via GLEIF and return the full ESG score.' It specifically names the resource (ESG score) and the action (resolve), and differentiates itself from siblings by stating 'Use when you have a company name but not a LEI,' which implies that tools like esg.score are for when a LEI is already available.

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 usage condition: 'Use when you have a company name but not a LEI.' It also explains the benefit for the optional country parameter ('improves match accuracy') and outlines the output components. However, it does not explicitly name an alternative tool for when a LEI is already known, relying on sibling context instead, so it stops short of a 5.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds transparency by enumerating the exact return categories (composite scores, tier distribution, fee surcharge impact, worst offenders, top performers, MiCA/SFDR flags) and the entity limit, which helps set expectations. It does not contradict annotations and provides useful behavioral context beyond them.

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

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

The description is three sentences, each earning its place. The opening sentence states the core action and constraint. The second sentence lists key returns without excessive detail. The third sentence frames the tool's canonical use case. No fluff or redundancy; structure is clean 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?

Given the output schema exists, the description doesn't need to detail every field, and it adequately covers purpose, limits, and return categories. However, it does not mention whether at least one of 'leis' or 'names' is required (schema lists all as optional), which could confuse agents about invoking with zero parameters. Minor gap in an otherwise complete 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?

Schema coverage is 100%, so baseline is 3. The description adds beyond the schema by clarifying that inputs are 'by LEI or name' (potentially implying mutual exclusivity) and introduces the 200-entity cap, which is not in the schema. It does not deeply explain the 'label' parameter, but the schema description already covers it, so the net contribution is positive.

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 functions as a portfolio-level ESG scorer, with a specific verb ('Score') and resource ('counterparty portfolio') and scope (up to 200 entities by LEI or name). It does not explicitly differentiate from sibling tools like esg.batch or esg.score, but the 'portfolio' focus and detailed returns make 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 a clear usage context: 'canonical pre-settlement compliance check for treasury systems and TMS integrations.' It also specifies a hard limit (up to 200 entities) and input method (LEI or name). However, it does not explicitly mention alternatives or when NOT to use this tool, leaving room for ambiguity with 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 classify this as read-only, non-destructive, and idempotent. The description adds behavioral context: 'Updated hourly from 6 institutional data sources' and the exact output components (Environmental, Social, Governance scores, composite average, settlement fee percentage). 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?

The description is three sentences, front-loaded with the core purpose, followed by output composition and then data sources/use cases. Every sentence earns its place; 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 a simple optional input, clear annotations, and an output schema present, the description provides sufficient context: data freshness (hourly), authoritative sources, and regulatory use cases. The agent can confidently invoke the tool without needing return-value details.

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 the single optional address parameter clearly documented ('Wallet address (0x...) to score. Omit for protocol default.'). The description merely echoes this without adding parameter-specific syntax, edge cases, or format 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 clearly states the verb 'Get', the resource 'counterparty risk score (ESG-denominated)', and the scope 'for a wallet address or the protocol default'. It distinguishes from sibling tools like esg.batch and esg.portfolio by emphasizing 'live' and single-address scoring.

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 provides clear context for when to use: live, single-address ESG scoring, with explicit use cases (EU SFDR and CSRD compliance reporting). It does not explicitly mention alternatives or when not to use, but the single-address focus implies distinction from portfolio/batch tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds value by explaining that data accumulates through other scoring tools and by detailing the return content (score history, trend direction, delta). This goes beyond the structured metadata and clarifies the data's provenance, which is useful 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 sentences, front-loaded with the core action, followed by return details and use cases. Every sentence contributes value without redundant repetition of schema or annotation information. Efficient and well-structured.

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

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

For a relatively simple tool with two parameters and an existing output schema, the description covers the purpose, data source behavior, return values, and practical applications. It is self-contained and provides enough context for an agent to decide when and how to invoke the tool. No significant gaps.

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

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

Both parameters (lei and days) are fully described in the schema with 100% coverage. The description only references 'by LEI' and 'requested window', neither adding meaningful detail beyond the schema. Since schema coverage is high, baseline 3 applies; the description does not substantially enhance parameter understanding.

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: 'Get the historical ESG composite trend for a specific entity by LEI.' This clearly distinguishes it from sibling tools like esg.score (likely current score), esg.lookup, esg.batch, and esg.portfolio by focusing on historical trend 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 provides concrete use cases: due diligence, MiCA Article 72 monitoring, and detecting degrading ESG posture. It also explains that data accumulates from esg.lookup, esg.batch, or esg.portfolio, which frames when this tool is relevant. Missing explicit 'when not to use' or direct sibling comparisons, but the context is 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?

The description goes well beyond the annotations. It discloses that DPX checks daily, the threshold condition for webhook firing, the return value (watchId) for status checks/cancellation, and the webhook payload structure. This is rich behavioral context that the annotations (only hint flags) do not provide. 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?

Four sentences deliver purpose, mechanism, regulatory context, return value, and webhook payload without waste. The description is front-loaded with the core action and stays focused. Every sentence contributes value, making it concise yet comprehensive.

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 monitoring registration tool, the description covers the full lifecycle: registration, monitoring frequency, trigger condition, return identifier, and webhook behavior. The output schema exists, so detailed return formatting is not needed. Given the tool's complexity and good schema/annotations, 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 coverage is 100%, but the description adds meaningful context: it ties thresholdPoints to the trigger condition ('shifts by ≥ thresholdPoints'), explains webhookUrl's role in receiving alerts, and clarifies that the return watchId is for status/cancellation. This enhances understanding beyond the schema's basic field 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 the tool's purpose: 'Register an entity for ongoing ESG monitoring.' The specific verb 'register' plus the resource 'entity for ongoing ESG monitoring' distinguishes it from one-off lookup tools like esg.score or esg.lookup. It also mentions key behavioral details (daily checks, webhook) that further differentiate it.

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: ongoing monitoring with daily checks and webhook triggers. It also cites a regulatory use case (MiCA Article 72), which helps the agent decide based on compliance needs. However, it does not explicitly mention alternatives or when not to use, though the sibling list makes the distinction implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: it mentions that rates are 'current' and 'typical', indicating variability, and that it returns compliance status in addition to savings. This goes beyond the annotation baseline without contradicting it.

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

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

The description is a single paragraph, front-loaded with the main purpose, and contains no filler. While the list of competitors is long, every item provides useful rate information, and the return values are specified. It is appropriately sized and well-structured.

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

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

With an output schema present, return values need not be detailed, and annotations cover safety. The description covers the core functionality, competitor set, and compliance outputs, making it sufficient for an agent to decide when to use it. It does not discuss edge cases like rate volatility or input validation, but these are not critical given the schema and annotations.

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 (amountUsd, hasFx, esgScore) already described clearly. The description does not add parameter-specific details beyond the schema, but it does provide overall context that helps infer how parameters might influence the comparison, which aligns with the baseline of 3.

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 'Compare' with a clear resource (DPX settlement cost) and specific competitors, making its function unambiguous. It clearly distinguishes itself from siblings like fees.schedule and fees.verify by focusing on comparison rather than schedule lookup or verification.

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 (when comparing DPX costs against alternatives) and what it returns, but it does not explicitly state when not to use it or mention alternative tools for other purposes. The context is clear, but exclusions and alternatives are not addressed.

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=false, covering the safety profile. The description adds useful behavioral context by emphasizing 'complete' fee schedule, implying a comprehensive snapshot without filtering or pagination. 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 a single well-structured sentence, front-loaded with the main verb and resource. It efficiently packs a detailed list of contents using a colon and comma-separated items, with no wasted words or redundant information. Every phrase 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?

For a zero-parameter, read-only tool, the description is highly complete. It covers all major aspects of the fee schedule: core components, volume tiers, ESG fee table, scenario examples, and competitive benchmarks. An output schema exists, so return value details are not needed in the description. This is sufficient for an agent to invoke the tool correctly.

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

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

The tool has zero parameters, so the schema fully covers parameters (100% coverage) and the description cannot add parameter semantics. Per the rubric, baseline is 4 for zero-parameter tools. The description does not need to explain parameters that do not 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's function with a specific verb ('Get') and resource ('complete DPX fee schedule'). It enumerates the exact contents (components, tiers, ESG table, benchmarks), which distinguishes it from sibling tools like fees.compare (likely comparison-focused) and fees.verify (likely verification-focused).

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 you need the complete DPX fee schedule with all components and benchmarks. However, it does not explicitly mention alternatives or when not to use it, such as whether fees.compare should be used for specific comparisons. Lacks exclusions but overall context is 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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the on-chain contract name and the boolean return value, which goes beyond the 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?

Two sentences, zero fluff. The purpose, return value, and usage timing are all conveyed efficiently. Ideal structure.

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 annotations cover safety, and the description provides workflow context and the return flag, the tool is thoroughly described. No gaps for the agent to get stuck.

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 parameters are fully documented in the schema. The description does not add any parameter-specific semantics, so baseline 3 applies.

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

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

The description clearly states the tool verifies that an off-chain fee quote matches the on-chain DPXSettlementRouter contract charge. It clearly distinguishes from siblings like fees.compare and fees.schedule by focusing on verification against the on-chain contract.

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 explicit temporal guidance: 'Call after get_quote and before settle to confirm fee integrity.' This clearly communicates when to use the tool, though it does not explicitly name alternatives or exclusion criteria, 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?

The description adds context beyond annotations by revealing that it runs three checks in parallel, returns a unified decision, and includes a 'ready-to-use settleBody' – indicating the output is actionable. It also labels itself as a pre-flight call, implying no settlement execution. Annotations already declare readOnlyHint=true, so 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 just three sentences, starts with the core purpose, and every sentence adds information (purpose, alternative, return fields). No redundant 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?

The description covers the tool's role, internal operations, and return payload. With an output schema present, return values are fully documented. It could mention conditions for BLOCKED/HOLD outcomes, but the overall context is sufficient for an agent to select and invoke the tool.

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

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

All 5 parameters have descriptions in the schema (100% coverage), so the description doesn't need to explain them. However, the description doesn't add any parameter-specific guidance 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?

The description opens with a specific verb phrase ('Single pre-flight call before settling') and clearly names the operations it performs (oracle check, compliance screen, stablecoin routing) and its output (unified go/no-go decision). It also distinguishes itself from the 3-step loop by explicitly saying it replaces that sequence.

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 when to use it ('before settling') and that it replaces the 3-step oracle → screen → route loop, providing an alternative. It doesn't explicitly say when not to use it or mention alternative tool names, but the context 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 mark this as a safe read-only, idempotent operation. The description adds concrete behavior: exactly 12 windows, sorted by urgency (active first, then months until occurrence), and each entry's fields (commodities, severity, agronomic basis).

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 deliver a complete picture: what it is, what it returns, and how it's sorted, with no redundant 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?

Given the tool's simplicity (0 params, output schema present) and rich annotations, the description fully covers the expected behavior and output structure. It is sufficient 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?

The tool has zero parameters, so schema coverage is 100% trivially. The description appropriately omits parameter details; there is nothing for it to add.

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 'Seasonal climate event calendar with commodity impact', clearly identifying the tool's function. It specifies the output ('12 critical annual windows') and the domain (climate events with commodity impact), distinguishing it from generic forecast 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 implies context: use when you need the annual seasonal calendar. It doesn't explicitly name alternatives or exclusions, but the clear scope ('seasonal climate event calendar') gives sufficient context for 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 and destructiveHint, but the description adds valuable behavior: a 4-hour cache, optional fresh recompute, coverage scope, and a disclaimer that signals are not financial recommendations. These go beyond what annotations provide, though auth/rate-limit details are absent.

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 core purpose, then efficiently covers output, coverage, target audience, disclaimer, and cache behavior. Every sentence earns its place, with no filler or repetition of schema details.

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, full parameter schema, and existing output schema, the description is complete. It covers scope, output structure, cache semantics, target users, and risk disclaimer, leaving no significant gaps for an agent to invoke it 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 fully describes both parameters (symbol enum and fresh boolean), so the baseline is 3. The description adds context like the 4-hour cache and commodity coverage, which indirectly relates to the 'fresh' parameter, but it does not introduce new parameter-level semantics 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 clearly states it produces a climate-driven price pressure outlook for a commodity and specifies the exact output: BULLISH/BEARISH/NEUTRAL signal, 30/60/90-day horizons, confidence score, per-region stressor breakdown, and FRED price. This distinguishes it from sibling forecast tools by its commodity-specific signal focus.

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: 'Designed for institutional research teams evaluating commodity positions' and implies use when assessing climate-driven supply risk. It does not explicitly name alternatives or state when not to use, but the context is sufficient for an agent to select it appropriately.

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

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

Annotations already mark it read-only and non-destructive. The description adds valuable behavioral context: weights are normalized internally, and the tool identifies hedges and returns a plain-language summary. 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, all information-dense with no filler. The main action is front-loaded, followed by input constraints and output expectations, then the target use case.

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 the description already covering input limits, normalization, and return value components, the tool is fully described for correct invocation. The description also gives the strategic context (pre-rebalancing evaluation), making it complete.

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

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

Schema coverage is 100%, including the weight description and symbol enum. The description adds meaning by clarifying that weights can be 'percentages or fractions' and are 'normalized internally,' which reassures the agent about acceptable inputs beyond the schema's 'any positive number.'

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 stress test for a multi-commodity portfolio.' It clearly states what the tool does and what it returns (aggregate score, most stressed positions, hedges, summary), distinguishing it from single-commodity forecast tools like forecast.commodity_outlook.

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 clear usage context: 'Useful for commodity fund managers evaluating aggregate climate exposure before rebalancing.' It implies the tool is for portfolio-level analysis, but does not explicitly name alternative tools 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 declare read-only, idempotent, and open world hints. The description adds useful context by mentioning the approximate count of regions (~40) and the categorical risk levels (HIGH/MODERATE/LOW), which 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 three sentences, front-loaded with the core purpose. Every sentence provides distinct value: the data set, the fields shown, and the intended use case. No wasted words.

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

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

For a read-only tool with no parameters and an output schema, the description sufficiently covers what the tool returns and when to use it. It explains the risk levels and adds context about the number of regions, making it self-contained for the 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 input schema has 0 parameters, so the baseline is 4. The description reinforces that no filtering is possible by saying 'All ~40 global commodity production regions,' which sets expectations appropriately.

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 ~40 global commodity production regions ranked by climate risk score, and specifies the data provided per region (commodities affected and risk level). This distinguishes it from sibling forecast tools like forecast.commodity_outlook and forecast.scenario by focusing on geographic 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 gives a clear use case: 'Use to identify which geographic zones are under active climate stress and which commodities are most exposed.' It lacks explicit alternatives or when-not-to-use guidance, so it does not fully earn 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 safety is established. The description adds context about applying scenarios, seeing signal shifts, and lists built-in scenario IDs. It does not cover return format, but that is handled by the output schema. 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?

The description is three sentences, front-loaded with purpose, includes a useful list of built-in scenarios, and ends with a usage recommendation. The scenario list is somewhat long but provides quick value to the agent. No wasted sentences.

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 detailed input schema (100% coverage), output schema flag, and clear annotations, the description adds sufficient context: what scenarios exist, how to use them, and when to use the tool. It clarifies the either/or relationship between scenario and stressorOverrides. A complete package 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 clear descriptions for symbols, scenario, and stressorOverrides. The description adds little beyond the schema, only rephrasing 'custom stressor multipliers' and listing scenario names that already appear in the enum. 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 defines the tool as 'what-if climate scenario analysis' that applies named scenarios or custom stressor multipliers to commodities and shows signal shifts. It distinguishes itself from sibling tools like forecast.commodity_outlook and forecast.portfolio_stress by focusing on scenario stress-testing.

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 explicit guidance: 'Use to stress-test a commodity thesis before committing to a position.' It does not explicitly name alternatives or when-not-to-use, but the use case is clear and specific enough for an agent to select 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?

Annotations already declare read-only and idempotent behavior. The description adds valuable context: sort order (best-first), 'current' data, and '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?

Four sentences with no fluff: content, sort order, use case, and parameter hint are all conveyed efficiently. The first sentence is front-loaded with the core function.

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

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

Given the simple one-parameter list tool, the description covers purpose, usage, sorting, and filtering. Output schema exists to document return values, and annotations cover safety. No significant gaps.

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

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

The only parameter 'from' is fully described in the schema (100% coverage). The description briefly mentions filtering but adds no additional meaning or examples beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the resource (all 60+ currency corridors) and attributes (stability tier, daily volatility, regulatory flags). It also conveys the purpose of comparing corridors, making it distinct from a single-corridor tool like stability.corridor.

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 concrete use case ('compare corridors before choosing a payment route') and an example query. However, it does not explicitly mention when not to use it or name alternative sibling tools, 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 mark readOnly=true and destructive=false. Beyond that, the description adds meaningful behavioral context: it discloses the x402 micropayment requirement, the fee-inclusive nature of the quote, and the specific '48h FX cost variance' output. This enriches the agent's understanding without contradicting the annotations.

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

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

The description is compact and front-loaded: the first clause states the tool's essence, followed by bullet-like output components and a concrete question. Every sentence adds value, and there is no repetition of schema or annotation 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?

Given the tool's moderate complexity, the presence of an output schema, and read-only annotations, the description is complete: it covers the purpose, the key output fields, the settlement-certainty use case, and the payment prerequisite. No critical context is missing 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?

Schema coverage is 100% with clear descriptions for all five parameters, so the baseline is 3. The description adds minimal param-specific detail beyond 'target currency' and 'source currency', but it does not introduce ambiguity. It earns a standard passing score, not higher, because the schema already 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 uses a specific verb-plus-resource framing ('All-in settlement cost quote for cross-border payments') and clearly states the exact question it answers: 'if I send $X today, what does my counterparty receive net of everything?' It names concrete outputs (rail fees, FX variance in dollars, stability overlay, execution window), which distinguishes it from sibling tools like fx.rate or settlement.quote.

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

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

The description clearly implies the use case: when a CFO or counterparty needs a net settlement amount with certainty bounds. It also states a prerequisite ('Requires x402 micropayment'). It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select this tool over rate-only or quote-only 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 mark this as read-only and non-destructive; the description adds valuable behavioral context: data sourced from central bank rates via open.er-api.com, updated hourly, no API key required, and free. This goes beyond annotation coverage, though it does not mention rate limits or error behavior.

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

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

Three sentences deliver purpose, return fields, source, update cadence, and auth requirements with no fluff. The structure front-loads the core purpose, and even the standalone 'Free' sentence adds cost-related value, so 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?

For a simple two-parameter read-only tool with an output schema and complete parameter coverage, the description provides ample context: return fields, data provenance, freshness, and no-auth access. Minor gaps like rate limits or invalid-code behavior are acceptable given the low complexity and existing annotations.

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 documents both parameters with ISO 4217 examples at 100% coverage. The description's 'any currency pair' adds minor scope confirmation but does not enrich parameter semantics beyond what the schema 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 opens with a precise verb+resource: 'Live mid-market FX rate for any currency pair.' It explicitly lists the returned metrics (mid rate, bid/ask spread, daily volatility %, regulatory flags, data freshness), which clearly distinguishes it from sibling tools like fx.cost_certainty or market.fx.

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 fetching live mid-market rates for arbitrary currency pairs, and notes no API key is required. However, it provides no explicit 'when to use' vs alternatives or exclusionary guidance, so the usage context 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?

The description goes well beyond annotations by detailing the polling behavior, the on-chain detection on Base mainnet, the state transition from pending to verified, and the inclusion of txHash and Basescan link. This enriches the safe-read nature indicated by 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 concise sentences with no fluff. It front-loads the core purpose before adding behavioral details, making every sentence 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?

For a status-checking tool with an output schema, the description still adds valuable context: polling interval, on-chain payment detection, and the exact response states. This makes the tool fully self-contained for an agent to use 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 coverage is 100% and the single id parameter is already described as the verificationId returned by integration.verify. The description adds no extra 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 clearly states the tool checks the status of a DPX integration verification session, which is a specific verb and resource. It distinguishes itself from sibling tools like integration.verify by focusing on status polling after payment.

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

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

The description explicitly instructs to poll every 10–15 seconds after sending the payment, which is precise timing guidance. It also implies the tool is used after integration.verify, establishing a clear use context without needing to name alternatives.

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

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

Annotations indicate a state-changing operation (readOnly=false, not idempotent) and the description adds meaningful context: it returns the treasury address and payment instructions, confirms wallet funding and settlement rails via a $0.01 USDC transfer on Base mainnet. It doesn't warn about duplicate calls, but the non-idempotent hint is not contradicted, and the description adds value beyond the annotations.

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

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

Four sentences, each serving a distinct purpose: action, return value, client action, and follow-up step. No redundancy or fluff, and key 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 output schema and annotations, the description is complete: it explains the purpose, the verification payment mechanics, the requirement before production, and the next polling action. No critical gaps for an initiating 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 input schema covers both parameters (walletAddress and optional apiKey) with 100% description coverage, including the hash storage note for apiKey. The tool description adds little new meaning beyond reinforcing that the walletAddress will send the verification payment, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific action ('Initiate a $0.01 USDC onboarding handshake') and resource ('new DPX integration'), distinguishing it from sibling tools like integration.status (poll) and settlement tools by focusing on the pre-production verification 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?

Explicitly states when it is required ('Required for all new integrations before production settlements are enabled') and directs users to the alternative/next step ('Call integration.status to poll for confirmation'). This provides clear usage context and alternatives.

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

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

Annotations already state readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond those: it defines the three aftershock waves with explicit time horizons (0–72h, 1–4 weeks, 1–6 months), what the model identifies (rebounding, amplified pressure, structurally altered nodes), and the expected HTTP method (POST). There is no contradiction with annotations.

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

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

The description is front-loaded with the core purpose, then details the three wave outputs, then the companion workflow, and ends with a REST method reminder. Each sentence serves a distinct function: definition, output details, usage guidance, and input summary. It is informative without excess wordiness.

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

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

The tool has a rich output schema, so the description does not need to detail return values. It explains the modeling logic, wave timing, and companion relationship, which gives an agent enough context to select and invoke the tool. It could mention typical error conditions or interpretation guidance, but the existing information is sufficient for a moderately complex predictive tool.

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

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

Schema description coverage is 100%, with all five parameters individually described. The description reiterates a subset (origin, eventType, magnitude, elapsedHours) but omits horizonHours, which the schema already documents. It adds minor context by framing them as components of a 'primary shock,' but does not significantly enhance beyond the schema. 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 opens with a specific verb+resource: 'models the secondary waves that follow a primary cascade event.' It clearly distinguishes itself from market.cascade by positioning as a companion, and from other intelligence tools by focusing on aftershocks with three distinct wave phases. The purpose is unmistakable and behaviorally specific.

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 it: 'run cascade first, then aftershock to see the full picture,' providing a clear sequential relationship with market.cascade. It also lists required inputs ('POST with origin, eventType, magnitude, elapsedHours'), which implies prerequisites. However, it does not explicitly mention when not to use it or alternatives like intelligence.contagion.

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 details beyond this, including the R-value threshold interpretation (R<1.0 vs R≥1.0), the specific output components (spread map, superspreader nodes, containment forecast, AI briefing), and the need to first list nodes. No contradiction with annotations.

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

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

The description is packed with needed information yet remains concise. It front-loads the title and model, then covers prerequisites and output. Every sentence serves a purpose, with 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 tool's complexity, the description fully covers its purpose, model, domains, outputs, interpretation, and prerequisite actions. The presence of an output schema removes the need to detail return structures, and the description supplies all necessary context for an agent to invoke it 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 coverage is 100%, so the baseline is 3. The description adds value by clarifying the origin parameter's lookup mechanism ('Call /contagion/nodes first') and indicating that simulation requires 'origin and magnitude,' which complements the schema's individual 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 explicitly states the tool's function: simulating how a macro/financial shock spreads through 30 nodes across 6 domains using an epidemiological R-value model. This is specific and distinguishes it from neighboring intelligence tools like 'aftershock' or 'resonance' by naming its unique model and outputs.

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

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

Clear context is provided: 'Call /contagion/nodes first to discover valid origin IDs' and 'POST with origin and magnitude.' While it does not explicitly name alternatives or state when not to use the tool, the direction is sufficient for correct invocation and prerequisite steps.

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

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

Annotations declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context beyond this: it discloses the two scores, transmission mechanisms, live FRED feedback, AI synthesis, data sources, and a 12h cache. 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?

The description is a single, dense sentence containing a lot of information. It is front-loaded with the main purpose and then details. Slightly long, but every clause adds value—no fluff. Could potentially be split for readability, but it remains appropriately sized for 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?

Given the tool's complexity and the presence of an output schema, the description covers all necessary context: the two scores, their economic rationale, data sources, cache behavior, and input requirements. 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?

The schema has zero parameters and the description explicitly states 'No input required — GET.' This fully clarifies the parameter situation. Since there are no params, the description's statement is sufficient and adds clarity beyond the empty schema.

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

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

The description opens with 'Gender Risk & Opportunity Intelligence' and clearly states it 'maps the structural relationship between GBV prevalence, legal discrimination, female labour force participation, and economic outcomes across 18 countries.' This is a specific verb+resource with clear scope, distinguishing it from sibling intelligence tools like aftershock or contagion.

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: no input required, GET method, and outputs two scores. It implies usage for gender-related risk and opportunity assessment. However, it does not explicitly name alternatives or state when-not-to-use, leaving some inference needed.

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 goes beyond the readOnlyHint and other annotations by detailing the exact outputs: per-signal phase angles, resonance clusters, amplitude amplification factor, system resonance score, and historical danger-zone comparison. It also states 'No input required — GET,' making the operational behavior transparent.

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 detailed but every sentence contributes value: the core concept, the risk context, the return payload, and the no-input requirement. It is front-loaded with the main purpose and avoids 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 is fully self-contained: it explains the domain (28 signals, 5 domains), the interpretation of resonance, and all return fields. With an output schema present, it doesn't need to explain return values, but it does anyway, making it complete for the agent to select and invoke.

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

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

The tool has zero parameters, and the description explicitly confirms 'No input required — GET.' This adds operational clarity beyond the empty schema, which is the baseline 4 for zero-parameter tools, and the explicit HTTP method is an additional helpful detail.

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

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

The description clearly identifies the tool's purpose: detecting when multiple independent macro forces oscillate in phase across 28 signals in 5 domains. It uses a specific verb ('detects') and resource ('resonance'), and the concept is distinct from sibling intelligence tools like aftershock, contagion, and tectonic.

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 this tool: to identify systemic resonance where multiple shocks amplify each other rather than cancel. It contrasts resonance with manageable single shocks, implying the appropriate use case. It does not explicitly name alternative tools or exclusions, but the context is sufficient.

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 annotation hints (all false), the description carries the transparency burden. It discloses important behavioral traits: 'cron checks hourly and fires the webhook on crossing — edge-triggered, not repeated every hour' and 'Returns a subscriptionId for status checks and cancellation.' This adds significant value beyond the sparse annotations, though it omits details like payload format or error handling.

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

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

The description is three sentences with no filler. It front-loads the primary purpose, then efficiently covers signals, triggering behavior, return value, and use cases. 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 presence of an output schema (which covers return values) and the sparse annotations, the description is remarkably complete. It explains the tool's function, supported signals, triggering mechanism, scheduling, return value, and intended use cases. No critical operational detail seems missing for an agent to decide when and how to invoke it.

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

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

The schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description goes beyond the schema by elaborating on signal meanings (e.g., 'stability (overall 0–100 score), cascade (shock propagation risk)') and the threshold-crossing behavior, enriching the semantics of 'signal' and 'threshold'.

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: 'Register a webhook to receive alerts when a DPX intelligence signal crosses a threshold.' It specifies the resource (DPX intelligence signals) and the action (webhook registration). While it does not explicitly contrast with sibling subscription tools, the different verbs and resources make 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?

The description provides clear use cases: 'Use for treasury alert systems, TMS integrations, or autonomous agent monitoring loops.' This establishes when the tool is appropriate, but it does not mention when not to use it or offer alternative tools, such as intelligence.subscription.get or delete.

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 this: it specifies that future webhook alerts stop and that the alert log is retained for audit purposes, which clarifies what is and isn't affected.

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

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

Two concise sentences that front-load the core action and add only necessary detail (stopping alerts and log retention). No wasted words.

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

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

Given the simple one-parameter tool and the presence of an output schema, the description covers the key behavioral aspects and side effects. It could mention irreversibility or prerequisites, but the annotations and schema fill most gaps.

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

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

The input schema fully describes the only parameter, subscriptionId, as 'UUID returned by intelligence.subscribe'. The tool description merely says 'by ID', adding no new semantic meaning. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Cancel an intelligence subscription by ID') with a specific verb and resource. It distinguishes from sibling tools by noting it stops future webhook alerts, which is distinct from intelligence.subscribe and intelligence.subscription.get.

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 usage context: canceling a subscription to stop alerts. It does not explicitly mention alternatives or exclusions, but the tool's purpose is unambiguous given the name and description, so the context 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 and idempotentHint=true, covering the tool's safe read-only nature. The description adds valuable behavioral detail by listing the returned data (signal score, last fired timestamp, total alerts fired, and configuration), which goes beyond the schema and 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 purpose, and includes essential usage guidance. Every sentence adds value 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, the presence of a strong output schema, and clear annotations, the description covers purpose, usage, and return values sufficiently. It is complete 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 schema already provides 100% coverage with a description for subscriptionId ('UUID returned by intelligence.subscribe'). The tool description does not add further parameter details beyond mentioning 'by ID,' 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 clearly states the tool's function: 'Check the status of an intelligence subscription by ID.' It also distinguishes itself from sibling tools like intelligence.subscription.delete by explicitly focusing on status verification and mentioning the return of configuration details.

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 context: 'Use after intelligence.subscribe to verify a subscription is active.' This gives clear when-to-use guidance, though it does not explicitly mention alternatives or when not to use the tool, which is acceptable given its specialized role.

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=false. The description adds beyond these by specifying it is a GET with no input and summarizing the return payload (per-node stress state, rupture sequence, horizon timeline, AI synthesis briefing). This provides useful 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 four sentences, slightly longer than the two-sentence ideal, but every sentence adds meaningful detail: purpose, data fields, alternative differentiation, return summary, and input requirement. It is front-loaded and organized, with only minor redundancy in the detailed node fields (which may overlap with output schema).

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

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

For a parameterless analytical read-only tool with an output schema, the description covers all necessary aspects: what it does, how it differs from a sibling, what data it returns, and that no input is needed. The presence of an output schema means return-value details are fully specified elsewhere, so the description 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?

With 0 parameters, the baseline is 4. The description explicitly clarifies 'No input required — GET,' which reinforces the empty schema and removes any ambiguity about needing arguments. Since there are no params to explain, this is appropriately sufficient.

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 and resource: 'maps slow-moving structural stress across 22 fault lines in 5 domains.' It immediately distinguishes itself from sibling tool market.cascade by contrasting acute shocks with latent pressure, making its unique role obvious.

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 positions this tool relative to market.cascade: 'Where market.cascade traces an acute shock, tectonic surfaces latent pressure before it ruptures.' This gives the agent clear guidance on when to choose this tool over an alternative, along with a direct 'No input required — GET' constraint.

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

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

Beyond the annotations (readOnlyHint=false, etc.), the description discloses key behaviors: the creation side effect, the return values (invoiceId, payUrl), and the TTL expiration. This is useful context that annotations alone do not provide. 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, front-loaded with the core purpose followed by flow and return/expiry details. Every sentence carries meaningful information 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 covers the primary flow, return payload, and expiry, and the output schema likely details exact return shape. It misses potential prerequisites (e.g., agent registration or mandate creation) suggested by sibling tools, but the core usage is well explained.

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 describes all 7 parameters with 100% coverage, so the description does not need to explain each one. It does add context for ttlSeconds (default 24h) but does not elaborate on other parameters. 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 clearly states the tool's purpose: 'Create an agent-to-agent invoice.' It specifies the actor (Agent A), the action (request payment), and the resource (invoice). It also distinguishes itself from sibling tools by naming invoice.pay as the counterpart for settling and invoice.get implicitly for retrieving.

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 context: 'Agent A calls this to request payment from Agent B.' It names the alternative tool invoice.pay for settlement, clarifying when to use this tool versus the sibling. The expiration behavior is also mentioned, helping the agent understand the lifecycle.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behaviors. The description adds the concrete return data (status OPEN/PAID/EXPIRED, amount, currency pair, payUrl) and the intended pre-payment check, which is valuable context beyond the annotations.

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

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

Two focused sentences efficiently cover purpose, return data, and usage guidance. No filler or restatement of the tool name.

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

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

For a simple one-parameter read tool with rich annotations and an output schema, the description covers the core action, expected return values, and the exact scenario the tool supports. No critical gaps remain.

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 fully documents the only parameter (invoiceId as a UUID from invoice.create), and the description simply refers to 'by ID.' With 100% schema coverage, the description adds little extra meaning, 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 ('Retrieve') and resource ('an agent-to-agent invoice by ID'), and distinguishes itself from sibling tools like invoice.create and invoice.pay by focusing on fetching rather than creating or paying.

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 provides explicit guidance on when to use this tool: 'Use before calling invoice.pay to confirm the invoice is still OPEN.' This names the exact alternative workflow and gives a clear condition, which is strong usage direction.

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 internal sequence (retrieves the invoice, runs settlement via POST /settle, and marks it PAID) and explains mode-specific outcomes. This adds value beyond the annotations, which are all false and provide no safety hints. Minor gaps like error handling or prerequisites prevent a higher score.

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 purpose, followed by the process and mode behavior. Every word is informative, with no redundancy or filler, making it exceptionally clear and efficient.

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

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

For a tool with an output schema and fully described parameters, the description provides sufficient context about purpose, process, and output modes. It lacks explicit error scenarios or prerequisites, but overall 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?

Schema coverage is 100% with descriptive parameter descriptions, so the baseline is 3. The description reinforces the sandbox/live distinction and mentions 'execution parameters' in live mode, but it does not add significant new meaning to individual parameters beyond what the schema already 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 specifies the verb 'Pay' and the resource 'agent-to-agent invoice by ID', which distinguishes it from sibling tools like invoice.create and invoice.get. It also outlines the process steps (retrieve, settle, mark PAID), making the tool's function 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 clear context for when to use the tool (when paying an agent-to-agent invoice by ID) and explains sandbox vs. live mode behavior. However, it does not explicitly mention alternatives or exclusion conditions, so it falls 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?

The description adds behavioral context beyond the annotations by specifying the returned data ('total USD moved, transaction count, chronological list'). The annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is established. The description complements rather than repeats this.

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 followed by use cases. Every sentence earns its place with zero 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's simplicity (one parameter, no output schema), the description fully covers purpose, usage, return, and context. It is complete and self-contained, requiring no further elaboration.

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 of the single parameter with a descriptive explanation ('Session or task ID — the same ID used in receipt.create calls'). The description does not add further parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Get') and resource ('aggregated payment graph for a multi-agent session'). It also enumerates the exact return values (total USD, transaction count, chronological payment list), making it distinct from sibling tools like receipt.create or analytics.overview.

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.' It also ties the session_id to receipt.create calls, giving integration context. However, it does not explicitly mention alternatives or when not to use, 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 establish readOnly, idempotent, and non-destructive behavior. The description adds value by clarifying the output structure (time-ordered chain, attenuated signal strength, AI synthesis) and scope boundaries ('Purely macro intelligence — no settlement or stablecoin mechanics'). 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 efficient despite its length: it opens with the core purpose, then details inputs/outputs, enumerates domains and nodes, and closes with an important exclusion. Every sentence contributes meaningful 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 complex tool with an output schema, the description is exceptionally complete: it explains input semantics, output structure, domain coverage, and boundary conditions. The output schema handles return details, and annotations cover safety, so no critical gaps remain.

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 clearly described. The description adds some context around origin and magnitude (e.g., '40–60 = significant but not extreme') but does not substantially enhance the parameter understanding beyond the schema. 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 identifies a specific verb+resource: models shock propagation and returns a time-ordered cascade chain. It distinguishes from siblings by emphasizing macro domains (climate, geopolitical, economic, commodity) and explicitly excluding settlement/stablecoin mechanics.

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 (macro shock propagation analysis) and includes a list of example origin events. It lacks explicit alternatives or when-not-to-use guidance against siblings like intelligence.contagion or intelligence.aftershock, so it does not fully meet the 'explicit exclusions' bar.

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 behavioral context beyond that by specifying data sources (FRED spot rates, DXY) and a 1h cache, which implies freshness and rate-limiting behavior. It does not contradict annotations, and the extra details are useful for setting expectations on data latency and availability.

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 moderately long but front-loaded with the core purpose and structured around outputs and data sources. It avoids redundancy, though it packs many details into a single paragraph. It earns its length given the complexity of the tool, but a slightly more structured layout could improve 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?

Given the tool has no input parameters and an output schema exists, the description thoroughly covers what the tool does, what it returns, its data sources, cache behavior, and its relationship to a sibling tool. This is sufficient for an agent to select and invoke it correctly without needing 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?

There are zero parameters, so schema coverage is trivially 100%. The baseline is 4 per the rubric. The description adds semantic context about the tool's purposeful zero-parameter design (a standardized assessment over fixed corridors), but since there are no parameters to document, this is sufficient.

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

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

The description states a specific verb and resource: 'FX Settlement Corridor Intelligence — per-pair execution risk assessment for 10 major currency corridors against USD.' It lists concrete outputs (SETTLE_NOW, DELAY_SHORT, etc.) and explicitly distinguishes itself from oracle.stability, 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 gives explicit when-to-use guidance: 'this tool answers "which currency pairs are risky to settle through right now?"' and provides an alternative exclusion: 'Distinct from oracle.stability (which covers peg deviation and macro settlement gates).' This clearly directs an agent on when to choose this tool over a named sibling.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond these: it lists specific tracked data points (Brent crude, diesel, 8 trade routes), describes the returned settlementRelevance section with risk categories, names data sources (FRED, EIA), and mentions the 4h cache. No contradiction with annotations.

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

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

The description is appropriately sized for the tool's complexity. It is front-loaded with the core purpose, then details tracked data, return sections, target users, data sources, and cache in a logical sequence. Every sentence contributes meaningful information without redundancy.

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