DPX — Institutional Cross-Border Settlement

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 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?

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?

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?

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?

The description adds valuable behavioral context beyond annotations: required scopes, one-time call nature, and automatic token refresh. The readOnlyHint=true annotation is consistent with the tool's action of returning a URL (not modifying state), so no contradiction. However, it does not clarify behavior on subsequent calls (e.g., idempotency or error handling).

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

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

The description is concise, consisting of three sentences that front-load the core purpose, then provide critical details (OAuth URL, scopes, lifecycle). 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?

For a simple authorization tool with one parameter and an output schema, the description covers purpose, output, usage, scopes, and token management. Minor omission: it does not specify behavior if called again after initial setup (e.g., returns same URL or error), but overall it is highly complete.

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

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

The schema already provides 100% coverage for the single parameter tenant_id with a clear description. The tool description does not add further semantic value beyond stating the parameter will be used in the callback. Thus, baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Connect' and the specific resources: 'a Ramp corporate account to DPX settlement'. It also details the output (OAuth authorization URL) and the action required from the user. This distinguishes it from sibling tools like ramp.agent_card or ramp.settle.

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

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

The description provides explicit context: 'Call once per tenant' and lists required scopes. It instructs the user to direct the user to the URL. However, it does not mention when not to use this tool or suggest alternatives, but the context is sufficiently clear for typical use.

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

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

Annotations indicate a write operation and destructiveness. The description adds behavioral context beyond annotations, such as the ~30-second settlement speed and the fact that it combines card creation. This supplements the minimal annotation hints.

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

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

The description is four sentences, front-loaded with the purpose. Each sentence provides distinct value: purpose, roles of Ramp and DPX, outputs/speed, and prerequisite. 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 complexity (10 parameters, output schema present), the description covers core behavior, speed, prerequisites, and outputs. It lacks examples or error context but is otherwise sufficient for an agent to understand when and how to use the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add further meaning to parameters beyond what the schema already provides, sticking to output-related details.

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

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

The description explicitly states 'Execute a DPX stablecoin settlement funded by a Ramp Agent Card — combines card creation and settlement in one call.' This clearly identifies the verb, resource, and unique combination, distinguishing it from siblings like settlement.execute and ramp.agent_card.

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 mentions that no crypto wallet pre-funding is required and that a Ramp account connected via ramp.connect is needed. However, it does not explicitly state when to use this tool versus alternatives (e.g., settlement.execute) or provide exclusions for specific scenarios.

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

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

Annotations already indicate read-only and non-destructive behavior; the description adds context about return data (totals, top vendors, savings) and calculation specifics (3.0% vs 2.035%), with 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 front-load purpose and key outputs, including specific rate comparisons, 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?

Output shape is described, prerequisites noted, and annotations cover safety; could hint at pagination or error cases, but overall sufficient for a read-only analysis 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 descriptions for both parameters; the description adds no new semantics beyond the schema, so it meets the baseline.

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 analyzing a connected Ramp account's wire/international bill volume to surface DPX settlement opportunity, distinguishing it from sibling tools like analytics.overview or ramp.settle.

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

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

It states the prerequisite (requires ramp.connect) and implicitly indicates use for wire/international bill analysis, but does not explicitly list when to avoid or compare to alternatives.

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

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

The description discloses behavioral traits such as checking oracle conditions, reasoning with Claude AI, and executing on-chain. It warns about sandbox mode and mentions returned fields. This adds context beyond annotations (destructiveHint=true), and there is 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 a single efficient paragraph of 4–5 sentences, front-loading purpose and key details. Every sentence adds value without 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 complexity (9 parameters, output schema), the description covers tool functionality, process, output fields, and sandbox behavior. It is complete enough for an AI agent to use effectively.

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 some context (e.g., sandbox default, purpose values) but does not provide substantial new semantics 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 starts with 'Execute a DPX cross-border settlement', a specific verb and resource. It clearly distinguishes from sibling tools like settlement.quote and settlement.status, defining its role as the execution 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 states a key guideline: 'Default: sandbox=true — set sandbox=false only for live execution.' It provides clear context on when to use sandbox vs live, but does not explicitly mention when not to use the tool or alternatives beyond the sandbox note.

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, but the description adds critical behavioral details: the quote is binding, valid for 300 seconds, and includes oracle status and AI reasoning. 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 extremely concise—two sentences: first defines purpose and return fields, second gives usage guidance. No wasted words, optimally front-loaded.

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

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

Given 4 parameters, rich output schema, and detailed annotations, the description covers all essential aspects: fees breakdown, validity, prerequisite relationship, and oracle status. 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% with each parameter described. The description does not add new parameter-level information beyond the schema, so 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's action ('Get a binding fee quote'), the specific resource ('DPX settlement'), and explicitly distinguishes it from the sibling tool settlement.execute by requiring it to be called first.

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

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

Provides explicit usage guidance ('Always call this before settlement.execute'), clarifying the sequential dependency. Lacks alternative scenarios or when-not conditions, but the context is sufficient for correct selection.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds value by detailing the full audit record returned, including specific data fields 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 sentence clearly front-loads the action and lists return fields. 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?

With output schema present (not shown), description adequately covers purpose, parameter, and return specification. Simple tool with one parameter, complete information provided.

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 parameter description. Description adds context about the parameter's origin ('from the settlement.execute tool') and format ('dpx_...'), exceeding 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?

Description clearly states 'look up a previous DPX settlement by settlement ID' and lists specific return fields (status, tx hash, amounts, etc.), distinguishing it from siblings like settlement.quote and settlement.execute.

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?

Implies use after settlement.execute but does not explicitly state when to use versus alternatives like esg.score or oracle.status. No when-not or direct sibling comparison.

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