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

No annotations are provided, so the description must disclose behavioral traits. It discloses the $0.05 fee on Base mainnet, a key side effect, and indicates the tool calculates and flags. However, it doesn't mention whether any state changes occur, permissions required, or error behavior.

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

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

Single sentence that front-loads the main action and cost. 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?

With no output schema and no annotations, the description leaves unclear the exact return format (per-call array? single flag?). It covers cost and purpose but lacks detail on output structure and edge cases.

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

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

Schema description coverage is 0%, and the description only hints at 'per call' and 'budget overrun' without explaining the required fields like input_tokens or input_usd_per_million. It introduces concepts like cached-token costs that aren't directly present in the schema, which could confuse.

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 'Calculate' to specify the action and identifies the resources: model, cached-token, and external-tool costs per call, plus budget overrun flagging. This clearly differentiates it from the sibling preflight 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?

It provides clear context for when to use the tool (cost analysis per call, budget monitoring) but does not name alternatives or exclusions. Since none of the sibling tools overlap in purpose, this is acceptable.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a key side effect: 'Costs $0.25 USDC on Base mainnet.' However, it does not mention whether the audit changes any state, what output to expect, or any other side effects, leaving significant behavioral gaps.

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

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

The description is two sentences with no filler. The first sentence front-loads the verb ('Audit') and resource scope, followed by a concise list of audit areas. The second sentence adds only the essential cost constraint. 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's complexity (6 parameters, nested objects, no output schema), the description is not sufficiently complete. It provides a high-level purpose and cost but omits parameter details, output format, and expected behavior, making it insufficient for an agent to confidently invoke the tool without further guidance.

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. The audit dimensions ('required discovery surfaces', 'supported claims', 'channel-specific launch constraints') map loosely to the surfaces, claims, and target_channels parameters, but the description does not explain the structure or required fields of the nested objects, leaving the agent to infer parameter semantics from names alone.

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

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

The description clearly identifies the tool as an audit of agents, skills, MCP servers, or paid APIs, specifying the audit dimensions (release consistency, discovery surfaces, evidence freshness, claims, and channel constraints). This is a specific verb+resource description, but it does not explicitly differentiate from sibling tools like justhandled_channel_fit_evidence_matrix or justhandled_agent_run_evidence_pack.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it state prerequisites or exclusions. It only describes what the tool does and mentions a cost, but no when-to-use or when-not-to-use 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 provided, the description carries the full burden. It discloses a critical behavioral trait: 'Costs $0.25 USDC on Base mainnet', which is not inferable from the schema or name. It does not mention side effects, auth, or failure modes, but as an audit tool, this is key context. This disclosure elevates it above baseline.

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

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

The description is two sentences: the first clearly states the function, the second states the cost. Every word earns its place, with no redundancy or filler. It is front-loaded with the core purpose and keeps the cost note separate and concise.

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

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

Given the complexity (6 nested objects, no annotations, no output schema), the description is noticeably incomplete. It explains what inputs are audited but does not describe the report output itself, what a passing/failing result looks like, or any response format. The user is left without crucial information about the tool's return value, making it hard to know what to expect or how to act on the result.

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 lists all six dimensions that map directly to the required parameter names (promise_action, tool_calls, completion, tool_descriptions, skill_activation, costs), adding high-level semantics. However, it does not explain the nested structure or required sub-fields (e.g., 'outcomes' in completion, 'contracts' in tool_calls), so it only partially fills the gap.

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

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

The description uses a specific verb ('Audit') and identifies the resource ('one agent-run packet') along with the exact scope ('promises, tool calls, completion evidence, tool descriptions, skill activation, and cost'). This clearly distinguishes it from sibling tools that each handle a single aspect, as it presents a consolidated audit.

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

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

The description says 'consolidated report', which implies it is the comprehensive tool for auditing an entire agent-run packet, covering all the dimensions that sibling tools handle individually. However, it does not explicitly state when to use this versus the individual checkers or any exclusions, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses the cost ($0.05 USDC) but does not state whether the operation is read-only, if there are side effects, or what the output format is. For an audit tool, it likely doesn't mutate data, but this is not stated.

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

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

The description is two short sentences: the first states the purpose, the second states the cost. No redundant information, no filler. It is front-loaded and efficient.

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

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

The tool has moderate complexity (arrays, matching logic, no output schema), but the description only covers purpose and cost. It omits what the tool returns, how results are presented, error conditions, and any usage examples. This is a substantial gap for an auditor 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 0%, so the description must compensate. It implies that 'contracts' contain expected status, content-type, field, type, and stable-value rules, and that 'responses' are recorded API responses. However, it doesn't explain the id linking scheme, required fields, or additionalProperties, leaving gaps.

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 function with a specific verb 'Compare' and resource 'recorded API responses' against 'explicit status, content-type, field, type, and stable-value contracts'. It names the key contract dimensions, which differentiates it from sibling audit tools, though it doesn't explicitly name 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?

There is no guidance on when to use this tool versus alternatives. It notes a cost but no prerequisites, constraints, or exclusions. The description does not mention any specific use case or conditions under which this tool is preferred over sibling auditors.

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 behavioral traits. It does disclose the cost ($0.05 USDC on Base mainnet) and the specific hazards checked, which adds useful context. However, it does not explicitly state whether the tool is read-only, what side effects (if any) occur, or what the response looks like. The word 'Check' implies analysis, but the monetary cost introduces operational ambiguity that is not resolved.

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

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

The description is two sentences with no fluff. The first sentence states the purpose, and the second adds a critical operational cost detail. Every word earns its place, making it highly efficient.

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

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

The tool has no output schema and no annotations, so the description must fill in gaps. It covers the purpose and cost, but it does not describe the return value (e.g., a report, list of hazards, boolean), nor does it clarify prerequisites or whether a blockchain transaction is required. For a paid tool with these gaps, the description is adequate but incomplete.

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 adds meaningful context by stating the events are 'normalized iCalendar events,' which clarifies the expected data structure beyond the raw schema's field list. It also names the hazard categories, indirectly linking them to the timestamp fields. This helps compensate for the low coverage, though it does not explain the exact format or semantics of dtstart/dtend as thoroughly as a full parameter doc would.

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

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

The description clearly states the tool's purpose: 'Check normalized iCalendar events for floating time, boundary, DATE, sequence, and recurrence hazards.' This specifies a verb (check), a resource (normalized iCalendar events), and a detailed scope. It also distinguishes itself from sibling preflight tools, which cover other domains (e.g., gitignore, Shopify CSV, subtitle timelines).

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 when one has normalized iCalendar events to examine for timezone hazards, but it does not explicitly state when to use this tool versus alternatives. No exclusions or sibling comparisons are mentioned. There is clear context but no explicit 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 present, so the description must disclose behavior; it mentions the cost and network but not whether the tool writes a record, mutates state, or what side effects occur. The absence of read/write clarity and failure behavior is significant for a paid on-chain-capable 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?

Two sentences with no filler; the core comparison and cost are stated up front.

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 complex with multiple nested objects, 7 required parameters, no output schema, and no annotations. The description gives the conceptual scope and the fee, but omits how to structure the experiment object, what 'contamination' means operationally, and what the tool returns or persists.

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

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

The schema has no descriptions, and the tool description provides conceptual vocabulary (contamination, budgets, changed variables, cooldowns) that maps to nested fields, but it does not explain individual parameters like observed_at, attribution_complete, or owner_activity_excluded. It partially compensates for 0% schema coverage.

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

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

The description names a specific verb ('Compare') and a clear resource (predeclared channel hypothesis and qualified outcome gate) plus the dimensions considered. It is clear on its own, though it doesn't explicitly contrast with sibling tools.

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

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

No guidance about when to use this vs. sibling evidence/preflight tools. The only operational note is the $0.25 USDC cost; there are no exclusions, prerequisites, or alternative recommendations.

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 responsibility for disclosing side effects and operational behavior. It does mention the $0.25 USDC cost on Base mainnet, which is useful, but it fails to state whether the tool is read-only, what it returns, whether it persists data, or what happens on failure. This is insufficient for a tool with financial cost.

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 that begins with the verb and resource, lists the key dimensions, and ends with the cost. It contains no filler or repetition, and every element adds necessary 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 highly complex nested schema, no output schema, and no annotations, this description is incomplete. It explains the ranking purpose and cost but omits how to assemble the evidence and constraints inputs, what the output looks like, and any operational requirements. For a tool with 100-item and 500-item arrays, more contextual guidance is 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?

Schema description coverage is 0%, so the description must compensate for the complex 5-parameter input. The long list of ranking criteria maps to nested channel fields (audience_match, buyer_intent, etc.) and adds some meaning, but it does not explain the required top-level parameters like observed_at, objective, constraints, evidence, or channels. The description only partially clarifies the input 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?

The description starts with the specific verb 'Rank' and clearly identifies the resource as 'evidence-backed distribution tests' with a detailed list of ranking criteria. This makes its purpose distinct from sibling tools like proof_to_channel_evidence_packet or qualified_demand_ledger, which focus on evidence construction or ledgering rather than comparative ranking.

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 offers no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Usage is only implied by the action word 'Rank', so an agent must infer the appropriate context without support.

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

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

No annotations are provided, so the description must carry the transparency burden. It discloses the cost ($0.25 USDC on Base mainnet) and the baseline comparison behavior, but it does not detail output format, possible errors, or whether the operation is read-only beyond the verb 'Query'. This is useful but incomplete for a tool with no annotation support.

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

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

The description is two sentences long, front-loaded with the core purpose, and adds the critical cost detail without unnecessary filler. 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?

This is a complex tool with 8 parameters, nested objects, and no output schema. The description is too brief to cover important aspects like the records parameter for deterministic testing, the meaning of previous_snapshot, or what a 'change packet' includes. It provides a high-level overview but omits essential context needed to invoke the tool correctly in various scenarios.

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 only 13%, so the description should compensate for the undocumented parameters. It does explain the query field enum values (vendor, department, contract, specification, keyword), but it says nothing about the other seven parameters, such as max_results, records, previous_snapshot, truncated, or source_updated_at. The description only partially covers the parameter space.

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 ('Query') and the resource ('live City of Chicago contracts dataset'), and specifies the available query fields (vendor, department, contract, specification, or description). The mention of comparing against a retained public-data baseline further distinguishes this tool from sibling change-packet tools.

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

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

The description implies usage for querying Chicago contract data and comparing against a baseline, but it does not explicitly state when to prefer this tool over alternatives or mention excluded scenarios. Sibling names suggest similar change-packet tools, but no direct comparison or when-not-to-use guidance is provided.

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

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

With no annotations, the description carries the full burden. It discloses the cost and 'bounded' nature, implying a read-only query, but does not mention authentication, rate limits, or failure/refund behavior. It adds some context but leaves important behavioral aspects unstated.

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 the core action and cost. No redundant words or filler; every word adds value.

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

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

For a tool with no output schema and nested parameters, the description is too minimal. It does not describe the return format (e.g., a list of changes) or explain 'records_generated_at'. While the cost and comparison intent are helpful, the description fails to provide enough context 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 50%, leaving 'previous' and 'records_generated_at' undocumented. The description's 'optional prior snapshot' clarifies 'previous', but 'records_generated_at' remains unexplained. The 'records' param is covered by the schema, so the description only partially compensates for the gap.

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

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

The description clearly states the tool queries a Chicago demolition-permit adapter and compares current matches with an optional prior snapshot. This specific verb-resource pairing distinguishes it from sibling tools like justhandled_chicago_contract_change_packet by narrowing to demolition permits.

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 clear context by mentioning the optional prior snapshot for comparison and the $0.25 cost, but it does not explicitly state when to use this over other change-packet tools or any exclusions. No direct alternatives are cited, but the purpose is enough to infer 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?

No annotations are provided, so the description carries the full burden. It discloses the $0.25 USDC cost and the general scope, but lacks necessary behavioral detail such as whether the tool performs a read-only check, what the return value is, whether it triggers a blockchain transaction, or if any external calls are made.

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

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

The description is two sentences with front-loaded purpose and cost. Every word earns its place; there is no redundancy or filler.

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

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

This is a complex tool with a large nested schema and no output schema, but the description does not explain what the tool returns, how the payment is submitted, or what the caller should do with the result. Significant context is missing for the agent to invoke it correctly.

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

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

Schema description coverage is 0%, and the description does not explain the meaning of the five parameters or any nested fields. It only loosely maps elements like 'Reddit, Hacker News, Show HN, Product Hunt' to the channel enum and 'community rules' to the community object, which is far too little to compensate for the complete absence of schema descriptions.

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

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

The description uses the verb 'Check' with a clear object: 'a proposed Reddit, Hacker News, Show HN, or Product Hunt action' and explicitly lists the criteria: official guidance, supplied community rules, account credibility evidence, and promotion boundaries. This is specific and distinct from sibling tools, which focus on different preflight topics (e.g., CSV schema, gitignore, redirect maps).

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

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

The description implies usage for checking a proposed action before it is taken, but does not explicitly state when to use it versus alternative tools. No exclusions or alternative tool names are mentioned, so the guidance is only implicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses the cost ($0.05 USDC on Base mainnet) but does not state whether the operation is read-only, whether authentication is needed, what the return value looks like, or any side effects. This is a significant gap.

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

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

The description is two short, efficient sentences. The first delivers the purpose, the second adds cost information. No redundant or filler language.

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

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

With no output schema or annotations, the description should ideally explain what the tool returns or any prerequisites. It omits return behavior (e.g., a report or pass/fail) but the tool's simplicity and clear purpose make it minimally viable.

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

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

The schema has 0% description coverage for the 'outcomes' parameter. The description adds context by mentioning the statuses (completion, partial, blocked) and the fields to check (evidence, remaining-work), which helps interpret the parameter. However, it does not fully explain the validation logic or exact expected structure beyond what the schema already provides.

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 a specific verb ('check') and resource ('completion, partial, and blocked outcome records'), and specifies what is checked (evidence and remaining-work details). This distinguishes it from sibling tools that check other types of data.

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

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

The description implies usage for verifying outcome records based on status, but it does not explicitly mention when not to use the tool or provide alternatives among siblings. This is acceptable but not explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a key cost behavior: '$0.05 USDC on Base mainnet,' which is valuable. However, it does not state whether the operation is read-only, how it handles normalization, or what side effects (if any) exist beyond the cost. This leaves 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?

The description is a single, front-loaded sentence that immediately states the action and scope, then lists comparison dimensions and cost. Every word earns its place; there is no redundancy or filler.

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

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

The tool has no output schema and no annotations, so the description should explain what the result looks like, how matching works, and any prerequisites. It only mentions cost and comparison aspects. It omits crucial context like return format, column matching logic, or error conditions, making it insufficient for an agent to fully anticipate tool behavior.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter explanations. The description only says 'Compare normalized CSV column contracts' and does not mention the parameters 'baseline_columns' or 'current_columns' nor their structure (name, type, required). The parameter names are self-explanatory, but the description adds no semantic detail about how the inputs are used or formatted.

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

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

The description opens with a precise verb and resource: 'Compare normalized CSV column contracts for removals, additions, type drift, and newly required fields.' This clearly states the tool's function and distinguishes it from sibling preflight tools (e.g., shopify_product_csv_preflight, api_response_contract_drift_auditor) by focusing on CSV column schema comparison.

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: use when you need to compare CSV column schemas for drift. It names the specific aspects (removals, additions, type drift, newly required fields) but does not explicitly state when to use this tool over alternatives or mention any exclusions or prerequisites. Usage context is inferred rather than clearly stated.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the cost ($0.05 USDC on Base mainnet) and the nature of the check (looking for missing/conflicting/invalid/monitor-only policies), but does not provide details on side effects, permissions, or return 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 that leads with the action verb and packs specific detail into a compact format. No redundant information is present.

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 a nested object schema and no output schema, yet the description does not cover return values, error conditions, or interpretation of results. It also omits guidance on what constitutes 'monitor-only' or 'normalized', leaving significant 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?

The description does not explain the domain, observed_at, or records parameters beyond naming the record types. Schema coverage is 0%, so the description should compensate but does not provide format, meaning, or constraints for the 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 uses a specific verb 'Check' and identifies the exact resource ('normalized SPF, DKIM, DMARC, and MX evidence') and the specific issues being checked (missing, conflicting, invalid, or monitor-only). This clearly distinguishes the tool's purpose from sibling tools, which are mostly unrelated domains.

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

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

The description implies the tool is for analyzing email DNS authentication evidence but does not explicitly state when to use it versus alternatives. No exclusion criteria or alternative tool references are provided, leaving usage guidance implicit.

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

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

With no annotations provided, the description must carry behavioral disclosure. It discloses that the tool incurs a cost of $0.05 USDC on Base mainnet, which is a meaningful behavioral trait. However, it does not state whether the operation is read-only, what the return format is, or any error/side-effect behavior. The cost disclosure is helpful but partial.

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

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

The description is two sentences, front-loaded with the core functionality and followed by cost information. Every word earns its place, with no redundancy or filler.

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

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

There is no output schema and no description of return values. While the function likely returns a list of flags, the description does not specify this. It also does not mention any prerequisites, required context, or behavior for edge cases like empty paths. The cost detail is useful, but the lack of output semantics and parameter details leaves the description incomplete 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 0%, and the description adds no information about the parameters. It does not explain how 'paths' is used or the role of 'max_path_length'. The parameter names are self-explanatory to a human, but the description fails to compensate for the lack of schema descriptions, leaving the agent with no added semantic context.

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

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

The description uses the specific verb 'Flag' and clearly names the resource (filename portability). It enumerates the exact categories of issues it detects (reserved names, invalid characters, trailing dots, case collisions, Unicode collisions, long paths), which goes beyond a generic purpose and distinguishes it from the other preflight tools in the sibling list.

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

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

The description implies use when needing to check filenames for portability issues but gives no explicit when-to-use vs alternatives. It does not name any sibling tools or state exclusions. The clear list of checks provides context but no direct guidance on selecting this tool over others.

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 cost ($0.05 USDC on Base mainnet) and describes the operation as a check, but does not explicitly state side effects, read-only nature, or any data-handling implications. The cost disclosure is valuable, but other behavioral aspects remain opaque.

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

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

The description is two short sentences, front-loaded with the core purpose and followed by the cost. Every word earns its place, with no redundancy or filler.

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

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

Despite being a relatively simple tool, the description omits key contextual details such as the output format (no output schema exists), the meaning of 'tracked_paths', and any usage prerequisites. The cost is useful, but overall the description leaves important gaps for an agent to invoke and interpret results correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'paths' and 'ignore patterns' (mapping to 'paths' and 'patterns'), but does not clarify the 'tracked_paths' parameter at all. It also lacks format or syntax details, leaving the third parameter entirely ambiguous.

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 a specific action ('Check supplied paths and ignore patterns for uncovered or tracked sensitive-looking files'), identifying both the resource (paths and ignore patterns) and the goal. This distinctly separates it from sibling preflight checkers by focusing on gitignore coverage and sensitive files.

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 when needing to audit ignore coverage for sensitive files, but offers no explicit guidance on when to use this tool versus alternatives. No conditions or exclusions are stated, and sibling tools are not referenced, so the context is clear but not fully elaborated.

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 disclosure burden. It transparently mentions the $0.05 USDC cost on Base mainnet and indicates that the tool flags categories rather than performing mutations. However, it does not discuss auth, rate limits, or failure 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 two succinct sentences: the first states the core functionality, and the second provides the cost. It is front-loaded and contains no unnecessary wording.

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 a simple checker, but with no output schema and no annotations, the description should clarify the return value and edge cases. It lists the flag categories but does not explain what 'colliding' means or describe the output structure. The cost disclosure is useful but not sufficient to make the description fully 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%, and the description only indirectly maps 'image paths' to the 'files' parameter and 'SKU roster' to the 'roster' parameter. The optional 'sku_pattern' parameter is completely unexplained, and no deeper parameter semantics are added beyond the property names.

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 ('Match') and clearly identifies the resource (image paths and SKU roster) and the action (flag missing, extra, unknown, or colliding assets). This distinguishes the tool from sibling checker tools, which focus on different domains.

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

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

The description implies the tool is used when you have image paths and a SKU roster to compare, but it never explicitly states when to choose this tool over alternatives or when not to use it. No exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only (reasonable to assume for a listing tool but not guaranteed), what the response format is, whether results are paginated, or if there are any side effects. The description simply says 'List...' without elaborating on behavior, leaving the agent with incomplete information about how the tool operates.

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 front-loads the action ('List') and clearly enumerates the categories. There is no unnecessary verbiage or repetition. Every word contributes to the meaning.

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

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

For a simple 0-parameter listing tool without an output schema, the description is minimally adequate: it conveys what categories are included. However, it lacks context about the purpose of the listing (e.g., overview, inventory, sanity check) and the return format. Given the absence of annotations and output schema, the description could be more helpful by indicating the kind of output (e.g., names, summaries) or when to prefer this over a sibling tool. This is a clear gap, though not severe for such a low-complexity 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, so the schema is fully covered (100%) and there is no additional parameter meaning to convey. Per the baseline rule for 0-parameter tools, the description need not add parameter details, and it does not. The description does not introduce any parameter-related ambiguity.

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 enumerates the specific types of items (preflights, maintained-data lookups, evidence products, prices, limitations). It distinguishes from the sibling tools, which are specialized checkers/verifiers, by indicating a general listing utility. However, the exact semantics of 'maintained-data lookups' and 'evidence products' are somewhat jargon-heavy, and the description could be more explicit about the output format or purpose.

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

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

The description provides no guidance on when to use this tool versus the many sibling tools. It does not mention any context, prerequisites, or alternatives. The name suggests it is a general listing tool, but without explicit statements about when it is appropriate, an agent would have to infer usage from the name alone.

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

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

With no annotations provided, the description carries the full burden. It adds useful behavioral context by disclosing the $0.05 cost and the specific checks performed. However, it does not explicitly state whether the operation is read-only, whether data is sent externally, or what the nature of 'baseline drift' comparison entails.

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 followed by cost. Every word earns its place and is concise.

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 moderate complexity with 3 parameters (one nested object) and no output schema. The description covers the core check and cost, but omits details about return values, interpretation of results, and more thorough input guidance. It is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It gives context that 'package' is an npm manifest and hints at 'baseline drift' relating to previous_files, but does not explain the structure of the package object, the format of pack_files, or explicitly map 'previous_files' to baseline drift. Insufficient for an agent to correctly construct all 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 uses a specific verb 'Check' with a clear resource ('npm pack manifest') and lists specific checks (missing entrypoints, absent runtime output, sensitive files, baseline drift). This clearly distinguishes it from sibling preflight tools, which target other domains.

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

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

The description clearly indicates the tool is for npm package preflight checks, and the sibling tools are all distinct domains, so context is clear. However, it does not explicitly state when to use vs alternatives or when not to use it.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure, but it only reveals the cost and that the input is normalized marketing-message evidence. It does not state whether the operation is read-only, what it returns, how errors are handled, or any side effects. The cost disclosure is useful, but the lack of safety/mutation details is a significant gap for a tool with zero annotation coverage.

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

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

The description is concise, consisting of two short sentences with no redundant or vague wording. It efficiently communicates the core purpose and a critical constraint (cost) in a front-loaded manner.

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 (one parameter, no output schema), the description is incomplete. It does not explain what the output looks like, how to interpret results, what constitutes valid List-Unsubscribe/RFC 8058 headers, or whether there are any prerequisites like specific message formats. The cost and input normalization are mentioned, but many essential behavioral aspects are 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?

The input schema has zero description coverage, so the description is needed to explain parameter semantics. It mentions 'normalized marketing-message evidence' and the folder headers, but it does not clarify the structure of the 'messages' array, the meaning of 'id', 'message_type', or how 'headers' should be formatted. This is insufficient compensation for the schema's lack of descriptions.

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

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

The description clearly states the tool's function: checking normalized marketing-message evidence for List-Unsubscribe and RFC 8058 one-click headers. The verb 'Check' is specific and the resource (headers) is well-defined, distinguishing it from sibling checkers like image_to_sku_match_checker or UTM link consistency checker. However, it does not specify what 'check' entails (e.g., presence, format validation), so it stops short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. While the name implies a use case, there is no explicit context or references to sibling tools, leaving the agent to infer when to invoke this checker among many similar 'justhandled_' tools.

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

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

No annotations exist, so the description must disclose behavioral traits, but it only mentions a $0.05 USDC cost on Base mainnet and vague 'version and effective-date guardrails'. It does not clarify whether the operation is read-only, whether it performs blockchain writes, or what side effects or safety measures apply beyond cost.

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

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

The description is two tight sentences with no filler. The primary purpose is front-loaded, and the cost information is a concise, useful addition. 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?

The description clearly states the core purpose and cost, but it omits critical invocation details: no explanation of the required 'policies' parameter structure, no return value specification (no output schema), and no disclosure of side effects beyond the cost. An agent cannot confidently invoke the tool correctly based on this description alone.

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 mention or explain the 'policies' parameter at all. It gives no meaning to 'id', 'baseline', 'current', or the expected array structure, so an agent has no guidance for constructing valid input.

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 the specific verb 'Produce' and clearly defines the resource as 'clause-level evidence for policy additions, removals, text, applicability, and requirement changes'. This is specific and distinguishes it from sibling evidence/audit tools that focus on other domains like promise actions or completion receipts.

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 used for generating policy change evidence but does not explicitly state when to use it versus alternatives. No exclusions or comparative guidance is given for the many sibling tools, leaving the agent to infer the appropriate context from the tool's name and purpose.

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

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

No annotations are provided, so the description carries the full burden. It adds the cost ($0.05 USDC) and implies a non-mutating analysis behavior through 'Compare' and 'flagging', but does not disclose return format, side effects, authentication needs, or whether any write operations occur.

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

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

The description is two sentences, front-loaded with the main action, and includes the cost as a separate sentence. No fluff or 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?

The tool has 3 complex array parameters, no annotations, and no output schema. The description lacks return value details, usage context, and parameter relationship explanations. It does not mention the maxItems constraints or what a 'flagged' result looks like, making it incomplete for a tool of this 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?

The schema has 0% description coverage, so the description must compensate. It explains that 'promises', 'actions', and 'evidence' are the subjects of comparison, providing high-level meaning. However, it does not explain the relationships between parameters (e.g., how actions reference promise_ids) or the meaning of specific fields like 'status'.

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 function with specific verbs ('Compare', 'flagging') and resources ('declared promises', 'recorded actions', 'evidence'). It distinguishes itself from sibling tools by focusing on the promise-action-evidence triad and unsupported completions.

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. It does not mention any exclusions, prerequisites, or scenarios where another tool would be more appropriate, despite the presence of many sibling checkers.

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

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

No annotations are provided, so the description must carry the full behavioral disclosure burden. The only behavioral trait disclosed is the $0.25 USDC cost on Base mainnet. It does not explain whether the operation writes to chain, what the output packet contains, what happens on failure, or any authorization requirements.

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

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

The description is two sentences, front-loaded with purpose and ending with a key cost qualifier. Every sentence contributes useful information without fluff or repetition.

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

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

The tool has a complex 8-parameter nested schema and no output schema, yet the description is minimal. It lacks expected return value/output format, usage examples, and sibling differentiation. The cost disclosure is helpful but insufficient for an agent to confidently invoke this complex 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 0%, so the description must compensate. It does map several key concepts (claims, observed proof, channel rules, required artifacts, link treatment, attribution, pricing disclosure, human-authored identity fields) to the input groups, adding meaningful context. However, it omits explanation for parameters like observed_at and max_evidence_age_days and leaves structural details to the schema.

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

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

The description states a specific action: 'Map product claims and observed proof to current channel rules, required artifacts, link treatment, attribution, pricing disclosure, and human-authored identity fields.' This clearly distinguishes it from sibling tools by focusing on product-claim-to-channel evidence. The verb 'Map' is somewhat abstract, but the resource and purpose are evident.

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 a use case—mapping claims and evidence against channel rules—but provides no explicit when-to-use guidance, prerequisites, or exclusions. It does not mention alternatives among sibling tools. The cost note is contextual but not actionable usage guidance.

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

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

With no annotations and no output schema, the description carries the full burden. It discloses a meaningful side effect ('Costs $0.25 USDC on Base mainnet') and communicates a behavioral guardrail ('without inflating vanity activity'). However, it does not disclose whether the tool persists data, returns classifications, or requires authentication.

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

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

The description is two sentences and front-loads the core purpose before the cost note. There is no filler or repetition; every clause adds 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?

Despite a complex nested schema and no output schema, the description does not explain return values, persistence behavior, or event classification semantics beyond the category names. The cost and anti-vanity guardrail are useful, but the tool's overall operational context is under-specified.

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% and the description provides no information about the three top-level parameters (observed_at, window, events) or the nested event fields. The schema's enums and required fields are left entirely for the agent to infer.

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 the specific verb 'Classify' and identifies the resource as 'normalized commercial events,' listing the target categories (exposure, operations, candidate signals, etc.). This clearly distinguishes it from the sibling preflight/audit tools, which focus on validation checks rather than event classification.

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

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

There is no explicit guidance about when to use this tool versus alternatives, nor any exclusions or prerequisites. The category list implies it is for classifying commercial events, but the description does not state a preferred use case or reference sibling tools.

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

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

With no annotations, the description carries the full burden. It discloses an important behavioral trait: the cost of $0.05 USDC on Base mainnet, which is not obvious from the schema. It also lists the validation categories. However, it does not disclose whether the tool is read-only, what side effects it may have, or what the output looks like. The cost disclosure adds value, but the lack of other behavioral details leaves gaps.

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

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

The description is a single sentence that front-loads the primary purpose and includes the cost note. Every word earns its place: the verb, the resource, the key checks, and the cost. There is no fluff or repetition of schema information. This is an ideal length for a tool description.

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 the clear purpose, the description is incomplete for a tool with no output schema and no annotations. It does not explain what the tool returns (e.g., pass/fail, list of errors), how parameters are used (especially baseline_sources), or any prerequisites (like network access or wallet funding). The cost and check list are useful, but without parameter guidance and return format, the agent may struggle to invoke it correctly or interpret results.

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 provides no explanation of the 'redirects' array or 'baseline_sources' parameter beyond a vague hint in 'missing legacy sources.' This does not clarify the structure, format, or meaning of the parameters. Users would have to infer that 'redirects' contains objects with source/destination (from schema names) and that 'baseline_sources' might be a list of expected sources, but this is not stated.

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

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

The description uses a specific verb ('Check') and clearly specifies the resource ('redirect map') and the exact checks performed (invalid targets, self-redirects, chains, loops, missing legacy sources). This distinguishes it from sibling preflight tools by naming the target domain and the concrete validation 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 implies usage: you use this tool when you need to validate a redirect map. However, it does not explicitly state when to use it vs. alternatives, nor does it mention exclusions or prerequisites. The 'preflight' suffix and the list of checks provide implied context, but there is no direct guidance on alternatives or non-use cases.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals an important trait: the operation costs $0.05 USDC on Base mainnet. It does not state whether the tool is read-only or describe return values or error behaviors, but 'validate' implies non-mutating. The cost disclosure is a positive, yet more behavioral context is needed.

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 is front-loaded with the primary action and resource, followed by a concise list of validation dimensions and a cost note. There is no redundant or filler content; every clause adds value.

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

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

The tool has nested objects and no output schema. The description covers the main input scope and validation rules, but it omits details about expected return values, failure conditions, or how to structure the 'policy' object precisely. For a validation tool with a rich schema, this is adequate but not fully complete.

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

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

The schema has 2 parameters with 0% description coverage. The description mentions validation categories (paths, prefixes, hashes, size limits, sensitive-file rules) that roughly map to the schema's 'files' and 'policy' properties, adding some meaning beyond raw fields. However, it does not explicitly name the parameters or provide syntax details, so it only partially compensates for the lack of schema coverage.

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

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

The description clearly states the tool's function: 'Validate a release file manifest against required paths, allowed prefixes, hashes, size limits, and sensitive-file rules.' The verb 'validate' and the specific resource 'release file manifest' make the purpose unambiguous, and it is distinct from sibling tools that focus on other domains like gitignore or subtitle timelines.

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: it is for validating a release file manifest. However, it does not explicitly state when not to use it or name alternative tools. The context is clear enough for an agent to recognize the tool's domain, but no exclusions or alternatives are provided.

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

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

With no annotations, the description carries the full burden. It discloses a significant behavioral trait (costs $0.05 USDC on Base mainnet) and the nature of the check, but does not state whether the operation is read-only, what the return format looks like, or any potential side effects beyond the cost.

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, well-structured sentence that leads with the action and key checks, then adds the cost detail. Every word adds value, with no redundancy or filler.

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

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

Given the tool's moderate complexity (4 parameters, no output schema), the description covers the core checks and cost but omits critical context: what the tool returns, how to interpret results, and the role of parameters like mode and existing_handles. It is enough for basic understanding but not fully sufficient for safe and correct 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%, so the description must compensate. It provides no direct explanation of the four parameters, their formats, or when they are required. The mention of 'overwrite hazards' vaguely relates to parameters like mode and existing_handles, but not explicitly, leaving the agent to infer semantics from the schema alone.

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

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

The description clearly states a specific action ('Check') and a specific resource ('normalized Shopify product rows'), and lists four distinct check categories (missing identity fields, duplicate SKUs, unsafe image URLs, overwrite hazards). This clearly distinguishes it from sibling preflight tools targeting other domains.

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

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

The usage context is implied by the tool name and description—use it to preflight Shopify product CSV data before import—but there is no explicit 'when to use' or mention of alternatives. No exclusions or comparisons to sibling tools are provided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does add the cost and network ('Costs $0.25 USDC on Base mainnet') and implies a comparison rather than a mutation, but it does not state whether the operation is read-only, what the output shape is, or how failures are surfaced.

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

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

The description is two sentences with no filler. The core comparison purpose is front-loaded, and the cost/network detail is kept to a separate, terse sentence.

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

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

For a tool with nested parameters, no annotations, and no output schema, the description is incomplete: it omits return-value information, failure modes, prerequisites for valid snapshots, and guidance on when not to use this tool. The cost detail is useful but does not make the tool fully self-explanatory.

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 partially compensates by naming the compared evidence fields (robots, sitemap, canonical, title, structured-data) and clarifying that the two parameters are 'dated site snapshots.' However, it does not discuss the 'captured_at' or 'url' properties or the snapshot structure beyond what the schema already provides.

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

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

The description opens with a specific verb ('Compare') and identifies the exact resource: normalized robots, sitemap, canonical, title, and structured-data evidence across two dated site snapshots. This clearly distinguishes it from sibling change-packet tools by naming the domain and 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 implies when to use the tool: when you have two dated site snapshots and need to compare their discovery-related evidence. However, it provides no explicit exclusions, prerequisites, or references to alternative sibling tools for related comparison tasks.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a significant cost: '$0.05 USDC on Base mainnet.' However, it does not specify whether the operation is read-only, what side effects might occur, or what the return format is. The cost is a valuable addition, but other behavioral aspects remain undisclosed.

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 that conveys purpose and cost with zero wasted words. Every phrase earns its place, making it efficient and easy to parse.

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 a simple input (one array) and a clear stated purpose, but with no output schema or annotations, the description does not explain what the tool returns or how the results are presented. The cost disclosure is helpful, but the missing return-value description leaves some ambiguity for an agent trying to use the tool correctly.

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

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

The input schema defines 'cases' as an array with required fields id, expected_skills, and observed_skills. The description adds context by calling them 'skill activations' and referring to 'test cases,' which aligns with the schema fields. However, it does not add further details about parameter format or constraints beyond what the schema already provides. With 0% schema description coverage, the description partially compensates but remains at baseline.

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

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

The description uses the specific verb 'Compare' and clearly identifies the resource as 'expected and observed skill activations across test cases.' It also states the intended outcome: to 'expose missed and spurious routing.' This clearly distinguishes it from the sibling tools, which are all preflight/checker tools in different domains.

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

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

The description provides clear context that this tool is for comparing expected and observed skill activations in test cases to identify routing issues. It does not explicitly state when not to use it or name alternatives, but the context is strong enough for an agent to infer appropriate use cases.

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

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

With no annotations provided, the description carries the full burden. It discloses the cost ($0.05 USDC on Base mainnet) and the specific checks performed, which is valuable contextual behavior. The verb 'Flag' implies it is an analysis tool rather than a mutating operation, though return format is not specified.

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

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

The description is composed of two sentences that front-load the core action and immediately add the cost detail. Every word contributes meaning, with no redundancy or fluff.

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

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

The description covers the tool's primary function and cost, but since there is no output schema and no annotations, it leaves the return format unspecified. An agent might know what to expect (flagged issues) but lacks explicit guidance on the structure of the response. Slightly more detail would improve completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions concepts like 'cue timing', 'overlaps', and 'reading speed', which help infer the roles of the 'cues' and 'max_characters_per_second' parameters. However, it does not explicitly define the parameters or their formats, leaving some ambiguity for the agent.

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 the specific verb 'Flag' and clearly identifies the resource and scope: invalid cue timing, overlaps, empty captions, and excessive reading speed in normalized subtitle data. This uniquely distinguishes it from sibling tools, which cover unrelated domains.

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

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

The description clearly indicates the context for use ('normalized subtitle data') and implies its role as a QA checker. It does not explicitly mention alternatives or exclusions, but given the tool's uniqueness among siblings, the context is sufficient to guide selection.

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

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

Annotations are absent, so the description must carry the full burden of behavioral disclosure. It does mention the $0.05 USDC cost on Base mainnet, which is useful, but it omits whether the operation is read-only, whether authorization is required, what happens on contract violations, or any output format. Only minimal behavioral context is provided.

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

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

The description is two sentences long, front-loaded with the action verb 'Audit', and includes the cost in a compact second sentence. Every word earns its place with no redundancy or filler.

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

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

Given the absence of annotations, output schema, and parameter descriptions, the tool description is under-specified. It fails to explain return values, failure behavior, how to structure the contracts/calls arrays, or when to invoke the tool. This is a significant gap for a tool with complex nested parameters and no structured fallback.

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

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

Schema description coverage is 0%, and the description does not explicitly map parameters. It hints that 'calls' are recorded tool calls and 'contracts' are declared authorization/argument/call-count/outcome contracts, but it does not define their precise structure, required fields, or formatting expectations. The high-level domain context is insufficient for correct parameter construction.

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-resource pair: 'Audit recorded tool calls against declared authorization, argument, call-count, and outcome contracts.' It clearly distinguishes this tool from siblings like tool_description_contract_linter and completion_evidence_receipt_auditor by focusing on recorded tool calls and the enumerated contract dimensions.

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. The cost note is practical but not a usage directive. The agent gets no explicit conditions, prerequisites, or exclusions, making the choice among sibling audit/checker tools ambiguous.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a key side effect—cost ($0.05 USDC on Base mainnet)—and lists what the linter checks. However, it does not mention whether the tool is read-only, what the output/report format is, or any failure modes beyond the cost.

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

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

The description is two sentences, front-loaded with purpose and immediately followed by the cost detail. Every word earns its place; there is no fluff or repetition of schema information.

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

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

Given the tool is a simple linter with no annotations and no output schema, the description adequately covers purpose and cost, and the linting dimensions are useful. It does not specify the output format or error behavior, but these are reasonably implied by the 'linter' framing, making it 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 schema provides only structural details for 'tools' (array of objects with name/description), and description coverage is 0%. The description compensates by explaining that the array contains structured tool descriptions and names the aspects that will be linted, giving meaningful semantic context beyond the raw 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 uses a specific verb ('Lint') and object ('structured tool descriptions'), and enumerates the exact dimensions checked: bounded purpose, inputs, outputs, side effects, failure modes, cost, and idempotency. This clearly differentiates it from sibling tools like justhandled_tool_call_contract_auditor, which targets call contracts rather than descriptions.

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 clear usage context: use when you need to lint structured tool descriptions. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses a cost of $0.05 USDC on Base mainnet, which is a valuable behavioral trait, but it doesn't mention whether the tool is read-only, external calls, rate limits, or data handling. The cost disclosure adds some transparency, but the overall behavioral picture remains incomplete.

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

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

The description is two sentences, front-loaded with the purpose, and includes a critical cost detail without any redundancy. 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?

The tool has two parameters, nested objects, no output schema, and no annotations. The description gives a good list of checks and cost, but lacks information about the expected return format, the exact policy schema, or any post-execution behavior. For a checker tool with this complexity, more context would be needed for an agent to fully understand the tool's capabilities.

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

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

The schema has 0% description coverage, so the description must compensate. It implies that the 'links' parameter contains campaign links and that 'policy' relates to policy violations, but it doesn't explain the structure of the policy object or how it maps to the checks. Partial semantic support, but not thorough.

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 ('Check') and a resource ('campaign links') while enumerating concrete checks (missing UTMs, duplicates, case drift, policy violations, PII). This clearly distinguishes it from sibling tools like justhandled_redirect_map_preflight or justhandled_shopify_product_csv_preflight.

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 clear context for when to use the tool—whenever campaign links need UTM consistency checks—but does not explicitly mention any exclusions or alternatives. The naming and sibling list make the scope obvious enough for a 4.

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

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

With no annotations, the description carries the full burden of behavior disclosure. It usefully discloses the cost ($0.05 USDC on Base mainnet) and the specific checks performed, but it does not describe the output format, whether any mutations or side effects occur, or any authentication requirements. This is a moderate level of 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, well-structured sentence that front-loads the purpose and ends with the cost detail. Every word earns its place with no redundancy or filler.

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

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

Despite the detailed audit scope, the description is incomplete for reliable invocation. It lacks input semantics for the three required parameters, has no output schema, and provides no usage context or side-effect information. For a paid tool with no annotations, this is a significant gap.

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

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

Schema description coverage is 0%, and the description does not explain the three required parameters (observed_at, contracts, deliveries). It only hints at what the tool checks (e.g., payload fields, signature evidence) without mapping these to parameter meanings or structure. This adds little value beyond the minimal schema 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 uses a specific verb 'Audit' with a clear resource 'webhook deliveries' and enumerates a detailed set of audit dimensions (declared events, allowed versions, required payload fields, signature evidence, freshness, idempotency, replay). This clearly distinguishes it from sibling audit tools like tool_call_contract_auditor or completion_evidence_receipt_auditor.

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

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

The description clearly states its purpose, making the when-to-use context obvious: when one needs to audit webhook deliveries against various contract requirements. However, it does not mention alternatives or when-not-to-use scenarios, so it falls short of a 5.

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