Do Not Act

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

Annotations provide readOnlyHint=true, etc. Description adds valuable behavioral context beyond annotations: 'Early-warning only', the special treatment of specific alert types, and the negative scope statement. No contradiction.

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

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

Three sentences, no waste. Front-loads purpose, then critical usage guidelines, then negative scope. Each 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?

Simple tool with one parameter and output schema. Description covers purpose, usage, behavioral context, and limitations comprehensively. Fully adequate.

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

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

Schema coverage is 100% for the single parameter 'limit'. The description does not add any additional meaning beyond the schema's description ('Maximum number of recent alerts to read.'). Baseline 3 is appropriate.

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

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

The description clearly states 'Read the DoNotAct alert feed' with a specific verb and resource. It distinguishes from siblings by specifying it is read-only and early-warning, unlike donotact_dispute which likely involves actions.

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

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

Explicitly says 'Early-warning only' and instructs to treat specific alert types as blocking unless overridden. Also states what it does NOT do ('No execution, custody, signing, routing, or advice'), guiding when to use versus 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?

Description adds early-warning limitation and blocking behavior details beyond annotations (readOnlyHint, idempotentHint, etc.). 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?

Three sentences, front-loaded with purpose, no redundant words. Each sentence provides essential 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 two parameters, annotations, and presence of output schema, the description covers key aspects: purpose, usage, caveats. It does not explain return values, but output schema covers that.

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

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

Schema coverage is 100% with clear descriptions. Description adds value for the 'venue' parameter by giving usage examples ('Use polymarket for UMA/Gamma/CLOB evidence or kalshi where supported'). No additional info for 'market_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?

Description clearly states it runs dispute lifecycle diagnostics with early-warning only. It implicitly differentiates from action tools by stating 'No execution, custody, signing, routing, or advice,' but does not explicitly name sibling alternatives.

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

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

Provides clear context on when to use ('where public lifecycle evidence is covered') and when not to (blocking conditions unless overridden). Lacks explicit comparison to siblings but offers actionable guidance.

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

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

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds context beyond annotations: the CSV source ('dispute ledger'), disclaimers about financial claims ('no ROI, alpha, or avoided-loss claim'), and the fail-closed policy. 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 very concise: two sentences plus a brief caution. It front-loads the key action and resource, then provides necessary behavioral context. Every sentence adds value and there is no redundancy.

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

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

Given the presence of a full output schema and 100% parameter descriptions, the description sufficiently covers the tool's purpose, source, disclaimers, and usage constraints. It is complete for the tool's complexity.

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

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

Schema coverage is 100% (both parameters have descriptions). The description does not add additional semantic information about the parameters beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Fetch'), the resource ('paid dispute-history CSV export'), and the scope ('for the authenticated API key'). It distinguishes from sibling tools like 'donotact_dispute' which likely fetches individual dispute details, not CSV export.

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 usage context: 'Diagnostics only' and a critical guideline about the fail-closed behavior ('if the verdict is DO_NOT_ACT or INSUFFICIENT_EVIDENCE, do not proceed'). It does not explicitly contrast with sibling tools but conveys appropriate when-to-use boundaries.

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

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

Annotations already mark readOnlyHint, idempotentHint, and destructiveHint=false. The description adds context beyond annotations by stating it is 'diagnostics only,' 'operational diagnostics, not financial advice,' and lists specific checks (resolver_type, decision, size-vs-book capacity). It reinforces the fail-closed verdict behavior. No contradiction.

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

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

The description is four sentences, front-loaded with the main purpose, and each sentence adds value: defines the tool, instructs on usage, explains fail-closed behavior, and clarifies it is not financial advice. 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 9 parameters (2 required) and an output schema (not shown), the description explains the overall purpose, fail-closed behavior, and the key checks performed. The output schema likely provides detailed return fields, so the description is sufficient for an agent to decide when and how to invoke the tool.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description groups parameters conceptually (e.g., 'requested action context') but does not add substantive per-parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states it is a 'default prediction-market decision-boundary check' and 'diagnostics only,' specifying the verb 'check' and the resource 'decision-boundary.' It distinguishes itself from sibling tools like donotact_alerts (alerts), donotact_dispute (disputes), and donotact_resolution_risk (resolution risk) by its preflight role.

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

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

The description explicitly instructs to 'Pass requested action context' and explains fail-closed behavior: 'if the verdict is DO_NOT_ACT or INSUFFICIENT_EVIDENCE, do not proceed.' It implies use before any action but does not explicitly state when not to use or compare to alternatives, though the tool's distinct purpose is clear given sibling names.

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

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

Annotations already mark the tool as readOnly, idempotent, non-destructive, and open world. The description adds crucial behavioral context: it is diagnostics only, not financial advice, and is fail-closed with specific verdict meanings. It also describes authentication requirements (API key vs. x402 route). This adds value beyond annotations without contradiction.

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

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

The description is 4-5 sentences, each adding distinct value: purpose, authentication, diagnostics disclaimer, fail-closed behavior. It is front-loaded with the core function and avoids fluff. While slightly longer than minimal, the information density justifies its length, earning a 4.

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 and rich annotations, the description covers authentication, fail-closed behavior, and a disclaimer. However, it does not elaborate on the T1-T8 taxonomy or what a typical output looks like (beyond the verdicts mentioned). For a tool that returns risk assessments, an agent might benefit from more guidance on interpreting results. Still, the output schema likely fills this gap, so a 3 is appropriate.

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

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

Schema description coverage is 100%, so the baseline is 3. The main description reiterates the 'preflight' purpose and mentions the T1-T8 taxonomy, adding context that the chain and address parameters are for inspecting token risk within that taxonomy. However, this does not significantly extend the semantic meaning beyond what the schema descriptions already provide (e.g., 'Token contract address to inspect before an agent buys or routes capital'). Hence, score 3.

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

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

The description clearly states the tool runs a token-risk preflight using the GoPlus T1-T8 fail-closed taxonomy. It specifies a specific verb ('Run'), resource ('token-risk preflight'), and methodology ('GoPlus T1-T8 fail-closed taxonomy'). The title and sibling tools list includes 'donotact_preflight' without '_token', implying this is the token-specific variant, which helps distinguish from the generic preflight 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 description provides some usage context: authenticated calls vs. accountless agents, and that this is diagnostics only. It also states the fail-closed behavior and that verdicts of DO_NOT_ACT or INSUFFICIENT_EVIDENCE should block action. However, it does not explicitly compare this tool to siblings like donotact_alerts or donotact_preflight, nor does it state when not to use it (e.g., for contract-level vs. broader risk). Thus, while helpful, it lacks explicit when-to-use vs. alternatives guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description shines by adding the fail-closed context and clarifying it is operational diagnostics, not financial advice. This enriches the agent's understanding beyond the structured 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 three short, focused sentences. Each sentence serves a distinct purpose: stating the action, providing critical behavioral guidance, and clarifying the scope. 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 the presence of an output schema and thorough annotations, the description covers the essential context: what the tool does, its operational nature, and how to interpret its output (fail-closed). Minor gap: it doesn't explicitly state that it checks resolution risk before an agent acts, but this is implied.

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

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

Schema coverage is 100%, and the schema descriptions for venue and market_id are already clear. The main description does not add new parameter-level details beyond the schema, achieving the baseline expectation.

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 resolution-governance and ambiguity diagnostics for a venue market. It uses specific verbs ('Run') and resources ('diagnostics'), and the phrase 'Diagnostics only' distinguishes it from action-oriented siblings like donotact_dispute or donotact_alerts.

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 guidance by explaining the DoNotAct fail-closed behavior ('if the verdict is DO_NOT_ACT or INSUFFICIENT_EVIDENCE, do not proceed'), implying when to use the tool (before taking action based on resolution). However, it does not explicitly compare to sibling tools or state when not to use it.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds valuable context about blocking behavior and human override requirements, enhancing transparency beyond structured fields.

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?

Very concise at three sentences. The first sentence immediately states the main action. No unnecessary words; every sentence contributes meaningful 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?

With output schema present and good annotations, the description is complete. It covers purpose, behavioral notes, and usage constraints, leaving no critical gaps for an agent.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond what the schema already provides for the parameters (e.g., email, venue, market_id, webhook_url).

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 'Add or update' and the resource 'DoNotAct early-warning watchlist item'. It distinguishes from siblings by specifying it is 'early-warning only' and listing exclusions like 'No execution, custody, signing, routing, or advice'.

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 provides clear context on when to use (early-warning) and when to treat as blocking unless human override. However, it does not explicitly name alternative sibling tools for comparison, missing a direct when-not-to-use reference.

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