DDG Agent Services

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?

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?

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?

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?

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?

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?

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

No annotations are provided, so the description carries full burden. It discloses that the tool does not execute backend compute, which indicates it is non-destructive but lacks details on authentication requirements, rate limits, or consequences of misuse.

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 15 words, making it concise and front-loaded. It earns its place by providing essential purpose information, though it could add parameter context without significant bloat.

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 2 optional parameters and an output schema. The description adequately conveys the core action but omits context about the output schema or how the payment challenge is used. It is minimally viable but could be more 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%, but the description does not explain the parameters (path and agent_id). With 0% coverage, the description should compensate by describing parameter roles, but it does not, leaving the agent with only schema defaults.

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 payment challenge without executing backend compute, specifying the verb 'return' and resource 'payment challenge'. It distinguishes from sibling tools that execute actions (e.g., ddg_submit_order), but could be clearer about what a 'payment challenge' entails.

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 like ddg_submit_order or ddg_run_paid_model. The description implies it's for quoting without execution, but does not explicitly state use cases, when-not-to, 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?

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?

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?

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

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