DDG Agent Services

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the output includes a completeness score and the cost, but it does not disclose whether the operation is read-only, what side effects it may have (if any), whether it makes external calls, or any rate limits. For a tool that likely performs external lookups and costs money, this is a significant gap.

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, concise sentence that packs the core function (parse + normalize), scope (US street address), key output (completeness score), and critical cost information ($0.003). Every word carries value, and it is front-loaded with the purpose and cost. No fluff or repetition.

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

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

The tool is relatively simple with a single required parameter and an output schema, so the description does not need to detail return values. However, given the cost and likely external operation, it would be beneficial to mention if the operation is read-only, whether it makes network calls, or any success/failure conditions. The description covers the core, but lacks behavioral context that could affect agent decisions.

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

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

The schema has 0% description coverage for parameters, but the tool has two parameters: 'address' and 'agent_id'. The description clearly implies that the 'address' parameter is the US street address to be parsed, adding meaning beyond the schema. However, it does not mention 'agent_id' or its purpose, leaving that parameter unexplained. The description partially compensates for the low schema coverage but not fully.

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 'US street address parse + normalize with completeness score' clearly states the action (parse and normalize), the resource (US street address), and adds a distinctive output (completeness score). It is specific and distinguishable from siblings, though it doesn't explicitly mention any sibling or scope limitations.

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 that the tool is for parsing and normalizing addresses and returns a completeness score, which suggests use cases like checking address validity. However, it does not provide explicit guidance on when to use this tool over alternatives, nor does it mention any exclusions or compared tools. The clear purpose partly implies the usage, but no when-not-to-use is stated.

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

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

No annotations are provided, and the description only states the return value. It does not disclose whether the operation is read-only, requires any special permissions, or has any side effects. This is a minimal disclosure for a 0-parameter tool.

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

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

The description is a single sentence that immediately conveys what the tool returns. It is front-loaded and contains no extraneous 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 no parameters and an output schema that likely documents the return structure, the description provides adequate context about the return values (radar surfaces and go-live gates). However, the terms 'radar surfaces' and 'go-live gates' may require domain knowledge, but with the output schema present, the description is complete enough.

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 0 parameters and schema coverage is 100% (trivially). The description does not need to add parameter information. According to the guidelines, 0 parameters yields a baseline of 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 'Return' and the specific resource 'AI-agent radar surfaces DDG is targeting' including the aspect of 'current go-live gates'. It distinguishes from sibling tools like ddg_agent_status which focuses on agent status, 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?

The description does not provide any guidance on when to use this tool versus alternatives such as ddg_agent_status or ddg_checkout_conformance. There is no mention of context, prerequisites, 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?

With no annotations, the description carries the behavioral disclosure burden. It usefully adds that the lookup uses DDG-rail settlement history plus public signals, returns an explainable score, and costs $0.002. However, it does not state whether the operation is read-only, requires authentication, or has rate/error behavior.

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

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

The description is a single compact line with no redundant words, and it front-loads the core purpose and key differentiators: reputation source, explainability, and cost. The telegraphic punctuation is slightly awkward but does not harm scannability.

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

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

The output schema may cover return values, but the description leaves four optional parameters without explaining selection semantics or the meaning of agent_id_hdr. Without annotations or any alternative routing guidance, it is not complete for a tool with four plausible identifier inputs.

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 0%, so the description must compensate for the undocumented parameters. It identifies three lookup keys (agent_id, seller endpoint, payTo) but leaves agent_id_hdr unexplained and does not clarify parameter formats, precedence, or how the 'seller endpoint' maps to the endpoint property.

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 conveys a reputation lookup keyed on agent ID, seller endpoint, or payTo, drawing on DDG-rail settlement history and public signals, and producing an explainable score. It clearly names the resource and output, though it reads as a fragment rather than a verb-led statement and does not explicitly distinguish itself from the sibling ddg_seller_trust_badge.

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 no guidance on when to use this tool versus alternatives such as ddg_seller_trust_badge or ddg_agent_status. It only states what data the lookup aggregates, with no conditions, exclusions, or selection criteria.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states what is returned, not any behavioral traits (e.g., read-only, authentication needs, rate limits).

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, no filler. Every word 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 zero parameters and presence of an output schema, the description is mostly complete. Lacks behavioral or usage context but adequate for a simple 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?

Input schema has zero parameters, so schema coverage is 100%. The description adds context about the returned document, which is sufficient. Baseline 4 for 0-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 clearly states the tool returns a machine-readable status document. It uses a specific verb ('Return') and resource ('DDG's machine-readable service/rail/MCP status document'), distinguishing it from siblings like ddg_order_status.

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 guidance on when to use this tool vs alternatives. No context on prerequisites, limitations, or typical use cases is provided.

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

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

With no annotations provided, the description carries the full disclosure burden. It usefully discloses output shape, optional ICS output, and a cost signal ('$0.001'). It does not mention failure behavior or timezone handling, but the core behavioral profile is transparent.

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

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

A single, front-loaded sentence with no filler. Every element adds value: input scope, output format, optional ICS, and cost are all packed efficiently.

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, an output schema exists, and parameter defaults are visible in the schema. The description covers input, output, and cost. It could add timezone-assumption behavior, but the overall context is sufficient 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 description coverage is 0%, so the description must compensate for parameter documentation. It does not explain the 'dates', 'assume_timezone', or 'agent_id' parameters beyond the schema names, and it omits the important timezone-assumption parameter entirely.

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?

States a specific verb ('Parse'), a clear resource ('20+ datetime formats'), and the exact output transformation ('ISO/UTC + epoch + day-of-week, optional ICS'). This is unambiguous and distinguishes the tool from all unrelated siblings in the list.

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

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

The description clearly implies when to use the tool: whenever datetime strings need normalized parsing. It does not explicitly name alternatives or exclusions, but none of the sibling tools offer overlapping calendar-parsing functionality, so the context is sufficient.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does this well by explaining that free/free-trial services return results directly while paid services return an x402 challenge, and by specifying the settle-and-retry flow. It does not mention auth prerequisites beyond the payment headers or what happens on invalid service names, but 'Only known DDG catalog paths are accepted' partially covers that.

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 tight sentences with no filler. The core purpose is front-loaded, followed by the critical payment behavior, and ends with the discovery constraint. Every sentence earns its place.

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

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

For a generic executor over a large catalog, the description covers the essential operational facts: how to target a service, how to discover valid targets, and how paid versus free responses behave. An output schema exists, so return-value details are not required. The main gaps are the unexplained 'agent_id' parameter and the lack of explicit guidance to prefer specialized siblings when available.

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 0%, so the description must compensate. It does add meaning to 'service' by saying it accepts a service_id or /v1/ path, and it clarifies that 'args' are JSON. However, 'agent_id' is entirely undocumented, and no concrete example of a service identifier or args payload is given, so parameter guidance is only partial.

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

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

The description opens with a specific verb and resource: 'Invoke any DDG service by service_id or /v1/ path with JSON args.' It also frames the tool as a 'generic executor over the whole DDG catalog,' which clearly separates it from the many specialized ddg_* sibling tools.

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

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

The description explicitly tells the agent how to discover valid targets ('use ddg_search_services(need) to discover valid targets') and notes that only known catalog paths are accepted. It also explains the free-vs-paid behavior, which affects whether retries are needed. However, it does not explicitly tell the agent to prefer a specialized sibling tool when one exists, so an agent might overuse this generic executor.

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

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

No annotations are provided, so the description carries the burden. It discloses that output is masked and that the operation costs $0.002, which is useful behavioral context. However, it doesn't disclose what happens with invalid numbers, whether the tool performs network calls, or any rate limits. The price and masked output are good additions but not comprehensive.

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 compact sentence that packs the core purpose, output fields, and a key behavioral note (masked output, price). Every word earns its place. It's front-loaded with the primary 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?

The tool has an output schema, so return values are covered elsewhere. The description covers the core purpose and a cost/masking caveat. However, it lacks input format guidance and any usage context (e.g., when to use this vs other card tools). For a paid tool, the missing input format details are a notable gap.

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 0%, so the description must compensate. It mentions 'number' implicitly via 'BIN/IIN fingerprint' but doesn't explain the format expected (e.g., full card number vs BIN only, digits only, length constraints). The agent_id parameter is completely undocumented in both schema and description. This is a significant gap for a tool with only 2 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 states a specific verb+resource: 'BIN/IIN fingerprint' with concrete outputs (network, expected length, Luhn validation). It clearly identifies what the tool computes. It doesn't explicitly differentiate from siblings, but the domain (card fingerprinting) is distinct enough among the listed tools.

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

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

The description implies usage context: it's for card BIN/IIN fingerprinting, and the masked output and price hint suggest it's a paid lookup. However, it doesn't explicitly state when to use this vs alternatives or mention any exclusions. The sibling list contains other card-related tools (ddg_checkout_conformance, ddg_seller_trust_badge), but no routing guidance is given.

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

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

Adds that the tool involves no cost, hinting at non-destructive behavior. However, no annotations provided, and description lacks details on read-only nature, auth requirements, or what the profile contains.

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, front-loaded, no wasted words. Highly concise for a zero-parameter 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 zero parameters and presence of output schema, the description provides sufficient context for purpose and cost. Could elaborate on conformance profile but not essential.

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 exist; schema coverage is 100%. Baseline 4 applies as description adds no parameter info, which is acceptable.

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?

Explicitly states the tool returns a 'public checkout conformance profile' and emphasizes it doesn't cost money, distinguishing it from sibling tools that involve payments.

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?

Implied usage: use when you need the conformance profile without spending money. No explicit when/when-not or alternatives, but straightforward due to zero parameters.

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

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

No annotations are provided, so the description must carry the full burden. It mentions a cost of $0.003, which is a useful transparency cue, but it does not disclose that the operation is read-only, any rate limits, or whether it requires authentication. The cost hint is helpful but insufficient.

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, a single sentence that front-loads the purpose and scope. It is efficient with no waste, though it omits important behavioral and parameter 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?

With no annotations, 0% schema coverage, and an output schema present (but not described), the description is incomplete for a tool that accepts 1-10 addresses and has an optional agent_id. It does not explain the output structure, any error conditions, or the relationship to sibling tools like ddg_crypto_price.

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 0%, so the description must explain parameters. The description says '1-10 addresses' and mentions ethereum/base, but does not explain that the 'addresses' parameter is an array or string, nor the format for the optional agent_id. It adds little beyond the schema.

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

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

The description states a specific resource (crypto portfolio), the action (consolidated USD value), and scope (1-10 addresses, native + USDC on ethereum/base). It is clear but does not explicitly differentiate from siblings like ddg_crypto_price or ddg_wallet_snapshot, though the scope hint helps.

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?

There is no explicit guidance on when to use this tool versus alternatives like ddg_crypto_price or ddg_wallet_snapshot. The description implies it is for portfolio valuation, but no when/when-not conditions or alternative names are given.

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

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

No annotations are present, so the description carries the full burden. It adds meaningful behavioral context: 60-second caching and a $0.001 cost per call, while implying a read-only price lookup. It does not disclose failure modes, unsupported-symbol behavior, or rate limits, but for a simple quote tool the disclosed caching and pricing traits are useful. There is no contradiction with annotations.

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

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

The description is a single front-loaded sentence with no filler, and the cache and cost details justify their inclusion. It is appropriately sized for a simple price tool. The vague 'etc.' and lack of any structural separation keep it from a perfect score.

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 two-parameter price lookup with an output schema, the description covers the core resource, caching, and cost. Missing usage guidance and an unexplained optional parameter create clear gaps, but an agent could probably make a successful call using the provided symbol examples. Since an output schema exists, detailed return-value documentation is not necessary.

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 0%, and the description does not explicitly map to the schema's parameters. It does provide concrete symbol examples, which helps the agent understand what 'symbols' likely accepts, but it leaves the optional agent_id parameter completely unexplained and does not clarify the string-or-array flexibility. The cache/cost note is behavioral, not semantic, so parameter meaning remains mostly under-specified.

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 resource ('USD prices') and the scope of symbols ('eth/usdc/usdt/wbtc/aero/degen etc.'). It lacks an explicit verb like 'gets' or 'returns,' but 'USD prices for' strongly implies retrieval and the tool name reinforces it. It is broadly distinguishable from crypto siblings like portfolio or token metadata, though it does not call out any specific alternative.

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?

There is no guidance about when to use this tool versus related tools such as ddg_crypto_portfolio, ddg_token_estimate, or ddg_eth_gas. No contexts, exclusions, prerequisites, or alternatives are mentioned. An agent must infer usage entirely from the tool name and the short description.

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

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

With no annotations, the description carries the full burden. It discloses the payment protocol (x402), the need for payment_headers, and the existence of free-trial calls. It does not detail error behavior or what happens if payment is missing, but it is reasonably transparent for a complex paid API endpoint.

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

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

The description is three concise sentences, each serving a purpose: stating the function, explaining the payment flow, and directing to additional resources. It is front-loaded with the main action and avoids 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 the tool's complexity (paid API with multiple endpoints) and the presence of an output schema, the description adequately covers the workflow, payment handling, and hints at available endpoints. It directs the agent to ddg_list_services for exhaustive information, making it complete in the context of the available metadata.

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 0%, so the description must add meaning. It explains the payment_headers parameter's role in the two-step process and mentions agent_id for free trials. However, the path parameter is described only as 'allowlisted endpoint' without specific values, and body is not explained, so coverage is partial but 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?

The description clearly states it calls an allowlisted paid DDG data endpoint and lists examples, distinguishing it from sibling tools like ddg_ethereum_rpc_query or ddg_fetch_public_resource. The verb 'call' with the resource 'allowlisted DDG paid data endpoint' is specific and informative.

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 the two-step process: call without payment_headers for a price quote, then retry with payment_headers for results. It also mentions free-trial calls and directs the agent to ddg_list_services for exact schemas and prices, providing clear when-to-use and how-to-use guidance.

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

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

No annotations are provided, so the description bears full responsibility. It accurately states the tool returns public addresses, but lacks details on safety (e.g., read-only nature) or response characteristics. Adequate but not enriched.

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

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

One sentence of 13 words that front-loads the core action and resource. No wasted words; efficient and clear.

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 parameters and an output schema (not shown), the description is sufficient for a simple lookup tool. Minor room for improvement: could note that these are public addresses or suggest related tools, but overall complete enough.

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

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

The input schema has zero parameters, so the description need not add parameter info. Baseline of 4 is appropriate; description adds nothing beyond schema, which is sufficient.

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

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

The description clearly states the tool returns 'DDG's public direct-crypto receiving addresses', specifying the resource and action. It distinguishes from siblings by adding 'for manual/beta payment routing', which hints at a niche use case among payment-related tools.

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

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

The description implies the tool is for manual/beta payment routing but does not explicitly state when to use it over siblings like ddg_quote_payment or ddg_submit_order. No exclusions or alternatives 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?

With no annotations, the description is the main behavioral signal, and it does add useful context: the operation costs $0.05 and produces a sha256-pinned artifact. However, it does not disclose side effects, persistence of the evidence file, charging conditions, or failure behavior, so it only partially carries the burden.

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?

A single, front-loaded sentence conveys the core facts—inputs, output, hashing, and price—without wasted words. Every part of the 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?

An output schema exists, so return values need not be explained in prose, but the operational contract is under-specified: it is unclear which inputs are required, whether any combination is valid, and what the evidence file is for. For a paid multi-source aggregation tool with three undocumented nullable parameters, this is not enough.

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 0%, so the description needs to explain the parameters, but it only loosely maps 'receipt lookups' to receipt_ids and 'Base on-chain tx proofs' to tx_hashes. The agent_id parameter is not explained, and nothing clarifies whether or how many inputs are actually 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 states a specific verb ('bundle') and identifies the inputs (DDG receipt lookups, Base on-chain tx proofs), the output (sha256-pinned evidence file), and the cost. This clearly differentiates it from sibling tools like ddg_tx_status or ddg_receipt_verify_design.

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 when-to-use guidance, prerequisites, or alternative tools are mentioned. The word 'evidence' implies a dispute/audit context, but an agent is not told when to prefer this over a direct receipt or transaction 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?

With no annotations, the description must carry the behavioral burden. It does disclose the paid nature ($0.001) and the WHOIS data source, which is useful, but it does not state read-only behavior, potential latency/failure, or how trust band is derived. This is adequate for a simple lookup but leaves clear gaps.

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 no filler; it packs purpose, output fields, source, and price into minimal words. Every element earns its place.

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

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

For a one-required-parameter lookup with an output schema, the core call is just 'domain', so the description is minimally viable. It is incomplete on usage guidance and the optional agent_id, but the output schema covers return-value details and the complexity is low.

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 is no parameter documentation and schema description coverage is 0%. The required 'domain' parameter is inferable from the tool purpose, but the optional 'agent_id' parameter is completely unexplained in both schema and description, and domain format requirements are not stated.

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

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

The description states the exact output: WHOIS creation date, age, and trust band, making the resource and purpose clear. It lacks an explicit verb but is unmistakably a domain-age lookup, and no sibling tool covers this domain. Full 5 is withheld because 'trust band' is undefined and the phrasing is a bare noun phrase.

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?

There is no statement of when to use this tool versus alternatives, no exclusions, and no comparison to the many ddg_* siblings. The only context is the implied scenario of needing domain creation/age/trust-band data, which is not enough guidance for tool selection.

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

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

No annotations are provided, so description carries full burden. It discloses read-only nature and sync-gating (node sync requirement), but lacks details on error conditions, rate limits, or authentication needs. Vague term 'sync-gated' could be clearer.

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 with no unnecessary words. Front-loaded with key information (proxy, free, read-only, Reth node, sync-gated). Every part 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?

Output schema exists (not shown), which may document return values. But description lacks request formatting details, allowed methods, or examples. For a query proxy tool, more context would enhance usability, though not critically missing.

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

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

Schema description coverage is 0%, so description must add meaning. It only says 'proxy a query' without explaining the 'body' parameter structure (e.g., JSON-RPC format) or 'agent_id' purpose. Very little added value beyond parameter names and types.

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 proxies a free read-only Ethereum JSON-RPC query through a DDG private Reth node. Verb and resource are specific, and it distinguishes from sibling tools like ddg_data_query or ddg_tx_smoke_test 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?

No explicit guidance on when to use this tool vs alternatives. The 'free read-only' hint suggests it's for Ethereum data queries, but no when-not or alternative tool mentions. Usage context is implied by the tool name and description but not explicitly clarified.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only lookup, whether it hits live network data, whether authentication is required, or whether any side effects occur. The output fields are listed, but operational behavior is not disclosed.

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

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

The description is extremely concise and front-loaded with the most important output information. Every phrase carries meaning and there is no filler. It is slightly telegraphic and comma-separated, but it remains efficient for a simple lookup 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?

The presence of an output schema covers return-shape details, and the tool is simple with only two optional parameters. However, the description lacks usage guidance relative to ddg_gas_multi, leaves 'agent_id' unexplained, and provides no behavioral safety context. It is minimally viable but has clear 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 description coverage is 0%, so the description must compensate. It partially does by listing the four supported chain values for the 'chain' parameter, but 'agent_id' is left completely unexplained, and there is no mention of defaults or optionality. An agent cannot fully understand parameter meaning from this definition.

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 enumerates what the tool returns: gas price, base fee trend, priority bands, and simple-transfer cost in USD. It names the resource and supported chains, so an agent can infer this is a gas-fee lookup tool. It lacks an explicit verb like 'fetch' or 'get,' but the output-oriented phrasing is specific enough to avoid tautology.

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?

There is no guidance on when to use this tool versus alternatives such as ddg_gas_multi or ddg_crypto_price. The chain list provides context, but no criteria, exclusions, or preferred-use cases are stated. An agent cannot distinguish this from sibling gas-related tools based on the description alone.

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

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

With no annotations, the description solely carries the burden of behavioral disclosure. It mentions 'redaction and size caps' but does not explain what they entail, whether the operation is read-only, or how errors are handled for non-allowlisted resources.

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 no redundant words. However, it could be expanded slightly without sacrificing conciseness to cover missing details.

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

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

Given the tool has one required parameter and no annotation, the description omits output expectations, error scenarios, and the impact of size caps/redaction. The presence of an output schema does not fully compensate for missing explanations.

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 0% so the description must compensate. It suggests the parameter accepts an id or ddg:// URI but does not specify format, validation, or examples. The single parameter 'resource' remains ambiguous despite the hint.

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 'Fetch' and identifies the resource as 'allowlisted DDG public manifest/doc', clarifying both the action and the object. It distinguishes from sibling 'ddg_public_resource_index' which lists resources, so the purpose is clear.

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 does not provide any explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites like obtaining an ID or URI from an index. The context is implied but not directly stated for an AI agent.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses aggregation behavior ('in one call') and pricing ($0.002), and the operation is implicitly a read-style query. It does not disclose defaults for omitted chains, authentication needs, or failure behavior, but the core behavior is reasonably clear.

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?

A single front-loaded sentence with no filler. Every element—scope, chains, aggregation benefit, and cost—earns its place.

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

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

The output schema may cover return values, but the description still leaves the agent guessing about how to specify chains, whether agent_id is needed, and what the default behavior is. Given the optional parameters and the existence of a similar single-chain sibling, more context is needed for confident 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 0%, so the description must compensate for both parameters. It only hints that 'chains' relates to the four named networks and says nothing about accepted value formats, defaults, or the purpose of agent_id. This leaves a significant semantic gap.

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

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

The description clearly identifies the tool's function: returning gas and transfer cost data across ethereum, base, arbitrum, and optimism in a single call. It lacks an explicit verb like 'get' or 'estimate' and does not name a sibling tool, but the scope and resource 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 'in one call' phrasing implies this tool is for multi-chain gas and transfer cost queries. However, it provides no explicit guidance on when to prefer this over the sibling ddg_eth_gas, no exclusion criteria, and no mention of what happens when the optional chains parameter is omitted.

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

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

With no annotations, the description itself must convey side-effect and safety behavior; 'Extract' and 'raw HTML' imply a read-only transformation with no external mutation. It also discloses the $0.002 cost, which is useful operational context. It does not discuss limits, error cases, or optional-parameter effects, but the core stateless behavior is clear.

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 sentence and front-loads the action and cost. The 'selectors=...' fragment adds a compact hint about parameter shape but is cryptic and not formatted as a clear example. It is appropriately brief, though slightly under-explains.

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?

Although an output schema exists, the description lacks context around the three optional parameters and gives no selection guidance relative to the large sibling set. For a tool with five parameters and no annotations, this terse description leaves meaningful gaps. It covers the happy path but not enough for confident invocation in edge cases.

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 0%, so the description must compensate, but it only touches 'selectors' via the 'selectors={'name': 'css'}' hint as a mapping of field names to CSS selectors. 'html' is inferable from 'raw HTML,' but 'attr,' 'mode,' and 'agent_id' are left completely unexplained. This is insufficient for a five-parameter schema.

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

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

The description opens with a specific action ('Extract structured JSON from raw HTML via CSS selectors'), naming the input, mechanism, and output. It is distinguishable from the sibling list even though it does not explicitly contrast with any sibling. The trailing code-like 'selectors={'name': 'css'}' is cryptic but does not obscure the core purpose.

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

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

The description implies the tool is for parsing raw HTML into JSON, so an agent can infer a basic use case. It gives no explicit when-to-use/when-not-to-use guidance and names no alternatives among the many sibling tools. Selection is left to inference rather than direct routing.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, authentication requirements, or resource constraints. It only hints at a read-only operation by listing status.

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 one concise sentence with front-loaded verb 'List', but includes vague phrasing like 'such as' and ends with 'etc.' which slightly reduces precision.

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 0 parameters and an existing output schema, the description adequately covers the tool's purpose and output. It could mention what 'free-seat status' means, but overall it is complete.

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

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

There are zero parameters with 100% schema coverage, so the description adds value by explaining the tool's output. The baseline for 0 params is 4, and the description provides sufficient 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 clearly states the tool lists 'free-seat status plus requestable local runtimes' and provides specific examples (Ollama, llama.cpp, LM Studio, etc.), making its purpose distinct from sibling tools like ddg_list_models and ddg_list_services.

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 see available local runtimes) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.

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

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

No annotations provided, so description carries full burden. It states what is listed but does not disclose any behavioral traits such as authentication requirements, side effects, or performance implications. For a read-only list, this is minimally 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?

Single sentence with no wasted words. Verb is front-loaded. Efficiently conveys the tool's scope.

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 sufficiently covers what the tool does. Could be slightly improved by noting it is a discovery step before using request/run tools, but is already complete enough for a simple list endpoint.

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?

Tool has zero parameters. Baseline for 0 params is 4. Schema covers all parameters (none), so description adds no parameter information beyond that.

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 uses specific verb 'List' and identifies resources: local/free Ollama models and queryable paid/account-backed route labels. Clearly distinguishes from sibling tools that request or run models.

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 guidance on when to use this tool vs alternatives. Does not mention prerequisites or context, such as that it should be used to discover available models before requesting or running.

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

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

No annotations exist, so the description must disclose behavioral traits. It only states the tool lists from 'public surfaces,' implying no side effects, but does not mention authentication, rate limits, or whether data is live or cached.

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 with the action verb 'List' front-loaded. Entirely concise 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?

For a parameterless tool with an output schema, the description is adequate but leaves gaps: it does not define 'live/manual services,' clarify the difference between 'pricing' and 'catalog' surfaces, or explain how this relates to sibling tools.

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

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

There are zero parameters, and schema description coverage is 100%. The description adds meaning by explaining what the tool lists, compensating 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 lists 'DDG live/manual services' from 'public pricing and catalog surfaces,' specifying the verb 'List' and the resource 'services.' It is distinct from sibling list tools like ddg_list_models, but no explicit differentiation is provided.

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 guidance on when to use this tool versus alternatives such as ddg_list_models or ddg_list_local_runtime_options. The description lacks context about prerequisites, scenarios, or exclusions.

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

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

With no annotations, the description carries full burden. It discloses the tool returns data but does not state it is read-only, any permissions needed, or potential error cases. However, for a zero-parameter retrieval, the omission is less critical; a 3 is fair as it communicates basic 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 a single sentence of 10 words, front-loaded with the action 'Return', and no redundant phrases. Every word 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 has an output schema (not shown), the description need not detail return values. However, it does not define 'local security controls' or 'publication gates,' which may require domain knowledge. For a simple 0-param tool, this is nearly complete.

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

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

The tool has zero parameters and schema coverage is 100% (trivially). Description adds no parameter details, but baseline for 0 params is 4. No additional information 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 tool returns local security controls and publication gates, using the specific verb 'Return' and identifying the resource. The name 'security_profile' aligns well, and it is distinct from sibling tools like 'ddg_security_service_catalog' which likely covers broader services.

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 guidance is provided on when to use this tool versus alternatives like ddg_security_service_catalog or ddg_skill_safety_scan. The description implies usage for checking security controls but lacks explicit context or exclusions.

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

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

With no annotations, the description must disclose behavioral traits. It only states it 'runs a preview' using a local model. It does not mention whether the operation is idempotent, destructive, or what side effects occur (e.g., network requests, resource consumption). The absence of such detail leaves the agent uncertain.

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 concise sentence that communicates the core purpose without extraneous words. It is front-loaded and direct.

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 4 parameters (1 required) and an output schema, the description fails to explain what the preview does, what the output contains, or any prerequisites. While the output schema may document return values, the description lacks high-level context about the tool's behavior and expected 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 0%, and the description adds no information about the 4 parameters (combo, model, prompt, agent_id). It only hints at 'local Ollama mini-model' but does not clarify which parameter corresponds to that or how prompts or other fields are used.

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 ('Run') and the resource ('free DDG micro-model-swarm preview'), with additional context about using a local Ollama mini-model. While it doesn't explicitly differentiate from siblings, the uniqueness is implied by the combination of 'free', 'micro-model-swarm', and 'local Ollama'.

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 guidance is provided on when to use this tool versus alternatives like ddg_run_paid_model or ddg_list_models. There is no mention of prerequisites, limitations, or exclusion criteria.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds useful behavior: local-only execution, Ollama runtime, a 2-3 model limit, an agreement score, a $0.01 cost, and rejection of account-backed models. It does not cover failure modes or selection behavior when 'models' is null, but provides meaningful 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 entire description is one compact sentence with no filler. It front-loads the core behavior, then adds cost and exclusion constraints economically.

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?

An output schema exists, so return-value documentation is not required in the description. However, the description does not clarify how optional parameters behave, what happens when 'models' is omitted, or how the 2-3 model count is enforced, leaving some ambiguity for a caller.

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 0%, and the description adds almost no parameter-level meaning. It implies 'prompt' is the shared input and that 'models' should be 2-3 local models, but it does not explain optional parameters like 'agent_id' or 'max_output_tokens.'

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 action phrase, 'Same prompt to 2-3 LOCAL models (Ollama),' naming the resource and scope precisely. It also differentiates itself from paid-model siblings by explicitly saying 'Account-backed models are rejected.'

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 is for comparing local Ollama models and excludes account-backed models, which orients an agent away from paid-model tools. It does not explicitly name an alternative sibling, so it falls short of a 5.

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

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

With no annotations, the description carries full burden but only says 'fetch', implying a read operation. It does not disclose what happens if the artifact is not ready, required permissions, or potential side effects. The behavioral disclosure is minimal.

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 sentence with no extraneous words, efficiently conveying the core action and key constraints. It is front-loaded and 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 moderate complexity (two params, many siblings), the description omits preconditions, error handling, and the nature of the artifact. The output schema is present but does not compensate for missing usage and behavioral 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 0%—the description does not explain the parameters. The phrase 'agent-scoped' hints at agent_id's role, but order_id is left implicit. No detail on format or constraints is added beyond the schema.

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

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

The description clearly states the verb 'Fetch' and the resource 'DDG order artifact', and specifies scoping ('agent-scoped') and condition ('when ready'). It distinguishes from sibling tools like ddg_order_status (which provides status) and ddg_submit_order (which submits orders).

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 phrase 'when ready' implies usage context but does not explicitly state preconditions (e.g., check order status first) or provide alternatives. No exclusions or comparisons to siblings are given.

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

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

No annotations are provided, and the description does not disclose behavioral aspects such as polling frequency, side effects, or required permissions. The term 'poll' implies repeated calls, but that is not explicit.

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 concise sentence, front-loaded with the key action and resource. No unnecessary words, but could include more detail without losing conciseness.

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

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

Given the presence of an output schema, the description need not detail return values. However, it lacks information on operational context like polling etiquette or error handling, making it adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It only hints at 'agent-scoped' but does not explain the parameters like agent_id or order_id meaning, default values, or usage.

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 (poll), the resource (DDG order status URL), and the scope (agent-scoped). It effectively distinguishes from siblings like ddg_submit_order or ddg_order_artifact.

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 guidance on when to use this tool vs alternatives, no conditions or exclusions provided. Sibling tools exist but no differentiation is made.

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

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

No annotations are present, so the description carries the full burden. It usefully discloses the $0.002 cost and hints at the return fields, but it does not describe failure behavior, data sources, privacy considerations, or whether any state changes occur.

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

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

The description packs the core purpose, expected outputs, and even pricing into a single front-loaded line 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 tool is relatively simple and an output schema exists, but the missing parameter explanations and lack of usage guidance leave an agent uncertain about optional fields like region and agent_id.

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 0%, so the description must compensate. It adds meaningful hints about E.164 and country, but it does not explain the 'phone' input format requirements, the semantics of 'region', or the purpose of 'agent_id'.

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 does phone parsing/validation and names the key outputs: E.164, country, line type, and carrier hint. It is specific enough to be distinguishable from siblings like ddg_address_validate, though it does not explicitly name any sibling.

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 guidance is provided about when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The agent must infer appropriateness from the tool name and terse description.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It mentions sorting order ('cheapest first') and a cost figure ($0.002), but does not state if the tool is read-only, whether it makes external calls, or any side effects. The behavior is not transparent enough for an agent to anticipate side effects or auth needs.

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 sentence with no fluff, placing the core function ('cost ladder') and the key sorting detail at the front. It is efficient, though brevity comes at the cost of missing 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?

For a tool with three parameters and zero schema coverage, the description is incomplete. It does not clarify parameter roles, usage context, or how it differs from cost-related siblings. Though an output schema exists, the lack of parameter explanation and usage guidance makes it insufficient 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 description coverage is 0%, and the description does not explain any of the three parameters (text, calls, agent_id). The only hint is 'workload' which loosely maps to text, but no details on expected input formats, units, or how agent_id affects results. The description fails to compensate for the lack of schema 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 states the tool provides a 'cost ladder for a workload across DDG routes' with sorting 'cheapest first', which clearly conveys that it returns cost comparisons. It does not explicitly differentiate from siblings like ddg_token_estimate or ddg_model_compare, but the purpose is specific enough that an agent can infer its function.

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 guidance is provided on when to use this tool versus alternatives such as ddg_token_estimate or ddg_run_paid_model. There is no mention of typical scenarios, prerequisites, or exclusions, leaving the agent to guess based on 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?

No annotations provided, so description carries the burden. It correctly indicates a listing operation but adds no details about safety, rate limits, or response behavior. Since it's a simple read-only list, the description is adequate but minimal.

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 with 8 words, front-loaded with the action verb 'List'. No redundancy or filler; every word 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 no parameters and an existing output schema, the description is adequate but could be more helpful by explaining what 'MCP resources' entails or linking to the fetch tool. It's complete enough for a simple list but lacks context for new users.

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 exist (schema coverage 100%). Description adds context by specifying the scope ('allowlisted... available as MCP resources'), which helps understand the output. Baseline for 0 params 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 tool's action ('List') and the specific resource ('allowlisted DDG public manifests/docs available as MCP resources'), distinguishing it from siblings like ddg_fetch_public_resource that fetches a specific resource.

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 (discovery of available resources), but no explicit guidance on when to use vs. alternatives (e.g., ddg_fetch_public_resource for a specific resource). No exclusions or prerequisites 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that no backend compute is executed, which signals a non-executing, likely read-only query operation. It does not mention authentication requirements, potential side effects, or whether a challenge expires, but the core non-execution behavior is transparent.

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

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

The description is a single, front-loaded sentence with no filler. Every clause adds relevant information: the action, the target resource, the route scope, and the critical non-execution behavior.

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 only two optional parameters and an existing output schema, the description communicates the main purpose and the key behavioral caveat. However, it leaves parameter semantics and alternative-tool routing underspecified, so an agent may still need to infer important calling details.

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

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

Schema description coverage is 0%, and the description does not compensate. Neither 'path' nor 'agent_id' is explained, and the only indirect link is 'protected route' suggesting the path parameter. This leaves an agent without enough information to know how to populate or omit the optional 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 gives a specific verb ('Return'), a resource ('payment challenge'), and a clear scope ('supported DDG protected route'). The phrase 'without executing backend compute' also sets it apart from execution-oriented siblings such as ddg_run_paid_model. It is slightly jargon-heavy ('payment challenge'), so it is clear but not maximally explicit.

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

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

The description implies when to use the tool: when a payment challenge is needed for a protected route and no backend compute should be executed. However, it does not explicitly name alternatives like ddg_run_paid_model or state when not to use this tool. Usage context is present but relies on inference.

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

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

There are no annotations, so the description carries the disclosure burden. It does reveal important behavior: release is withheld pending receipt validation, the process costs $0.01, and verification is operator-based. It does not disclose side effects, required permissions, failure behavior, or reversibility, which is material for a financial escrow tool.

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

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

The entire description is one front-loaded sentence that conveys the core workflow and a key constraint. There is no redundant filler or repetition of schema details.

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

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

Despite having an output schema, the description is too sparse for a financial escrow operation with four parameters and no parameter documentation. It omits side effects, failure modes, authorization context, and parameter meaning, so an agent would need substantial external knowledge to call it correctly.

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

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

Schema description coverage is 0% and the description mentions none of the parameters. The required seller_pay_to field, optional evidence_url, payment_headers, and agent_id are left undefined, so an agent cannot infer what values are expected from the tool description.

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

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

The description clearly identifies the action as opening an escrow case and explains that DDG holds the release decision until a completion receipt validates. This is specific enough to distinguish the tool as an escrow-release function, though it does not explicitly contrast with sibling tools such as ddg_receipt_verify_design or ddg_submit_order.

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 phrase 'until a completion receipt validates' implies the intended trigger: use this when a completion receipt exists and needs to be verified before escrow release. However, there is no explicit when-not-to-use guidance or mention of alternatives, leaving usage mostly inferred.

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

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

With no annotations, the description carries full burden. It discloses the tool's not-live state and dependency, which is transparent. However, it does not explicitly state whether the tool is read-only or what side effects exist, leaving some ambiguity.

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, and a clear condition. Every sentence earns its place 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?

Given the tool has 2 parameters and no annotations, the description is incomplete. It lacks explanation of how to use the parameters, what the output looks like (though output schema exists, description could still help), and any prerequisite knowledge. The not-live status is helpful but not enough.

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 0% (no parameter descriptions in schema). The description does not add any meaning for the two parameters (order_id, receipt_hash). The tool description should explain what these parameters represent in the context of the receipt-verification contract.

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

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

The description states a clear verb ('describe') and resource ('planned free receipt-verification tool contract'). It distinguishes itself from operational sibling tools like ddg_order_status by being a design/planning tool. However, 'describe' could be more specific (e.g., returns a schema or documentation).

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 the tool is 'not-live' until a certain backend is implemented, giving clear guidance on when NOT to use it. It implies use for planning/review but does not list alternative tools for the actual operation.

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

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

With no annotations, the description must carry the full behavioral disclosure, and it does usefully warn about ReDoS risk and a $0.002 cost. However, it does not explain side effects, matching semantics, what 'live matching' means operationally, or what happens on failure.

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?

A single compact sentence front-loads the main feature and includes the risk/cost caveat with no filler. The '...' shorthand and '$0.002' notation could be more precise, but the overall structure is efficient.

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

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

For a tool with six optional parameters and no schema descriptions, this description is thin: it fails to state what values kind accepts, what text is for, or how the template mode versus custom pattern mode is selected. The presence of an output schema reduces the need to describe return values, but invocation ambiguity remains significant.

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 0%, so the description must compensate, but it only hints at kind/pattern/samples. It leaves text, agent_id, and ignore_case unexplained, so an agent cannot reliably map the two described modes to the six available 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 defines two distinct operations: using a named regex template (email, url, eth_address, tx_hash) with live matching, and testing a custom pattern against samples. This is clear enough to differentiate the tool from its siblings, though it is phrased as a noun phrase rather than a direct 'builds/tests' verb.

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 guidance is provided about when to prefer this tool over sibling tools or which sibling alternatives exist. The only conditional is the tool's own internal 'or' between template-based matching and pattern testing, which does not help an agent choose this tool over 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?

No annotations are provided, so the description carries full burden. It only mentions that it never auto-downloads, but omits details on queue behavior, permissions, or error handling. The description does not reveal important behavioral traits.

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 brief (two sentences) and front-loaded with the core purpose. However, it is under-specified for the tool's complexity, and additional parameter context would be valuable.

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 5 parameters with 0% schema description coverage and no annotations, the description is insufficient. Even though an output schema exists, the description fails to explain what the tool does in enough detail 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 description coverage is 0%, and the tool has 5 parameters. The description adds no meaning beyond the parameter titles, failing to explain fields like reason, runtime, agent_id, or expected_size_gb.

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 queues a local model/runtime request and explicitly notes it never auto-downloads by public request. This distinguishes it from sibling tools like ddg_run_paid_model or ddg_list_models.

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 vs alternatives. It implies it's for requesting local models that aren't auto-downloaded, but does not clarify prerequisites or contrast with tools like ddg_list_local_runtime_options.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only audit and discloses a $0.01 cost, but it does not explain side effects, authorization needs, or whether the tool returns a report, passes/fails, or aggregate data.

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 highly compact and front-loaded with the resource and domain. There is no filler, but the compression creates jargon-heavy phrasing that may obscure meaning.

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 nested required spec, a nullable agent_id, and a paid chain aggregate, the description is too sparse. It does not clarify how to construct 'spec', when to pass 'agent_id', or what the audit output represents, leaving a capable agent without enough context to call it correctly.

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

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

Schema description coverage is 0%, and the description does not explain the required 'spec' object or the optional 'agent_id' parameter. Terms like 'monotone caps' and 'per-hop expiry' hint at domain content, but there is no explicit mapping to the parameters, so the description fails to compensate for the schema gap.

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 names a specific resource (multi-robot delegation contracts) and the core audit concerns (monotone caps, per-hop expiry/revocation), which distinguishes it from sibling audits like robot_geo_fence_audit and robot_fleet_quota_audit. However, it does not state what the audit returns, and 'chain aggregate' is ambiguous.

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 no guidance on when to use this tool versus the many sibling audit tools. There is no decision rule, exclusions, or mention of alternatives, so the agent must infer usage from the name alone.

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

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

With no annotations, the description carries the behavioral burden. The term 'audit' implies a read-only assessment, and the '$0.01 rate bound' discloses a meaningful cost boundary. However, it does not state whether the tool only reads data, whether the rate bound is enforced or informational, or what happens if limits are exceeded.

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 line with no filler. It front-loads the resource and immediately lists the distinct audit dimensions. Despite its brevity, every phrase earns its place.

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

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

For a tool with a nested, loosely-typed required parameter and no schema descriptions, this definition is incomplete. It provides no usage guidance and no parameter semantics. The presence of an output schema mitigates return-value concerns, but the agent still lacks what it needs to formulate input correctly.

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

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

Schema description coverage is 0%, and the required 'spec' parameter is an opaque additionalProperties object with no field-level documentation. The description mentions audit dimensions but never maps them to concrete input fields. An agent cannot reliably construct the 'spec' object or understand the role of 'agent_id' from this definition.

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 resource ('robot fleet spend-quota') and enumerates the audit's focus: per-robot caps, aggregate cap, unique ids, and a $0.01 rate bound. This differentiates it from sibling fleet audit tools such as geo-fence, delegation-chain, and human-takeover audits. It lacks an explicit main verb, but 'audit' in both name and description conveys the action.

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 no explicit guidance on when to use this tool versus the many sibling audit tools. It does not state conditions, exclusions, prerequisites, or alternatives. Usage is only implied by the name and focus phrases, leaving an agent to infer when this specific audit is appropriate.

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

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

No annotations exist, so the description carries the full burden. It discloses the audit's scope (the four dimensions checked) and a $0.01 cost, both of which are genuine facts not present in structured data. However, it never reveals side effects, whether anything is mutated, the shape of the result, or failure modes — notable gaps for a zero-annotation tool.

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

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

A single sentence, front-loaded with the core purpose followed by four scope dimensions and the cost. Zero waste — purpose, audit dimensions, and the fee are all packed efficiently. Ideal conciseness with no filler.

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

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

An output schema exists, so return values are covered elsewhere. But the tool is complex (multi-dimensional audit fed by a free-form nested spec), and the input format is genuinely undefined: the description lists the dimensions without explaining how they map into the spec object. An agent would struggle to construct a valid `spec` without additional documentation.

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 0%, and the required `spec` parameter is a completely opaque free-form object (additionalProperties: true, no description). The description partially compensates by implying the spec should carry geofence, vertical bounds, outdoor scoping, and speed-cap data. But it never specifies their format (coordinate system, units, bound structure), so the spec shape remains guesswork.

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?

Names a specific verb (audit) and resource (physical/geographic authority) and lists the concrete scope dimensions: geofence, vertical bounds, outdoor scoping, speed cap. This distinguishes it from sibling audits like ddg_robot_delegation_chain_audit and ddg_robot_fleet_quota_audit, since this is clearly the geographic variant of the robot audit family. Slightly cryptic phrasing ('authority audit') costs it a 5.

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 guidance on when to use this tool versus alternatives. It never states which situations call for this audit over ddg_robot_delegation_chain_audit, ddg_checkout_conformance, or ddg_data_query, and mentions no prerequisites or exclusions. Usage context is only implicit in the name and the listed scope fields.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions the audit scope and a $0.01 cost. It does not state whether this is a read-only audit, what inputs trigger execution, what side effects may occur, or what the response contains.

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

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

The description is a single, dense sentence with the core purpose front-loaded and no filler. The cost disclosure and audit dimensions are packed efficiently into a compact format.

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

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

Despite having an output schema and nested objects, the description is too thin to fully support correct invocation. The required 'spec' parameter is opaque with additionalProperties allowed, and the description does not explain how to construct it or how agent_id affects the audit.

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 0%, so the description must compensate, but it only names audit topics rather than explaining the 'spec' object or the optional agent_id parameter. The listed dimensions hint at what spec might contain, but the agent is left guessing about required structure and values.

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 an audit of human handback/takeover, listing concrete audit dimensions: pause signal, handover latency, operator ack, and resume policy. It is distinguishable from sibling robot audit tools (delegation chain, fleet quota, geo fence), though it lacks an explicit action verb beyond the word 'audit'.

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 for auditing human handback behavior but gives no explicit conditions, prerequisites, or when-not-to-use guidance. It does not differentiate itself from sibling audit tools or explain when an agent should choose this over ddg_robot_delegation_chain_audit or ddg_robot_fleet_quota_audit.

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

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

No annotations are provided, so the description bears full burden. It mentions the need for valid payment headers but does not disclose side effects, error behavior, or reversibility. This is adequate for a straightforward run tool but lacks depth.

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 sentence with no wasted words, front-loading the core purpose and precondition. Efficient for a simple 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?

With 4 parameters (2 required), no parameter descriptions, and only minimal behavioral info, the description is incomplete. Although an output schema exists, the description adds no details about the return value or process.

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 0%, and the description does not explain any parameter (route, prompt, agent_id, payment_headers). It only mentions payment headers indirectly, leaving the agent uninformed about required 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 action ('run') and the resource ('paid model/chat or agent-run route'), and specifies the precondition of valid payment headers. This distinguishes it from sibling tools like ddg_list_models or ddg_request_ollama_model.

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 (when payment headers are available) but does not explicitly contrast with alternatives or state when not to use it. Context signals show no sibling differentiation 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?

No annotations are provided, so the description carries the behavioral burden. It discloses the return shape and workflow: returns best-matching services with service_id, path, price, description, and is meant to be followed by ddg_call. It does not discuss edge cases like empty results or ranking guarantees, but for a low-risk search tool the disclosed behavior is 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?

Three concise sentences with no redundancy. The purpose is front-loaded, followed by the return value and the recommended workflow. Every sentence contributes useful information.

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

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

Given the tool's simplicity and the presence of an output schema, the description covers the essential search, pick, and call flow. It could be more complete by explicitly naming ddg_list_services as the alternative for browsing all services and by explaining top_k, but it is sufficient for an agent to invoke the tool correctly.

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

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

The schema has 0% description coverage, so the description must compensate. It does clarify that "need" is a natural-language query, but it never explains top_k or how it affects results. The parameter name and default value make top_k's likely meaning inferable, but the description itself leaves it unaddressed.

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

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

The description uses a specific verb and resource: "Find DDG agent-callable services matching a natural-language NEED." It clearly distinguishes this search tool from the later invocation step ddg_call and from related sibling tools like ddg_list_services by emphasizing matching rather than listing.

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 gives clear usage context: "This is the entry point to all DDG services — search first, then call." This tells the agent to use it before ddg_call and explains the overall workflow. It does not explicitly mention when to prefer ddg_list_services or other alternatives, so it is not a full 5.

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

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

No annotations are provided, so the description carries full burden. It only states it returns a catalog, with no disclosure of behavioral traits like read-only nature, authentication needs, or rate limits.

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?

A single sentence of 9 words, very concise and front-loaded with the action and resource. No unnecessary words.

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

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

Given no parameters and an output schema that covers return values, the description is minimally complete. It could mention the output type (list) but is sufficient for a simple catalog retrieval.

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 exist, and schema coverage is 100%. The description adds no parameter information, which is acceptable per guidelines for zero-parameter 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 clearly states the verb 'Return' and the specific resource 'DDG's AI-agent cybersecurity service catalog'. It distinguishes from sibling tools like ddg_list_services by specifying 'cybersecurity', though it doesn't explicitly differentiate.

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 guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or context for 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?

With no annotations, the description carries the full behavioral disclosure burden. It adds value by mentioning that the check is 'live', that it costs $0.003, and that it involves a 'real 402' and checks for 'challenge shape' and 'payTo consistency', implying active HTTP interaction with the endpoint. It does not discuss auth, rate limits, or side effects, but the cost and live nature are meaningful disclosures.

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 dense sentences with no filler. The first sentence front-loads the core purpose and cost, and the second enumerates the specific checks. Every phrase contributes 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?

The description covers the core purpose, cost, and check criteria, and the output schema likely explains the returned badge structure. However, it omits semantics for the agent_id parameter, provides no usage guidance or exclusions, and lacks behavioral caveats beyond cost. For a paid live check with no annotations, this is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It indirectly identifies 'url' as the seller endpoint, but it never explicitly names 'url' or 'agent_id', and agent_id is completely unexplained. The check criteria are endpoint behaviors, not parameter meanings, leaving the optional parameter's purpose unclear.

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

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

The description states a specific action ('live conformance check of a seller endpoint'), a clear outcome ('gold/silver/bronze badge'), and enumerates concrete checks ('discovery manifest, real 402, challenge shape, payTo consistency'). This distinguishes it from more generic sibling tools, though it does not explicitly contrast it with similar conformance tools like ddg_checkout_conformance.

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

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

No explicit guidance is provided on when to use this tool versus alternatives. The purpose implies use for evaluating seller endpoint conformance, but it does not mention when not to use it, what prerequisite conditions exist, or how it compares to functionally similar 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?

Without annotations, the description explicitly discloses two key behaviors: the scan never executes submitted code and redacts secret-like evidence. This provides essential safety assurances but omits details like authorization or rate limits.

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 with no redundancy. The behavior is front-loaded and every word contributes to understanding.

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

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

Despite having an output schema, the description does not clarify return values or the format of scan results. With three parameters and no parameter descriptions, the tool is under-specified 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?

With 0% schema description coverage and no parameter explanations in the description, the meanings of 'label', 'agent_id', and 'skill_markdown' are left entirely to the agent. The description adds no value beyond the schema's structural definitions.

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 runs a safety scan on AI skills/workflows, using a specific verb 'Run'. It distinguishes from sibling tools like ddg_mcp_security_profile by being static-only, but could elaborate on the scan's scope.

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

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

The description lacks guidance on when to use this tool versus alternatives like ddg_security_service_catalog or ddg_mcp_security_profile. No mention of prerequisites or conditions under which the scan should be invoked.

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

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

No annotations are provided, so the description must disclose behaviors. It mentions 'operator-reviewed' indicating a manual step, but does not detail what happens after submission (e.g., asynchronous, returns order ID). The presence of an output schema reduces the burden, but more context on the review process would improve 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 a single sentence of 14 words, making it concise. However, it is too sparse given the tool's complexity and the lack of schema descriptions, leaving critical details unaddressed.

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 4 parameters, a nested object, and an output schema, the description is incomplete. It does not explain the 'request' object, how to obtain 'service_id', or the format of 'payment_headers'. The output schema may help, but the description should still provide overall workflow 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 description coverage is 0%, so the description must compensate. It only explains 'payment_headers' (as 'payment headers/proof'), but fails to describe 'request', 'agent_id', and 'service_id'. This is a significant gap for a 4-parameter tool with nested objects.

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 'Submit' and the resource 'paid operator-reviewed DDG order', with a prerequisite condition. This distinctively differentiates it from sibling tools like ddg_order_status or ddg_quote_payment.

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

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

The description implies when to use: after obtaining valid payment headers/proof. However, it does not explicitly state when not to use or list alternatives, but the context is clear.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does add useful concrete traits: output shape (JSON rows or CSV) and a per-call price ($0.003). It omits any behavior around malformed HTML, multiple tables, or failure modes, but for a simple extraction tool the basics are present.

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

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

The description is a single efficient sentence with no filler; the core action is front-loaded. It earns a four rather than five because it is so terse that some needed context is missing, but conciseness itself is handled well.

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 a large sibling set and a closely related ddg_html_to_structured tool, this one-liner does not provide enough context about HTML source requirements, table-selection behavior, or when this tool should be preferred. The output schema exists and reduces the need to explain return values, but the absence of usage and limitation context leaves a clear gap.

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 0%, so the description must explain the parameters. It indirectly documents the output side of the 'format' parameter by mentioning JSON and CSV, but it does not explain the expected 'html' input beyond the obvious, and 'agent_id' is entirely unexplained. This is insufficient compensation for a three-parameter 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 names a specific verb and resource ('Extract HTML tables') and states the output forms (JSON rows or CSV), so an agent can tell what the tool does. It does not distinguish itself from the closely named sibling ddg_html_to_structured, so it misses the top 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?

The phrase 'Extract HTML tables as JSON rows or CSV' implies the main use case: the agent should invoke this when HTML contains tables to be converted. However, it gives no explicit alternatives, exclusions, or conditions, and the sibling ddg_html_to_structured could plausibly overlap in purpose.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It usefully reveals that results are deterministic and that the call costs $0.001, which is meaningful for an agent deciding whether to invoke it. However, it does not disclose side effects, read-only status, failure behavior, or limitations, so transparency is only partial.

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 sentence with no filler. It front-loads the core behavior and includes the key cost signal. Every element contributes useful information, making it highly concise and easy to scan.

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 output schema exists, so return structure does not need to be explained. The description gives a usable purpose and cost context, and the agent can call the tool with just the required text parameter. However, the role of agent_id and how 'per model family' applies to the input are left ambiguous, creating clear 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 description coverage is 0%, and the description provides no explanation of the text or agent_id parameters. It does not say how the text array is handled, what agent_id controls, or how model families are selected. The agent must infer parameter meaning entirely from names and types, which is insufficient for correct invocation.

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 providing deterministic token estimates per model family before a metered call. This is a specific resource and function, though it is phrased as a noun phrase rather than an explicit imperative. It is distinguishable from a generic run-model or cost tool.

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 phrase 'before a metered call' gives a clear context for when the tool should be used: as a pre-call estimation step. It does not name alternatives or exclusions, such as when to use ddg_prompt_cost_budget or ddg_list_models instead, but the timing guidance is explicit and useful.

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?

There are no annotations, so the description carries the behavioral transparency burden. It does add value by disclosing the returned metadata fields and a $0.001 cost, and 'metadata' implies a read-only operation, but it does not mention errors, rate limits, supported networks, or any side effects. For a simple lookup tool this is adequate but not rich.

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 compact phrase with the key output fields and cost front-loaded. It contains no filler or redundant details, making it easy to scan quickly.

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

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

Even though an output schema exists, the three parameters have no schema descriptions and the tool has no annotations, so the description needs to provide more context about chain values, contract format, and when to prefer this over sibling token tools. It is too sparse to be fully actionable in an unfamiliar environment.

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 0%, and the description does not explain any of the three parameters. Contract, chain, and agent_id are left as raw types and defaults, with no guidance on address formats, allowed chain values, or the meaning of agent_id.

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 names the resource (ERC-20 token) and the expected fields (name, symbol, decimals, total supply), so an agent can infer the tool fetches token metadata even without an explicit verb. It is distinct enough from a token estimate or price tool, though it never explicitly contrasts with a sibling.

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 no guidance on when to use this tool versus alternatives like ddg_token_estimate, ddg_crypto_price, or ddg_crypto_portfolio. It does not state when not to use it, what prerequisites exist, or how it differs from similar token-related 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?

With no annotations, the description must convey behavioral traits. It mentions 'smoke test' but does not clarify side effects (e.g., whether a real charge occurs), permissions needed, or idempotency. The agent lacks critical safety 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?

Single sentence, directly states the core function. No unnecessary words. Front-loaded with the key action and 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?

Despite having two parameters and an output schema (unseen), the description provides no information about return values, error cases, or prerequisites. For a tool with zero annotation coverage, the description is too minimal to fully inform the agent.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only mentions 'payment_headers' as 'caller-supplied' but does not explain format or role of 'agent_id'. Agent_id is left completely undocumented, and payment_headers lacks detail on required keys or structure.

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 exercises a specific 'one-cent DDG transaction smoke-test route' with caller-supplied payment headers. This distinguishes it from sibling tools like ddg_submit_order (for actual orders) and ddg_quote_payment (for quotes), making the purpose very clear.

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 guidance on when to use this tool versus alternatives. It does not mention that this is a test route not for production use, nor does it compare with sibling tools like ddg_submit_order. The description assumes implicit 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?

No annotations are present, so the description carries the behavioral burden. It discloses the $0.001 cost and the receipt fields returned, which is useful operational information. However, it does not state read-only behavior, error handling for missing transactions, or any rate limits, leaving a partial gap.

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 very short and front-loads the essential return fields. The telegraphic style with question marks is compact but still informative. It earns its place with the cost disclosure, though a bit more polish around the field names would help.

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 presence of an output schema reduces the need to document return values, and the tool is a simple status lookup. However, with no annotations, no usage guidance, and no parameter semantics in the description, the overall context is only minimally adequate. An agent could likely call it correctly using the schema, but not with full confidence about behavior or alternatives.

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 0%, and the description does not explain the chain, tx_hash, or agent_id parameters. It mentions response fields like block, gas, and cost, which are not inputs. The name and schema provide the only hint that tx_hash is the key input, so the description adds minimal parameter-level value.

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

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

The description clearly identifies the tool as returning a transaction receipt with mined status, success, block, gas, and cost. The verb is implied rather than explicit, but the resource and fields are specific enough to separate it from generic tools. It does not explicitly name a sibling for differentiation, so it falls short of a 5.

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 no guidance on when to use this tool versus alternatives like ddg_tx_smoke_test or ddg_order_status. There is no stated context, prerequisite, or exclusion. The agent must infer usage from the name alone.

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

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

No annotations are provided, so the description must disclose behavior. It mentions the cost ($0.002) and that it's a snapshot, implying a read-only operation, but it doesn't state whether it calls external APIs, what happens with invalid addresses, or any rate limits. It also doesn't describe the response format despite an output schema existing.

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 concise sentence that conveys the core purpose and cost. It is front-loaded with the essential action. It could add a bit more detail on parameters, but the brevity is appropriate.

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 4 parameters but only 1 required, and no annotations, the description is somewhat thin. It explains the main purpose and lists optional tokens, but doesn't cover the 'agent_id' parameter or chain defaults beyond what schema shows. The output schema exists, so return value details aren't required. It is adequate for a simple balance check, but missing some 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 description coverage is 0%, so the description must provide meaning beyond the schema. It explains that 'tokens' allows extra ERC-20s, and mentions 'address' and 'chain' implicitly. However, it does not explain the 'agent_id' parameter, nor does it clarify the format of the 'address' or 'chain' values. The description only partially compensates for the lack of schema 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 states it retrieves native + USDC balance for an address, with optional extra ERC-20s. It specifies a verb (snapshot), resource (wallet balance), and mentions the address parameter. However, it doesn't explicitly distinguish it from the sibling ddg_crypto_portfolio, which might also deal with balances, but the focus on a single address and specific tokens differentiates sufficiently.

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 it is for a single address's balances, and mentions optional extra tokens, which suggests use cases. However, it does not explicitly state when to use this instead of ddg_crypto_portfolio or other balance-related tools. No clear exclusions or alternatives are named.

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

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states that data is returned, without clarifying if the operation is read-only, whether any side effects occur, or what authentication/rate limits apply. For a no-parameter tool, more transparency about the nature of the response (e.g., caching, latency) would be helpful.

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 12-word sentence that front-loads the core action. It is very concise, though it could optionally add a bit more context without losing brevity, such as noting that this is a readiness check.

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 zero parameters and an output schema exists (so return details are covered), the description provides a high-level summary of what is returned (candidate resources, schema metadata, settlement indexing gates). This seems adequate for the agent to understand the tool's purpose, though the exact composition of the output might be better understood from the schema.

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

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

There are zero parameters and 100% schema description coverage, so the baseline is 4. The description does not need to elaborate on parameters since none exist. A score of 4 is appropriate because it adds no confusion but also adds no extra value beyond the schema.

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

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

The description specifies the action ('Return') and the resource ('CDP x402 Bazaar candidate resources, schema metadata, and settlement indexing gates'), distinguishing it conceptually from sibling tools like ddg_x402scan_status (scanning status) and ddg_x402_supported_chains (supported chains). However, the terms 'candidate resources' and 'settlement indexing gates' could be clearer for an agent without domain knowledge.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as mentioning scenarios where readiness information is needed or exclusions. It merely states what the tool returns, leaving the agent to infer 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?

With no annotations, the description must disclose behavioral traits. It states what the tool returns but does not mention side effects, idempotency, authentication requirements, rate limits, or that it is a read-only query. The name implies status, but explicit safety guarantees are missing.

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?

A single sentence of 12 words efficiently conveys the tool's purpose. It is front-loaded with the verb and resource, containing no redundant 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 zero parameters and an existing output schema (not shown), the description adequately lists the three categories of returned data. It could be slightly more descriptive about the nature of 'runtime probe guardrails,' but overall sufficient for a simple status tool.

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

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

The tool has zero parameters and schema coverage is 100% (trivially). The description adds no parameter semantics because there are none to document. Baseline for 0 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 tool returns 'DDG's x402scan registration status, resource URLs, and runtime probe guardrails.' The verb 'Return' identifies it as a retrieval operation, and the specific resource 'x402scan' distinguishes it from sibling tools like ddg_x402_bazaar_readiness.

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 guidance is provided on when to use this tool versus other status-related sibling tools (e.g., ddg_agent_status, ddg_order_status). There is no mention of prerequisites, context, or 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?

No annotations provided, so description must fully convey behavioral traits. It implies a read-only operation but lacks details on idempotency, caching, or rate limits. For a simple list query, minimal disclosure is underwhelming.

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?

A single sentence that is concise, front-loaded, and contains no wasted words. Every part earns its place.

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

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

The tool is low complexity (0 params) and has an output schema, so description need not explain return values. However, it could mention the list contains chain identifiers or names. Still, minimal context is sufficient for a simple query.

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

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

The input schema has zero parameters, so schema coverage is 100%. Description adds no param info but also has no params to document; baseline 4 is appropriate.

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

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

The description clearly states the verb 'Return' and the resource 'all x402/direct-crypto chains DDG supports for AI-agent payment routing', which is specific and distinct from sibling tools like ddg_direct_crypto_addresses or ddg_checkout_conformance.

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 guidance on when to use this versus alternatives (e.g., checking supported chains before querying addresses). With 26 sibling tools, explicit usage context would help but is missing.

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