China Macro & Supply Signals

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the tool makes zero network requests and that each output row is enriched with stable identity, freshness, evidence gaps, review priority, and a human action. This adds meaningful behavioral context without contradicting the annotations.

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

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

The two-sentence description is dense but efficient: the first sentence states purpose, the second covers output behavior, the no-network guarantee, and pricing. No filler, but the second sentence is long and packs many clauses; still appropriately sized for the tool's 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?

For a tool with a large nested schema and no output schema, the description captures the core workflow (compare snapshots), key output enrichment, and the critical constraint (no network requests). The schema's root description handles the one-of condition and legacy productUrls, so the tool-level description remains a solid high-level guide.

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% for all parameters, so the schema already documents fields, types, and constraints. The description adds only a high-level summary of compared attributes (price, MOQ, stock, supplier, badge, promotion) but does not explain parameter syntax or relationships beyond what the schema already provides. Baseline 3 applies.

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

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

The description uses a specific verb ('Compare') with a precise resource ('buyer-owned, merchant-authorized, or licensed 1688 offer exports') and enumerates the compared attributes (price, MOQ, stock, supplier, badge, promotion changes). It clearly distinguishes this tool from sibling China-focused monitors by targeting 1688 supplier data specifically.

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 defines the intended input type (authorized offer exports) and the operational context (no login, scraping, API, or URL fetch), which implies offline use with buyer-provided data. It does not explicitly name alternatives or state when not to use, but the clarity of purpose and constraints provides strong usage 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 provide readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the cost per call ($0.02/call) and a cryptic 'paid-delivery-safe deltas' phrase, but does not elaborate on what 'paid-delivery-safe' means or how deltas behave. This adds some value beyond annotations but lacks rich behavioral detail.

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

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

The description is exactly two sentences, front-loaded with the core purpose and followed by pricing. Every word serves a purpose, and it is concise without being under-specified, though 'x402 (USDC on base)' is slightly cryptic.

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

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

With no output schema, the description should hint at return values, but it only says 'flows and positions' and 'deltas' without elaborating on output structure or delta computation. The schema richly documents inputs, but the agent remains unclear about what the response contains or how to interpret 'paid-delivery-safe deltas'.

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 the 5 parameters, including detailed info like year ranges, dataset enums, watchName patterns, and cache age. The description itself does not add much semantic value beyond echoing 'assets and liabilities' from the datasets field, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Monitor official OECD China FDI financial flows and positions by assets and liabilities'. It uses a specific verb (monitor), a distinct resource (China FDI from OECD), and notably differs from sibling tools like supplier or LEI monitors. The scope and data source are unambiguous.

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

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

The description implies usage for tracking China FDI data, but does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools are in unrelated domains, so confusion is minimal, but no explicit 'use when' guidance is given. The pricing note is not a usage 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 and destructiveHint=false, so the safety profile is established. The description adds context about the external GLEIF data source and the cost per call ($0.02/call, x402), but it does not describe return format, pagination, rate limits, or other behavioral traits. It provides some value beyond annotations but not rich detail.

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

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

The description is composed of two concise sentences: one for the purpose and one for pricing. It is front-loaded with the main action and contains no filler words, making it 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?

Despite a detailed schema, the description lacks any mention of what the tool returns or how changes are reported. With no output schema, this is a significant gap: the agent does not know what to expect from the call. For a 9-parameter tool with scheduled monitoring semantics, more context about output shape and change-detection behavior is needed.

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%; all 9 parameters have detailed descriptions in the schema, so the schema carries the semantic burden. The tool description itself contributes no parameter information, so the baseline of 3 is appropriate.

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

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

The description clearly states 'Monitor official GLEIF LEI records for entity, registration and parent-relationship changes in mainland China and Hong Kong.' It specifies the verb (monitor), the resource (GLEIF LEI records), and the geographic scope, which distinguishes it from sibling tools focused on suppliers, FDI, or macro revisions.

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

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

The description implies the use case by naming the data source (GLEIF) and region (CN/HK), but it provides no explicit when-to-use guidance or alternatives. There is no mention of when not to use this tool or how it compares to sibling tools, so usage is only implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds contextual details about the data source (World Bank WDI source=2) and pricing ($0.02/call), which are useful operational insights beyond annotations.

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

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

The description is a single, front-loaded sentence with a concise pricing tag. Every word 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?

With no output schema, the description should clarify what the tool returns (e.g., list of observations/revisions), but it only says 'monitor' without specifying the output shape. The schema covers input constraints well, but return semantics are incomplete for an agent deciding whether 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?

Schema description coverage is 100%, so the schema already thoroughly documents all four parameters. The description does not add extra parameter-level meaning, thus meeting 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 states the tool monitors 'China macro observations and historical revisions' from the World Bank WDI source=2 API, with a specific verb and resource. It distinguishes itself from sibling monitors by focusing on China macro data and revisions.

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

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

The description gives clear context that this tool is for China macro data monitoring from WDI, but it does not explicitly mention when to use it over alternatives or list exclusions. It implies usage via the domain-specific focus.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond that: the tool is free, it lists every paid tool, and it includes payTo address and network details, which are essential for payment setup. This helps the agent understand the tool's role in the transaction process without contradicting the annotations.

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

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

The description is two short sentences, front-loaded with 'Free' and the action 'list.' Every word adds value: pricing, bundle scope, specific data fields, and a usage directive. No redundant or filler content.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description is fully sufficient. It explains what information is available and when to call it. There are no missing critical details that would impair the agent's ability to use it correctly.

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

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

The tool has zero parameters, so the schema is trivially complete (100% coverage). Per the rubric, 0 params warrants a baseline of 4. The description adds no parameter information because none exist, but it compensates by explaining the tool's output content, which is the relevant semantic context.

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

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

The description uses a specific verb ('list') and identifies the resource ('paid tools in the china-macro bundle') plus the exact contents (price, payTo address, network). It clearly distinguishes this pricing tool from the sibling monitoring tools. The phrase 'Call this first' adds a clear use case, making the purpose unambiguous.

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

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

Explicitly states when to use: 'Call this first if you don't have a wallet ready yet.' This provides direct usage guidance and implies it should be used before the paid sibling tools. It also notes the tool is 'Free,' setting expectations. No alternatives are named, but the 'call first' directive is strong and sufficient for this simple tool.

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