Whysaid

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.05 in USDC) and implies a query-only behavior (asking an assistant), but does not explicitly state whether it is read-only, the exact response format, or any side effects. The cost disclosure adds value, but operational details are sparse.

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 compact and front-loaded, with the primary action and output in the first sentence, and the use case and cost in the second. It is efficient and well-structured, though it could arguably be slightly more organized with bullet points for parameters, but the brevity is a strength.

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 purpose, output, and cost, but lacks details on all parameters (domains, competitors) and does not explain the return format or any side effects. With no annotations and no output schema, the description should provide more detail, but it does cover the core functionality sufficiently for basic use.

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 hints at 'prompt' (buyer question) and 'aliases' (brand name), but does not explain 'domains' or 'competitors'. The description under-explains the parameters, failing to provide complete semantics for all four inputs.

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

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

The description clearly states the action ('Ask a live AI assistant'), the resource ('a buyer question'), and the output ('report whether a given brand is named, at what position, and which competitors appear instead'). It differentiates from sibling tools like verify_claim and check_provenance by focusing on brand mentions and competitive analysis.

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 states a clear use case: 'Use for competitive and market research that reflects what assistants say right now.' However, it does not provide exclusions or alternative tool comparisons, leaving the agent to infer when not to use this tool. This provides some guidance but lacks explicit when-not-to-use direction.

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 behavioral traits: it checks two things (model-generated and material similarity), and it mentions a cost of $0.01 in USDC, which is critical for an agent to know before invocation. This goes beyond a simple verb phrase.

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

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

The description is three sentences: purpose, usage context, and cost. Every sentence adds value, no fluff. It is front-loaded with the core action.

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 simplicity (one string parameter), no output schema, and clear description, it is complete for an agent to decide and invoke. It mentions cost, which is additional critical context. No further information is needed.

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

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

Schema coverage is 0%, so the description must compensate. It explains what 'content' is (the text to check) implicitly by describing the tool's action, but it does not specify the format or length limits. However, with only one parameter, the tool name and description make it clear that 'content' is the text 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 clearly states the tool's purpose: detecting whether text is model-generated and whether it has been emitted before materially identically. It names the specific verb 'Detect' and specifies the resource ('a piece of text'), distinguishing it from siblings like verify_claim or verify_source.

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 explicitly says when to use: before storing text in long-term memory, to prevent re-ingestion of model output as fact. It does not name alternatives, but the context is clear and exclusive enough given the domain.

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 transparency burden. It reveals that the tool provides informational pricing content and notes that the service is free, but does not explicitly state read-only behavior, lack of side effects, or any required permissions. Given the tool's simplicity, this is adequate but minimal.

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

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

The description is exceptionally concise: a single sentence plus the fragment 'Free.' It front-loads the core purpose and every word contributes value, with no wasted text.

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

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

For a zero-parameter informational tool with no output schema, the description fully conveys the content: the costs and payment methods, and the key fact that it is free. It is complete for the tool's simple scope.

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

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

The tool has zero parameters and the schema coverage is 100% (vacuously). Per the guidelines, the baseline for 0 parameters is 4. The description adds contextual meaning by explaining what the tool reports, which is sufficient.

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

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

The description clearly states the tool's purpose: to show the costs and payment methods for Whysaid verification. It distinguishes from sibling verification tools by focusing on pricing information, making the resource type 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 the tool is used when one needs pricing or payment info, and the sibling tool names make it clear this is separate from verification actions. However, it does not explicitly state when to use it versus alternatives or provide exclusions.

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

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

The description discloses that the tool performs a 'real check' including HTTP fetch, file access, or shell command, and it explicitly notes the cost ($0.02 USDC). However, it does not mention potential side effects (e.g., executing arbitrary commands, modifying files) or any security/authorization considerations, which are critical for a tool that can run shell commands. This is a significant gap given the absence of annotations.

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

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

The description is extremely concise—two sentences—and directly conveys the purpose, use case, and cost. There is no fluff or redundant information; every sentence 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 (check_spec) and executes potentially complex operations (HTTP, file, shell). The description lacks any explanation of the check_spec structure, expected output, error handling, or edge cases (e.g., what happens if the claim is false). It fails to provide enough context for an agent to use the tool reliably without additional external documentation.

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

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

The schema provides only parameter names and types without any descriptions. The description adds no detail about what `claim`, `check_kind`, or `check_spec` mean semantically, nor does it explain how they interact (e.g., how check_spec is structured for each check_kind). With zero schema coverage and no parameter explanations, an agent would struggle to construct valid inputs.

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: independently verify a claim using a real check (HTTP fetch, file, or command). It distinguishes itself from sibling tools like verify_source by focusing on verifying a claim's truth rather than source credibility, and it explicitly mentions confirming another agent's reported work.

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 a clear usage scenario: 'Use to confirm work another agent reports as done.' It also mentions the check types (HTTP, file, shell) and the cost. While it doesn't explicitly state when not to use it, the given use case is specific enough to guide an agent effectively.

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 transparency burden. It discloses a real side effect: 'Costs $0.02 in USDC' and explains the verification behavior. It does not state return format or read-only guarantees explicitly, but the description is more transparent than typical check tools.

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?

It is two compact sentences: purpose first, usage second, then cost. Every sentence adds necessary information 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 simple 2-parameter schema, no annotations, and no output schema, the description covers purpose, trigger, failure modes, and cost. A return-value format is not explicitly outlined, but 'confirms' and 'catches' make the pass/fail nature reasonably obvious.

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

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

Schema coverage is 100%, and both parameters already have meaningful schema descriptions. The tool description reinforces the purpose and why `contains` matters, but does not add much semantic information beyond what the schema 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 starts with a specific verb and resource: 'Confirm a URL is reachable and actually says what it is claimed to say.' This clearly scopes the tool to URL-source verification and differentiates it from sibling claim/provenance checks.

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 explicitly says to use the tool 'before citing, quoting, or acting on a web source' and names the failure modes it catches: dead links, changed pages, and unsupported claims. It does not name alternative tools or exclusion conditions, but the usage context is clear.

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