DPX — Institutional Cross-Border Settlement

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

Annotations indicate a write operation (readOnlyHint=false) and no destructive behavior. The description adds significant behavioral context: it explains the instant processing for ANONYMOUS/REGISTERED, the real-time GLEIF API call for VERIFIED, no documents or manual review, and the legal basis (FATF R.16, MiCA, GENIUS Act). This far exceeds the annotation-provided information.

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

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

The description is relatively verbose but well-structured: it opens with the three-tier model, then explains each tier's requirements and outcomes, and ends with legal basis. Every sentence adds value, though some repetition could be trimmed. Front-loading the model helps quick comprehension.

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 (8 params, nested mandate object, multiple tiers) and the presence of an output schema, the description is remarkably complete. It covers all tiers, how to achieve each, caps, verification process, and regulatory references. No gaps or ambiguities 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 covers all 8 parameters (100% coverage), but the description adds critical context: ownerLei triggers instant VERIFIED tier, ownerEmail/ownerEntity are required for REGISTERED, mandate caps are clamped to tier limits for REGISTERED. This enriches the agent's understanding beyond the schema's brief 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: registering an agent under a three-tier KYA model. It specifies 'KYA — Know Your Agent' and details the three tiers (ANONYMOUS, REGISTERED, VERIFIED), distinguishing this registration tool from the sibling 'agent.kya_verify' which likely handles verification of existing agents.

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 implicit guidelines on when to use each tier based on compliance burden and caps (e.g., ANONYMOUS for low risk up to $1K/day, VERIFIED for institutional caps). It also explains what parameters are needed for each tier. However, it lacks explicit guidance on when not to use the tool or alternatives, such as using agent.kya_verify instead for existing agents.

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

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

Discloses credentials expiry (1 hour) and downstream usage beyond annotations. Annotations show readOnlyHint=true, and description adds behavioral context (signing, headers, FATF attestation) without contradiction.

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

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

Three sentences, front-loaded with core action, returns, and usage. Every sentence adds value with no redundancy or fluff.

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

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

Covers purpose, return values, usage instructions, and expiry. Output schema exists, but description still lists key return fields. Complete for this tool type.

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?

Only one parameter (agentId) with 100% schema coverage. Description does not add extra meaning beyond the schema's already clear description, 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 clearly states the tool's purpose: 'Verify a registered DPX agent and receive a signed 1-hour credential.' It specifies the returned data (KYA level, spend caps, etc.) and differentiates from sibling tools like agent.kya_register.

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 instructs when to use: before DPX /settle requests, with header attachment details. Also advises refreshing before credential expiry, providing clear usage context.

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

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

Discloses behavioral traits: creates or updates, AP2 formatting, clamping based on agent tier, expiry. Annotations indicate mutation but not destructive. No contradiction. Lacks detail on idempotency but adequate.

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?

Concise (~100 words), well-structured with purpose first, then agent type rules, then parameter context. No unnecessary 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 8 parameters, 3 required, agent status-dependent behavior, and output schema present, the description covers all essential aspects: agent prerequisites, mandate constraints, AP2 formatting. Complete for agent 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 has 100% description coverage (baseline 3). Description adds significant value: agentId source, clamped caps for REGISTERED, LEIs/wallet addresses for whitelist, empty array semantics for currencyPairs and counterpartyWhitelist.

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 identifies verb (create/update) and resource (spend mandate), specifies AP2 compatibility and agent types (REGISTERED/VERIFIED). Distinguishes from siblings like agent.kya_register and agent.kya_verify.

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

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

Provides context on when to use (set per-agent constraints) and explicit exclusions (ANONYMOUS agents cannot hold mandates). Explains behavior differences for REGISTERED vs VERIFIED agents. Could be more explicit about alternatives but 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?

Annotations already declare readOnlyHint true and destructiveHint false, indicating a safe read operation. The description adds important behavioral context: the data is 'live' and returns a specific set of metrics, which goes 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 two sentences long: the first identifies the tool's function and outputs, the second provides usage guidance. No unnecessary words; front-loaded with key 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 no parameters and the presence of an output schema, the description covers all necessary aspects: what the tool does, what it returns, and when to use it. No 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?

There are no parameters (schema coverage 100%), so the description does not need to explain them. The baseline for zero parameters is 4.

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

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

The description clearly states the verb 'Get' and resource 'live DPX performance analytics', and lists specific outputs (stability score, ESG scores, fee breakdown, oracle health, settlement readiness). This distinguishes it from sibling tools that cover individual aspects.

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 recommends use for 'dashboards, reporting, and AI-driven monitoring of protocol health', providing clear context. It does not explicitly state when not to use or list alternatives, but the context implies it is for high-level overviews.

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 a safe, read-only operation. The description adds context on return fields (confidence, risk level) and regulatory implications (EDD requirements), which is valuable 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?

Four concise sentences, front-loaded with action, no redundancy. Every sentence adds 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?

For a read-only screening tool with annotations and output schema, the description provides complete context: what it screens, outputs, and regulatory significance.

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 no new parameter information beyond what the schema provides, but context on usage is sound.

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 against the OpenSanctions PEP dataset, defines PEPs, and lists outputs. It is specific and distinct from sibling tools like compliance.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?

Usage is implied through the description (when you need PEP screening), but there is no explicit guidance on when to use this tool versus alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds value by detailing the output structure (events, frameworks, DPX alignment). 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?

Well-structured with front-loaded purpose, detailed output list, and usage guidance. Slightly verbose but each sentence adds unique 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?

Complete for a zero-parameter tool. Includes all relevant regulatory frameworks, output fields, and DPX alignment. Output schema exists but description covers essential context.

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

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

No parameters (schema coverage 100%). Description adds meaning by detailing output contents, compensating for lack of parameter documentation.

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 tool returns a structured calendar of compliance obligations across multiple regulations (MiCA, SFDR, CSRD, GENIUS Act, FATF). It distinguishes from sibling tools like compliance.pep_screen and compliance.ubo_chain by focusing on regulatory calendar rather than screening or chain analysis.

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 this before settlement workflow design, compliance gap analysis, or regulatory reporting.' Provides clear use cases but does not mention when not to use or alternative tools.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds value by detailing the output structure (chain, sanctions status, LEI flags, verdict, FATF attestation) and the screening process against multiple sanctions lists, going beyond annotations without contradiction.

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

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

The description is a single paragraph that front-loads the main action and summarises output and use cases efficiently. It is slightly dense but contains no superfluous 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 existence of an output schema, the description adequately covers the tool's purpose, method, and key outputs. It addresses complexity by explaining depth parameter and use cases, leaving no major gaps.

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

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

Schema coverage is 100% with descriptions for both parameters. The description does not add additional meaning beyond the schema, meeting the baseline for high coverage.

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

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

The description clearly states the verb 'trace' and resource 'beneficial ownership chain', specifying depth and sanctions screening. It distinguishes from sibling compliance.pep_screen by focusing on ownership chains 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 lists use cases: correspondent banking due diligence, FATF R.12/13 UBO identification, and MiCA Article 72 counterparty risk management. It does not explicitly state when not to use, but context from sibling tools implies alternatives like pep_screen for individual screening.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=true. Description adds valuable info: 'No auth required' and 'Free', which are not in annotations. 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?

Three concise sentences, front-loaded with purpose and source, then details, then usage context. No filler or repetition.

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

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

Given one optional parameter and presence of output schema, description covers purpose, return data, use cases, authentication, and cost. No 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?

Only one optional parameter 'window' with enum values and full schema description coverage (100%). Description does not add extra meaning beyond schema, matching baseline for high coverage.

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

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

Description explicitly states tool returns live performance metrics for DPX settlement infrastructure, lists specific data types (request volumes, error rates, etc.), and mentions use cases (investor due diligence, portfolio management). It clearly distinguishes from sibling tools like analytics.overview or oracle.*.

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 context: designed for investor due diligence, analyst queries, and Standard Metrics integrations. Implicitly excludes non-performance use cases. Does not explicitly state when not to use, but 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?

The description adds that it screens up to 50 entities, returns ranked results, and that name resolution is slower. This goes beyond annotations which only indicate readOnly and openWorld. No contradictions with annotations.

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

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

Three sentences, no fluff, front-loaded with the core function. Every sentence adds unique 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?

The description covers purpose, input types, output ordering, and use cases. However, it is ambiguous about whether both leis and names can be used together. The presence of an output schema partially compensates, but this gap reduces completeness.

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 3. The description adds the constraint of up to 50 entities and the performance note about name resolution, which is not in the schema. This provides additional value beyond the schema descriptions.

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

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

The description clearly states it screens up to 50 entities by LEI or company name, returning results ranked by composite ESG score descending. This distinguishes it from sibling tools like esg.lookup (single entity) and esg.portfolio (portfolio view).

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 lists concrete use cases: portfolio-level compliance screening, supplier due diligence, and TMS pre-payment checks. It also notes that name resolution is slower, implying LEIs are preferred for speed. However, it does not explicitly contrast with sibling tools or state when not to use it.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds valuable behavioral context: it returns pillar scores with weights, composite 0–100, fee surcharge tier, and per-source breakdown. No contradiction with annotations; in fact, it enhances understanding of what the tool does beyond safety profile.

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

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

Four short, focused sentences. Front-loaded with the primary action. No redundant or generic phrasing. Every sentence adds value (purpose, need removal, output details, usage context).

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

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

Given an output schema already defines return structure, and annotations cover safety, the description completes the picture by listing the exact pillar weights, source breakdowns (SEC EDGAR, OSHA, etc.), and usage scenario. There is no missing context for the agent to decide to invoke this 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%, so the schema already documents all three parameters well. The description adds minimal extra meaning beyond contextualizing the 'q' parameter as a name/domain/ticker and why it's useful (removes need for LEI). With full coverage, baseline is 3; the description does not significantly compound 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 starts with a specific verb 'Resolve a company name, domain, or ticker to a LEI via GLEIF and return the full ESG score.' It clearly distinguishes from siblings like esg.batch or esg.portfolio by focusing on single-entity lookup. Also explicitly states 'Use when you have a company name but not a LEI.'

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

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

Explicitly says to use when you have a company name but not a LEI, which is strong usage guidance. However, it does not mention when NOT to use (e.g., if you already have a LEI, another tool like esg.score might be more direct). Missing explicit exclusion of alternatives among siblings.

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

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

Annotations already indicate read-only (readOnlyHint=true). The description adds significant behavioral context: returns portfolio-level composite scores, tier distribution, fee impact, worst offenders, top performers, MiCA status, SFDR flags, and the 200-entity limit. 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?

Two concise sentences: first gives core purpose and constraint, second lists return values. Front-loaded with the primary action, 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?

Covers use case, input, and output well. Output schema exists so return values can be detailed there. Minor omission: no mention of behavior if input exceeds 200 entities, but otherwise complete for an agent to decide.

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 good param descriptions. The description adds extra value by noting that LEI input is fastest and avoids name resolution, which helps the agent choose between 'leis' and 'names'.

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

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

The description clearly states the action ('Score an entire counterparty portfolio in one call') and the resource (counterparty portfolio), with explicit constraints (up to 200 entities by LEI or name). It distinguishes from likely single-entity tools like 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?

Positions the tool as 'The canonical pre-settlement compliance check for treasury systems and TMS integrations', clearly indicating when to use. Does not explicitly state when not to use, but the context is strong enough for an agent to infer appropriate usage.

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, open-world, and idempotent behavior. The description adds valuable context: data is updated hourly from 6 institutional sources (WorldBank, IMF, etc.), and the output includes a composite weighted average and settlement fee percentage. No contradiction with annotations.

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

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

The description is a single dense paragraph that packs purpose, output, data sources, and regulatory relevance. It is not verbose but could be slightly restructured for even better readability. Still efficient.

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

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

Given the simple input (one optional parameter) and presence of an output schema and detailed annotations, the description fully covers purpose, update frequency, data sources, and compliance use cases. It leaves no obvious 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 schema already covers the single optional parameter with a clear description. The description adds minimal extra meaning beyond stating the protocol default case. With 100% schema coverage, baseline is 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 clearly states the tool retrieves a live counterparty risk score (ESG) for a wallet address or the protocol default. It specifies the output (E,S,G scores, composite, settlement fee) and differentiates from sibling tools like analytics.overview or fees.schedule which serve different purposes.

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 ties usage to EU SFDR and CSRD reporting, giving clear regulatory contexts. However, it does not explicitly state when not to use this tool or compare it to alternatives among siblings, which would improve score.

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

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

Annotations already indicate safe, idempotent read. The description adds a key behavioral trait: data accumulates from other esg scoring tools (lookup, batch, portfolio), which is crucial for understanding data freshness and dependencies.

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 key action, and each sentence adds value: purpose, data accumulation, use cases. No fluff.

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

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

Given the tool's complexity (trend with data accumulation), annotations cover safety, schema covers params, and output schema presumably covers return format. The description explains data accumulation and use cases, making it fairly complete. Minor gap: no mention of delta calculation details, but output schema should handle that.

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

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

Schema description coverage is 100%, so the schema already explains both parameters (lei, days) with details. The description does not add new semantic information beyond stating 'by LEI' and 'over the requested window', which is already implied.

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

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

The description clearly states the tool gets historical ESG composite trends by LEI, specifying outputs like score history, trend direction, and delta. It distinguishes itself from siblings implicitly (trend vs. point scores) but does not explicitly name alternatives.

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

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

The description provides explicit use cases: due diligence, MiCA Article 72 monitoring, and detecting degrading ESG posture. However, it does not include when not to use or contrast with sibling tools like esg.score or esg.lookup.

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

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

Discloses key behaviors: daily checks, threshold-based webhook, watchId for follow-up, and webhook payload details (previous/current score, delta, tier change). No contradiction with annotations (readOnlyHint=false, etc.), and adds 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?

Four concise sentences, front-loaded with main purpose. Every sentence adds value: registration action, DPX mechanism, regulatory compliance, return value, and webhook payload. 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?

Covers all essential aspects: purpose, parameters (with defaults/constraints), behavior (daily check, threshold), output (watchId, webhook payload), and compliance context. Missing error handling or rate limits, but overall complete for a registration tool with output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining thresholdPoints default and minimum, webhookUrl must be HTTPS, and the purpose of lei (GLEIF LEI) is clarified in schema. Extra context justifies score 4.

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

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

The description clearly states the verb 'Register' and the resource 'entity for ESG monitoring'. It distinguishes from siblings like esg.score (one-time) and esg.batch (batch) by specifying ongoing daily monitoring and webhook behavior.

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 to use: for ongoing monitoring, daily checks, threshold-triggered webhooks, and MiCA compliance. However, lacks direct comparison to alternative tools (e.g., esg.score for ad-hoc queries) or explicit when-not-to-use conditions.

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

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

The description aligns with annotations (readOnlyHint=true) and adds behavioral details: it returns savings and compliance status, indicating no side effects. This exceeds annotation coverage, providing clear insight into tool behavior.

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

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

The description is concise, front-loaded with the main purpose, and packs essential details (competitors, metrics, compliance) into two sentences with 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?

The description covers the comparison scope, outputs, and compliance status. Given the tool's complexity and presence of an output schema, the description is largely complete, though it does not explain calculation methodology.

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

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

The input schema has 100% description coverage, and the description does not add additional meaning beyond the schema's parameter descriptions. 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 compares DPX settlement costs against multiple named competitors and returns specific outputs (dollar savings, compliance status). It distinguishes itself from siblings like fees.schedule and fees.verify by specifying the comparative nature.

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 this tool: when needing to compare DPX against alternatives. It does not explicitly state when not to use or name alternative tools, but the specificity makes usage 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 declare readOnlyHint=true and destructiveHint=false; description adds detail on what the fee schedule includes (tiers, ESG table, examples, benchmarks), providing useful behavioral context beyond annotations.

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

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

Single, front-loaded sentence that efficiently lists all major content areas without waste. 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?

Given no parameters and an existing output schema, the description covers all relevant aspects: components, tiers, ESG, examples, benchmarks. Fully adequate for a zero-input read 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?

Input schema has zero parameters, so there is nothing to document. Baseline of 4 is appropriate; description adds no redundant 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?

Clearly states 'Get the complete DPX fee schedule' and enumerates specific components, tiers, and benchmarks, distinguishing it from sibling tools like fees.compare and fees.verify.

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

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

No explicit guidance on when to use this tool versus siblings. With multiple fee-related tools, context on when to pick this one is missing.

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, which the description aligns with. The description adds that it compares off-chain quotes to on-chain charges, providing behavioral context beyond annotations. 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 consists of two concise sentences. The first states purpose and result, the second gives usage order. 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?

The tool is simple and has an output schema (returns boolean), so the description need not explain return format. It provides workflow context (after get_quote, before settle) which is sufficient for a verification tool. It does not detail error scenarios, but that is minor.

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 cover 100% of parameters, so the baseline is 3. The description does not add additional meaning to the parameters beyond what the schema already provides. It subtly implies the role of amountUsd as the settlement amount, but not explicitly.

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

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

The description clearly states the verb 'Verify' and identifies the resource as 'fee quote vs on-chain contract charge'. It also specifies the return value 'feesMatch (true/false)'. This distinguishes it from sibling tools like fees.compare (comparing quotes) and fees.schedule (scheduling).

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 call after get_quote and before settle, providing a clear workflow context. It does not mention when not to call or alternatives, but the guidance is sufficient for correct usage.

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

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

Adds significant behavior beyond annotations: describes polling mechanism, payment detection, return states ('pending', 'verified'), and output details (txHash, Basescan link). Annotations already indicate read-only and idempotent, which the description aligns with.

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?

Extremely concise: three sentences that front-load the purpose and provide actionable instructions. 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 tool with one parameter and existence of an output schema, the description covers purpose, usage pattern, and expected outputs (states, txHash, explorer link). Complete for the context.

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

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

Schema coverage is 100% with the 'id' parameter well-described. The description echoes the schema but adds no new semantic depth. 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 resource ('DPX integration verification session') and the action ('check status'). It distinguishes from siblings like integration.verify by specifying it's for status checking after 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?

Provides explicit polling guidance: 'Poll every 10–15 seconds after sending the payment.' This tells when to use the tool. No explicit exclusion of alternatives, but the context is clear for this specific workflow.

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 annotations (readOnlyHint=false), the description reveals that the client must send $0.01 USDC on Base mainnet, that the API key is stored as a hash and never logged, and explains the return (treasury address and payment instructions). It does not cover multiple invocation behavior or error handling, but provides sufficient 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 four sentences long, front-loaded with the primary action, and every sentence adds essential information without 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?

Given that an output schema exists, the description fully explains the tool's purpose, prerequisites, return values, subsequent step (polling with integration.status), and specific details like chain (Base) and amount ($0.01 USDC), making it sufficient for correct agent invocation.

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

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

Schema description coverage is 100% (both parameters are described in the schema), and the description repeats those descriptions verbatim, adding no new information. 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 action ('Initiate a $0.01 USDC onboarding handshake'), the target resource ('new DPX integration'), and distinguishes it from sibling tools like integration.status by specifying that polling is a separate step.

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

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

The description explicitly states that this tool is required for all new integrations before production settlements, and directs users to call integration.status for confirmation. However, it does not exclude other scenarios or mention alternatives for similar tasks.

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, openWorld, idempotent. Description adds details about wave definitions and node states, which enhances transparency without contradiction.

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

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

Compact, front-loaded with purpose, then detailed outputs, then usage instruction. Every sentence adds value.

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

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

Despite no output schema shown, description explains return values (three waves, node states). With full schema and annotations, the description completes the picture.

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

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

Schema covers all 5 parameters fully. Description lists some parameters (origin, magnitude, elapsedHours) but adds no new meaning beyond schema. Baseline 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 clearly states it models aftershock waves from a primary cascade, specifying inputs, outputs (three waves), and companions. It distinguishes from siblings like intelligence.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?

Explicitly instructs to run market.cascade first, then aftershock. Provides usage context: after a primary event, to see secondary effects. No ambiguity.

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, idempotent, non-destructive; description adds context (simulation, R-value model, output types) without contradicting annotations. Adds value 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?

Three sentences with no fluff: first states purpose and model, second explains key R-value metric, third gives prerequisite and usage. Front-loaded 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?

Given output schema exists, description lists all key outputs (trajectory, map, superspreaders, forecast, briefing) and explains the core concept (R-value). Prerequisite call is noted. No gaps for the intended use case.

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

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

Schema covers all parameters with descriptions (100% coverage). Description integrates parameters into usage flow but does not provide additional meaning 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 states it simulates shock spread using an R-value model across 30 nodes and 6 domains, with specific outputs listed. It distinguishes itself from siblings like 'aftershock' or 'resonance' through the contagion focus, but lacks explicit differentiation statement.

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

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

Explicitly advises to call '/contagion/nodes' first for valid origin IDs and explains R-value interpretation (self-limiting vs expanding). Does not mention when to avoid or alternatives among siblings.

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

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

Annotations already declare readOnly and idempotent. The description adds significant behavioral context: 12h cache, data sources (WHO, World Bank, FRED), transmission mechanisms, and that it synthesizes multiple datasets. 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 paragraph that front-loads the core purpose and efficiently conveys all necessary information without redundancy. Every sentence contributes value.

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

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

Given no required input, the description fully explains output scores, data sources, cache duration, and methodology. With an output schema present, the agent has complete understanding of what the tool returns.

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

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

With zero parameters, schema coverage is 100%. The description adds full meaning by explaining the output scores and their interpretation, exceeding the baseline of 4 for no-param tools.

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 precisely states it maps structural relationships between GBV prevalence, legal discrimination, and economic outcomes, returning two specific scores. It clearly distinguishes from sibling intelligence tools by its unique domain and data sources.

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

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

The description indicates it's a GET request with no input, implying use when gender risk intelligence is needed. However, it lacks explicit guidance on when to prefer this over sibling tools like intelligence.contagion or intelligence.tectonic, though the domain specificity makes it 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 and destructiveHint=false, so the description adds value by explaining the concept of resonance, the signals involved, and the return data (phase angles, clusters, etc.). 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?

Three sentences with no wasted words. First sentence defines purpose, second explains significance, third lists outputs. Perfectly front-loaded and concise.

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

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

Given zero parameters, full annotations, and existence of an output schema, the description adequately covers purpose, behavioral context, and return data. No gaps identified.

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

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

With zero parameters and 100% schema coverage, the description correctly notes 'No input required — GET.' This adds no extra meaning beyond the schema but is appropriately minimal.

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 detects resonance of macro forces across signals and domains, providing a specific verb-resource pair. However, it does not explicitly differentiate from sibling tools like 'intelligence.aftershock' or 'intelligence.contagion', which could have overlapping purposes.

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 case (detecting systemic crises) but lacks explicit guidance on when to use versus alternatives, or when not to use. No exclusions or context for selection among siblings.

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

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

Annotations indicate readOnlyHint=false (mutation) and destructiveHint=false. The description adds important behavioral traits: hourly cron check, edge-triggered (not repeated), returns subscriptionId. It does not describe webhook payload or cancellation details, but overall adds value 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?

Description is concise with three sentences, front-loaded with purpose, and no redundant information. Every sentence adds value: purpose, supported signals, behavior, return value, and use cases.

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 an output schema exists (though not shown), the description covers the tool's core behavior, supported signals, and use cases. It does not cover error handling or payload format, but is sufficiently complete for a creation tool with good 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%, so baseline is 3. Description reinforces that default signal is stability and direction is above, but these are already in the schema. It adds context about the cron and edge-triggering, but not enough to raise the score.

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

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

Description clearly states the tool registers a webhook for DPX intelligence signal thresholds, lists supported signals, and explains edge-triggered behavior. The verb 'register' and resource 'webhook for alerts' are specific, and the purpose is distinct from sibling tools like oracle.intelligence or oracle.stability, though not explicitly differentiated.

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?

Description provides clear usage context: 'Use for treasury alert systems, TMS integrations, or autonomous agent monitoring loops.' However, it does not explicitly state when not to use or mention alternative tools, missing some 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 indicate destructive and idempotent behavior. The description adds value by specifying what is stopped (webhook alerts) and what is retained (logs), providing behavioral context beyond annotations. No contradiction.

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

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

The description is two sentences, front-loaded with the primary purpose, and contains no redundant or unnecessary information. Highly 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 simple tool with one parameter and an output schema, the description adequately covers purpose, effect, retention, and idempotency. No additional context is needed for correct invocation.

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

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

Schema coverage is 100% with the only parameter 'subscriptionId' described as 'UUID returned by intelligence.subscribe.' The description does not add further meaning to this parameter. Baseline of 3 applies.

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

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

The description clearly states the action ('Cancel'), the resource ('intelligence subscription'), and the mechanism ('by ID'). It distinguishes from siblings like intelligence.subscribe (create) and intelligence.subscription.get (retrieve).

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

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

The description explains the effect ('Stops future webhook alerts') and retention policy ('alert log is retained'), providing context for use. However, it does not explicitly state when not to use the tool or mention alternative tools for related actions.

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, idempotent, non-destructive. Description adds what the tool returns (signal score, last fired, etc.), which is 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?

Two sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.

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

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

Given output schema exists, the description fully explains purpose, usage context, and return data. Could mention authorization or error conditions but overall sufficient.

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

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

Schema coverage is 100% and description repeats the schema's parameter description ('UUID returned by intelligence.subscribe'), adding minimal new information. 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 'Check the status of an intelligence subscription by ID' and lists the returned data. It differentiates from siblings by specifying usage after intelligence.subscribe.

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

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

Explicitly says 'Use after intelligence.subscribe to verify a subscription is active', providing clear usage context. No explicit when-not or alternative tools, but sibling names provide context.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds context that it requires no input, is a GET, and returns specific data fields. 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?

Concise yet comprehensive: front-loads purpose, explains data structure, differentiates from sibling, lists return values, and states no input. Every sentence adds value.

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

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

Given zero parameters and existence of output schema, description fully covers what the tool does and returns. Sufficient for agent to understand tool's purpose and output.

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?

No parameters, so description need not add parameter info. Baseline 4 applies as schema coverage is 100% and description clarifies no input needed.

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

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

Description explicitly states it maps slow-moving structural stress across fault lines and domains, with clear output details. Contrasts with sibling market.cascade to distinguish 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?

Provides context for when to use this tool versus market.cascade (latent pressure vs acute shock). Also notes no input required. Lacks explicit exclusions or alternative sibling 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 declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description adds behavioral context: returns time-ordered cascade, attenuated signal strength, AI synthesis, covers 24 nodes across 4 domains, and explicitly states 'Purely macro intelligence — no settlement or stablecoin mechanics.' 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 slightly verbose (e.g., listing all 24 nodes) but well-structured: purpose first, then node categories, then usage instructions. Every sentence adds information, though some details could be trimmed without losing clarity.

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

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

Given the tool's complexity (5 parameters, no required, output schema exists), the description covers purpose, domain nodes, usage guidelines, and output characteristics. It is fully sufficient for an AI 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 clear descriptions for all 5 parameters. The description adds value by explaining the domain nodes and the listNodes discovery pattern, going beyond the schema's basic 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 models shock propagation across macro domains (climate, geopolitical, economic, commodity) and returns a cascade chain with AI synthesis. It clearly differentiates from siblings like market.fx or market.shipping which handle specific domains, and none of the siblings perform cascade intelligence.

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

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

The description explains when to use the tool (macro shock analysis) and instructs to call with listNodes:true to discover valid origin values. While it doesn't provide explicit 'when not to use' scenarios, the context is clear enough for an AI agent to decide.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral context: data sources (FRED spot rates, DXY), cache duration (1h), and output structure (risk categories, regime, blocks, recommendations). 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 detailed but front-loaded with the main purpose. Every sentence adds value: listing currencies, explaining outputs, data source, caching, and sibling differentiation. Slightly long but appropriate 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 (multiple currencies, output fields, data sources, caching, and sibling context), the description is fully complete. It explains all key aspects without relying on the output schema (which exists). An agent can correctly 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?

No parameters; schema coverage is 100%. Per guidelines, 0 parameters yields baseline 4. The description does not need to explain params.

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 provides per-pair execution risk assessment for 10 major currency corridors against USD, mapping spot rates to settlement advice categories (SETTLE_NOW etc.) and returning DXY regime, regional risk, and recommendations. It distinguishes from sibling oracle.stability by specifying what question this tool answers.

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 contrasts with oracle.stability to guide selection: this tool answers 'which currency pairs are risky to settle through right now?' while oracle.stability covers peg deviation and macro gates. Though no explicit when-not scenarios, the differentiation 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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the tool is safe and non-destructive. The description adds valuable behavioral context beyond annotations: data sources (FRED, EIA), a 4-hour cache, and the specific output structure (settlementRelevance mapping). 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 somewhat verbose but well-structured, with the core purpose front-loaded. Each sentence adds useful information (target users, data sources, cache). Could be slightly more concise, but overall no wasted 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 zero-parameter tool with an output schema, the description is highly complete. It explains the composite view, what metrics are tracked (energy costs, 8 routes, trade flows), the settlementRelevance output, target users, data sources, and cache behavior. An agent has all necessary context to invoke this tool correctly.

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

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

The input schema has no parameters, so schema coverage is 100%. With zero parameters, the description naturally adds no parameter information, but a baseline of 4 is appropriate since the schema fully covers 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 provides a composite view of global freight market conditions across ocean, air, truck, and rail, with specific tracking of energy costs, trade routes, and trade flow signals. It distinguishes itself from siblings like market.fx and market.cascade by focusing specifically on shipping logistics stress, and mentions a unique 'settlementRelevance' section.

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 identifies target users (treasury teams, trade finance desks, agents pricing cross-border payments) and contexts where the tool is useful (supply chain financing exposure, goods-backed corridors). It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns account IDs, names, balances, currency, and works with both environments. This adds some context but does not disclose any behavioral traits beyond what annotations and schema already convey.

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

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

Three sentences with no wasted words: first sentence states purpose and return fields, second sentence guides usage with sibling tools, third sentence mentions environment compatibility. Front-loaded 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?

Given no parameters and presence of output schema (which explains return values), the description is complete. It covers purpose, return fields, usage with siblings, and environment compatibility. No 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 has no parameters, so schema description coverage is 100% (vacuously). According to calibration, zero parameters baseline is 4. The description does not need to add 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 lists Mercury bank accounts and balances, specifying the returned fields (account IDs, names, balances, currency). It distinguishes itself from sibling tools by mentioning how to use account IDs with mercury.transactions and mercury.send.

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 (to list accounts) and how to use the output with sibling tools. It also mentions compatibility with sandbox and production environments. While it lacks explicit when-not guidance, the context is clear given it's a read-only list.

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

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

Description discloses that the tool can optionally execute the payment (destructive), as indicated by autoExecute parameter and annotations (destructiveHint: true). No contradiction. Provides context on compliance checks and irreversibility of ACH.

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?

Well-structured with clear sections: purpose, usage guideline, numbered workflow. Every sentence adds value without redundancy. Front-loaded with the core purpose.

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

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

Given 9 parameters, compliance integration, and workflow, the description is complete. It explains decision outcomes, autoExecute behavior, and prerequisites (recipientId from mercury.send). Output schema exists but not shown; description covers what 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 has 100% coverage with descriptions, but the description adds workflow context for autoExecute and clarifies recipientName's role in compliance screening. However, most parameters are already well-documented in 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 the tool screens an ACH payment via compliance oracle before execution, returning APPROVED/FLAGGED/BLOCKED. This distinguishes it from sibling tools like mercury.send, which sends payments without pre-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?

Explicit guidelines: use before every ACH payment, with a detailed workflow (authorize with autoExecute:false, review decision, proceed or not). Clearly states when to use (before each ACH) and what to do for each outcome.

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 denote destructive and open world. The description adds valuable context: timelines for each payment rail, the effect of sandbox, and the DPX routing behavior. 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?

Well-structured with a clear overview, then specific sections. It is somewhat long but every sentence adds value. Could be slightly more concise, but the numbered flow helps.

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 21 parameters and output schema existing, the description covers behavioral aspects (timelines, error handling not needed), prerequisites, and a complete workflow. It leaves no major gaps.

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

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

Schema coverage is 100%, but the description adds critical semantics: which parameters are required for which rail (e.g., swiftCode for internationalWire), the meaning of dpxRoute (triggers DPX settlement), and sandbox default. This goes well beyond a baseline 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 clearly states it initiates a Mercury bank payment with all supported rails. It does not explicitly distinguish from sibling tools like mercury.transactions, but the typical flow and detailed specificity make it clear. The verb 'Initiate' is precise and the resource 'Mercury bank payment' is well-defined.

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 guidance on when to use this tool, including prerequisites (e.g., check oracle.stability and market.fx first), alternatives for filtering (e.g., merchant accounts tool), and a step-by-step typical flow. Also explains sandbox usage and when to set false. This is exemplary.

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 annotations: it confirms no funds are moved, spells out safety rules (reserve threshold, deployment cap, time window, minimum amount, exit timing), and explains the yield instrument. Annotations already indicate readOnly=true, but the description enriches this with concrete constraints.

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

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

The description is well-structured with clear sections: purpose, disclaimer, safety rules, current instrument, workflow. Every sentence adds essential information. It is concise for the amount of detail provided and 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 tool has an output schema, the description adequately describes the return value (structured recommendation with yield, amount, timing, steps). It covers prerequisites, safety rules, and workflow integration. No missing elements are evident.

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 each parameter is documented in the schema. The description adds value by specifying default values (thresholdUsd=$50k, riskTolerance='moderate', settlementDeadlineUtc=7 days) and explaining the role of each parameter in the analysis. This goes beyond 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 description clearly states the tool's purpose: analyzing idle Mercury bank balances for yield routing into sUSDS. It uses a specific verb ('computes', 'evaluates') and distinguishes from siblings like mercury.accounts and treasury.yield_route by focusing on sweep analysis and recommendations.

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 workflow (step 1-4) and states that the tool does not move funds. It defines when to use it (after mercury.accounts) and includes safety rules. However, it does not explicitly contrast with alternatives like settlement.execute for fund movement.

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, not destructive. Description adds nuance about DPX-tagging logic (memo contains 'dpx:') which is behavioral context beyond annotations. No contradiction.

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

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

Two sentences pack all essential information: purpose, output fields, filter condition, and prerequisite step. No redundant 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 output schema exists (confirmed by context), description is fully adequate. It explains what the tool returns, how to use it, and why it's needed (DPX reconciliation). No gaps.

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

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

Schema coverage is 100%, so baseline 3. Description adds value by explaining that accountId comes from mercury.accounts and clarifies limit/offset pagination through context. Default values (20, 0) and max limit (500) are in schema, but usage guidance for accountId is helpful.

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 lists recent transactions for a Mercury bank account and enumerates specific returned fields (ID, amount, status, etc.). Distinguishes itself from sibling tools like mercury.accounts (which provides account IDs) and mercury.send (which sends money).

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

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

Explicitly says to use this for reconciling DPX settlements against bank activity, and guides the agent to obtain accountId from mercury.accounts. Implicitly indicates not for sending or account listing.

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. Description adds behavioral details: pulls from two sources, returns composite score, tier, MiCA flag, and component breakdown. No contradictions, and description enhances transparency 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?

Three sentences, each adding value: first on purpose and inputs, second on data sources, third on outputs and differentiation. No wasted words, front-loaded with key 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 output schema existence, full parameter coverage, and annotations covering safety, the description is complete. It covers inputs, outputs, data sources, and differentiation, leaving no obvious gaps 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 has 100% description coverage. Description adds meaning by explaining data sources (GLEIF, World Bank) and the output structure (composite, tier, MiCA flag, component breakdown), which is beyond the 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?

Clearly states the tool gets a live governance score (0–100) for a legal entity, identifies specific inputs (LEI or company name), data sources (GLEIF, World Bank), and outputs (composite score, tier, MiCA flag, component breakdown). Distinguishes from sibling tool esg.score by isolating the G pillar.

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 context on when to use (governance score, complementing esg.score) and mentions data sources. Does not explicitly state when not to use or list alternative tools, but the differentiation from esg.score serves as a guideline.

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

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

Annotations already declare readOnlyHint=true, but the description adds critical behavioral details: payment requirement, 402 response without txHash, and output composition. This goes beyond what annotations offer, enhancing transparency.

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

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

The description is concise (3-4 sentences), front-loads the main purpose, and efficiently conveys payment mechanics. Every sentence adds value with no redundancy.

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

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

Given the tool's complexity (pay-per-use, multiple domains, output schema exists), the description covers essential aspects: core function, payment mechanism, parameter options, and output content. It is sufficiently complete for an agent to decide usage.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant behavioral context for parameters, especially the txHash (payment unlocking) and focus (optional for full briefing), which are not fully captured in 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 description clearly identifies the tool as returning a macro intelligence briefing from the DPX Stability Oracle, specifying content like confidence scores, outlook, alerts, and forward signals across multiple domains. It distinguishes from sibling tools like oracle.stability or oracle.status by naming the specific oracle and listing covered domains.

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

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

The description explicitly states the pay-per-use cost and behavior when txHash is omitted (returns payment instructions with 402). It provides clear when-to-use context but does not explicitly exclude alternative tools or conditions where this tool should not be used.

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 (readOnlyHint, etc.) are consistent with the description. The description adds valuable behavioral context: returns structured outputs like network health score, regime classification, node data, and explains data sources. 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 quite long and detailed, covering output fields and data sources. While comprehensive, it could be more concise. It is well-structured but every sentence might not earn its place.

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

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

Given the tool's complexity and the existence of an output schema, the description provides a complete picture: what it does, how it works, what it returns, and data sources. No 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?

With 0 parameters and 100% schema coverage (empty schema), baseline is 4. The description adds no parameter info, but it thoroughly explains what the tool returns, which compensates for the lack of parameters.

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

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

The description clearly states the tool's purpose: modeling the global financial system as a network to detect crisis formation from topology. It distinguishes from siblings by emphasizing its unique network-topology approach.

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 explains when to use this tool (for crisis detection from network topology) and highlights it as the only oracle reading network topology, providing usage guidance. It does not explicitly mention when not to use or alternatives, but the context strongly implies a specific niche.

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 the description's mention of 'Get live health status' reinforces safety. The description adds useful behavioral context: returns per-rail status (OPERATIONAL/DEGRADED/DOWN), latency, last incident, and composite score. However, it does not disclose potential issues like rate limits or data freshness. With annotations providing the safety profile, a score of 3 is appropriate.

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

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

Four sentences with zero redundancy. The first sentence states purpose, the second lists return fields, the third lists key rails, and the fourth gives usage context. Every sentence earns its place.

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

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

Given the tool's simplicity (2 optional params, output schema exists), the description covers purpose, usage timing, return content, and examples. No gaps remain for an AI agent to be uncertain about when or how to invoke this tool.

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

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

Schema coverage is 100% with both parameters already described. The description lists the valid rails and regions but adds no new semantic meaning beyond 'Specific rails to check' and 'Filter by region'. The baseline of 3 applies 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 starts with 'Get live health status of local payment rails relevant to a settlement', which is a specific verb+resource pair. It clearly distinguishes from sibling tools like oracle.stability (general stability) and oracle.intelligence (broader analysis) by focusing on real-time per-rail health for settlement decisions.

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 'Call this before domestic or regionally-specific settlements to confirm the destination rail is healthy.' This provides clear when-to-use guidance. While it doesn't explicitly list when not to use or alternatives, the context is well-understood from the sibling list and the 'before settlements' directive.

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, but the description adds valuable context: it is live, backed by 25+ institutional data sources, and cross-validated. The conditional action ('hold large settlements') further clarifies behavioral expectations.

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

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

The description is front-loaded with the core purpose and outputs, then adds supporting details. Each sentence adds value without redundancy, achieving clarity within a compact space.

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 tool with an output schema, the description fully covers what the tool does, what it returns, and how to interpret results. No gaps are evident, and it provides sufficient context for an AI agent to decide when 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 tool has zero parameters, so the description does not need to explain parameter meaning. The baseline for no parameters is 4, and the description appropriately focuses on outputs, which suffices.

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 provides a live macro stability assessment for DPX settlement infrastructure, listing specific outputs like risk score, status, peg deviation, AI reasoning, and recommendation. It stands distinct from sibling tools like oracle.status or oracle.intelligence by focusing on stability and settlement implications.

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

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

The description specifies when to hold large settlements (UNSTABLE or peg deviation >= 50 bps), providing actionable guidance. However, it does not explicitly state when not to use this tool or suggest alternatives among siblings, leaving room for improvement.

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, conveying safety. The description adds that it includes an 'AI intelligence briefing' but does not disclose any behavioral traits beyond these annotations, such as rate limits or data freshness.

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 with zero waste. The first sentence states the core action, the second enumerates outputs concisely. Ideal structure for a simple retrieval 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 and an output schema exists, the description is complete. It covers what is returned (9 signal layers plus AI briefing) without needing to detail output schema. No gaps for a read-only retrieval tool.

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

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

There are zero parameters, and the input schema is empty. Per guidelines, a baseline of 4 applies. The description adds no parameter info as none exist, but does not detract.

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

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

Description clearly states it retrieves the full output from the latest DPX Stability Oracle run, listing all 9 signal layers. This verb+resource combination is specific and distinguishes it from siblings like oracle.stability or oracle.intelligence which likely have different scopes.

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 to get the latest run output but provides no explicit guidance on when to use vs. alternatives (e.g., oracle.stability, oracle.intelligence). No exclusions or context for when not to use this tool are mentioned.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about the return content (list of sections) but does not disclose additional behavioral traits beyond what annotations provide. This is adequate but not exceptional.

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: two sentences. First sentence states purpose, second gives usage guidance and lists return sections. No redundant information. Front-loaded with critical 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's low complexity (one optional parameter, output schema present), the description fully covers what the tool does, when to use it, and what it returns. No 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 description coverage is 100% for the single parameter 'section', with enum values fully described. The description does not add additional semantic meaning beyond the schema's enumeration. 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 explicitly states it returns a structured investment memo for a specific entity (DPX / Untitled_ LuxPerpetua Technologies, Inc.), using clear verb 'Returns' and specific resource. It is easily distinguishable from sibling tools which cover analytics, fees, oracle, and settlement functions.

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

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

The description provides explicit guidance on when to use the tool: for due diligence, evaluating DPX as an investment opportunity, or building a company report. It does not explicitly state when not to use, but the sibling tools are sufficiently different to imply exclusions.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds specific details about what the manifest returns (contract addresses, URLs, endpoints), enhancing transparency without contradiction.

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

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

Two sentences, no wasted words. The first sentence states the purpose, the second lists contents and usage advice. Front-loaded 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 discovery tool with zero parameters and an output schema, the description fully covers what to expect: capabilities, assets, addresses, URLs, and endpoints. It is complete enough 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?

Since the tool has zero parameters, the description cannot add parameter details beyond the schema. The baseline score of 4 applies as no further compensation is needed.

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

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

The description clearly states the verb ('Get') and the resource ('DPX protocol manifest'), listing specific contents like capabilities, supported assets, and endpoints. It distinguishes itself from sibling tools by focusing on the overall manifest.

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 advises 'Call this first to understand what DPX can do,' providing clear context for when to use the tool. It does not mention alternatives, but the directive 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?

Description adds behavioral details beyond annotations: card expires after first authorization or 12 hours, async with task ID and polling. Annotations are consistent (non-readonly, open-world, non-idempotent, non-destructive). 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?

Front-loaded with main purpose and key characteristics. Follows with usage context, async behavior, polling instruction, and scope requirement. Efficient but could be slightly tighter; still very good.

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

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

Covers all essential aspects: what the tool does, when to use (funding DPX fiat leg), how it works (async, polling), prerequisites (cards:read_agentic scope). Output schema exists but description informs about task ID return. Complete for the complexity level.

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

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

Schema coverage is 100%, so baseline is 3. Description adds minor context (e.g., 'amount cap' for amount, 'informational' for merchant_scope), but most parameters are already well-described in the schema. No significant additional meaning.

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 creates a scoped Ramp Agent Card with specific characteristics (single-use, merchant and amount cap, short expiration). Distinguishes from siblings like ramp.settle by focusing on card creation for DPX settlement funding.

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

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

Explicitly says 'Used to fund the fiat leg of a DPX settlement without pre-funding a crypto wallet,' giving a clear use case. Mentions polling for result but does not explicitly exclude alternative tools; context from sibling tools helps differentiate.

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

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

Annotations indicate readOnlyHint:true, non-destructive, idempotent. The description adds substantial context: it performs five checks in parallel with specific thresholds ($10K, $100K), uses OpenSanctions and GLEIF, and defines the return values precisely. No contradiction with annotations; description enriches understanding of the tool's behavior.

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

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

The description is well-structured with numbered checks and front-loaded purpose. While informative, it is slightly verbose (e.g., repeating 'OpenSanctions' twice) and could be trimmed without losing clarity. Still, it effectively communicates the tool's 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 tool's complexity (8 parameters, 5 checks, output schema exists), the description is remarkably complete. It covers the logic, thresholds, outcomes, and appropriate actions. The output schema is not shown but the description explains the return values adequately for an agent to use the tool correctly.

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

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

Schema coverage is 100% with descriptions for all 8 parameters. The description adds extra meaning by explaining how parameters affect the checks (e.g., paymentType triggers PEP, counterpartyLei enables UBO chain). This goes beyond the schema, justifying a score above 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 clearly specifies the tool as a compliance pre-screen for Ramp accounting agent payments before issuing an Agent Card. It details the five parallel checks and defines outcomes (APPROVED/FLAGGED/BLOCKED). It implicitly distinguishes from sibling tools like compliance.pep_screen and compliance.ubo_chain by being a comprehensive screen rather than a single check.

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: 'run before issuing an Agent Card to eliminate unnecessary human approval queues.' It provides clear action guidelines for each outcome: issue card for APPROVED, halt for BLOCKED, route to compliance for FLAGGED. It also quantifies the benefit (removing human-in-the-loop for ~95% of payments).

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