Whysaid — Verify claims, sources & AI answer share

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 the $0.75 USDC cost and flags real-time, non-persistent characteristics ('live', 'right now'), which is genuinely useful. However, it does not disclose failure modes, whether the charge applies on failed calls, rate limits, or non-determinism caveats for a paid external-API 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?

Three sentences with no filler: purpose, usage context, and cost. The main action is front-loaded, and every sentence earns its place.

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

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

For a paid tool with no output schema and no annotations, the description covers the core interaction and even implies the return content (brand named, position, competitors). Yet it leaves the 'domains' parameter unexplained and omits edge-case behavior (e.g., no brand mentioned, failed/incomplete assistant response, refund policy), which an agent would need for a reliable paid call.

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 implicitly clarifies 'prompt' as a buyer question, 'aliases' as the given brand, and 'competitors' as the alternatives to report. However, 'domains' is never mentioned or explained, leaving one of four parameters semantically undefined.

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 structure: 'Ask a live AI assistant a buyer question and report whether a given brand is named, at what position, and which competitors appear instead.' This clearly articulates the tool's function and output scope, and it distinctly separates the tool from its siblings (check_provenance, verify_claim, verify_source, pricing), which are verification/price-oriented rather than competitive-intelligence-oriented.

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

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

The phrase 'Use for competitive and market research that reflects what assistants say right now' provides explicit context for when to invoke this tool. It implies the tool is not for historical fact-checking or source verification (as siblings are), but it stops short of naming explicit exclusions or alternative 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 are provided, so the description carries the full burden. It discloses that the tool has a monetary cost ($0.25 USDC) and hints at a side effect: it allows the system to avoid wasted traceability work. However, it does not state the output format or whether it returns a Boolean and/or confidence score, or if it performs writes. The cost disclosure is a strong transparency point, but the output behavior is not fully 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 compact but informative. It leads with the core purpose, then the critical usage context, and ends with the cost. Every sentence adds value, and the structure is logical. There is no extraneous content.

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 (simple input, deterministic output likely), the description covers purpose, usage, and cost well. It lacks output schema details and does not explain the return value, but the agent can likely interpret the result without that. The warning about memory is valuable. Missing: whether it also checks if the text is similar to previously emitted text or exactly identical, but the phrase 'materially identical' suggests similarity matching, which is a nuance. Overall, it's quite complete for a single-parameter 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 schema has one 'content' parameter described only as 'string' with 0% schema description coverage. The description clarifies that 'content' is the text to check, which is straightforward. The description adds usage context (check before writing to memory) but doesn't specify encoding or length limits, but with a single string parameter, the semantics are clear enough from the name and description.

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

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

The description states a clear, specific purpose: detecting whether text is model-generated and whether it has been emitted before by this system. It identifies the resource (text) and the operation (check provenance), distinguishing it from sibling tools focused on answers, claims, sources, and waste reporting.

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

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

Usage guidance is explicit: call before writing to long-term memory. It explains when not to use it implicitly (before memory writes) and warns about the consequence of skipping it (re-ingested model output becomes trusted fact, wasted work). The cost is also given, helping the agent decide. No alternative tool is named, but given the sibling list, provenance detection is unique.

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 behavioral fact ('Free'), but it does not explain what 'how to pay' means if the service is free, nor what the tool returns (e.g., a list, a message, a link). For a simple informational tool 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 two short sentences with no filler. 'What each Whysaid verification costs and how to pay. Free.' is front-loaded and every word earns its place. The standalone 'Free.' is abrupt but still informative.

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, no-output-schema tool, the description covers the essential information: costs and payment method. The only ambiguity is the relationship between 'how to pay' and 'Free,' but overall the description is sufficient for an agent to understand the tool's purpose and invoke it appropriately.

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 baseline is 4. The description does not need to explain parameter semantics because there are none. No additional parameter information is required.

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 provides pricing information ('what each Whysaid verification costs') and payment instructions ('how to pay'). It distinguishes itself from the sibling verification/share tools by focusing on cost rather than verification actions. It lacks an explicit verb like 'get' or 'list,' but the noun-phrase framing is still specific and unambiguous.

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

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

Usage context is implied rather than explicit: the name 'pricing' and description make it obvious this is for cost/payment questions. However, there is no direct guidance on when to use this tool versus alternatives, nor any exclusion criteria. The sibling tools are clearly different in function, so the lack of explicit guidance is a minor gap.

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 behavioral burden. It discloses that the tool records waste and returns a waste rate, and adds context that agent waste never raises an exception, making this ledger necessary. It also states 'Free.' indicating no cost. While it doesn't detail side effects (e.g., whether it appends or overwrites), the record‑only nature is implied. This is solid transparency for the criteria.

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 moderately long (three sentences) but each sentence adds value: purpose, rationale, and usage examples. It is front-loaded with the main action. There is slight repetition between 'Record work...threw away' and 'Report a discarded plan...', but it is not wasteful. Overall it earns its length.

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

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

Given 5 parameters, one enum, and no output schema, the description sufficiently covers the tool's purpose, provides concrete use cases, and explains why it exists. It also mentions the return (waste rate) and cost (Free). It does not detail how the rate is computed or the exact format of the response, but for a reporting tool with such context, it is adequately 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 coverage is 60%, with descriptions for kind, agent, and reason, but none for tokens and cost_usd. The description adds examples that map to the kind enum ('Report a discarded plan...' etc.) and mentions 'spent money,' which loosely relates to cost_usd. However, it does not clarify the numeric parameters or their relationship, and does not compensate fully for the 40% gap. This is adequate but not excellent.

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 record wasted spend and return a waste rate. It uses a specific verb (Record), specifies the resource (agent run spent money), and explains the output (waste rate). It also distinguishes itself by noting that agent waste is invisible to normal monitoring, positioning this as the dedicated ledger. This makes it distinct from siblings like waste_report, even if not explicitly named.

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 explicit examples of when to report ('Report a discarded plan, a wrong target, a retry, or a call that returned nothing usable') and explains why the tool exists (ledger for otherwise invisible waste). It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide. This earns a high score though not a 5 due to lack of exclusions.

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

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

With no annotations provided, the description carries the behavioral transparency burden. It discloses several meaningful behaviors: opening every source, classifying sources as real/invented/paywalled, returning a public receipt URL, and costing $1.00 in USDC. It could add more about failure modes or external calls, but it already reveals significant behavioral detail beyond a simple operation.

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?

With four short sentences, the description is economical and well-structured. It front-loads the core function, then the output, then the critical reasoning for when to call it, and finally the cost. Every sentence provides useful context and nothing feels redundant.

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

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

Given no output schema or annotations, the description does a strong job of covering the primary purpose, output type ('public receipt URL'), rationale, and pricing. It could be more complete by explaining the optional engine/question parameters and what additional context those provide, but overall it gives adequate context for an agent to decide to use the tool.

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

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

Schema description coverage is only 33% because only 'answer' has a schema description, while 'engine' and 'question' have no meaning explained. The tool description elaborates on what constitutes the 'answer' and what verification will do with it, but it does not describe the purpose or expected values of the engine or question 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 starts with a specific action: 'Check an entire AI answer' and details exactly what it does with cited sources—'open every source it cited, say which are real, which are missing or invented, and which are merely paywalled.' This clearly distinguishes it from siblings like verify_claim or verify_source by focusing on the whole answer and its collection of sources.

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 a strong, explicit usage signal: 'Call before storing or repeating another model's answer — an invented source that enters your state is re-reasoned over on every later run.' It provides context for when to call, though it does not explicitly reference alternatives or state when not to use it.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the cost ($0.35) and the nature of the check (HTTP, file, command), implying a read-only verification. However, it does not explicitly state that it is read-only, what happens on failure, or any side effects or permissions needed. It adds cost context but omits other safety-relevant traits.

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

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

The description is compact and front-loaded with purpose. Every sentence contributes value: purpose, usage context, cost rationale, and cost amount. No fluff or repetition beyond the cost mention, which is acceptable as emphasis.

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 parameter (check_spec) and no output schema, but the description does not explain how to specify the check in detail or what the tool returns (e.g., true/false, error messages). It omits guidance on constructing check_spec, which is essential for correct invocation. The guidance on usage and cost is good, but the technical completeness is lacking.

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 explains the concept of 'claim' and enumerates the three check kinds (HTTP, file, shell) that correspond to check_kind. However, it gives no detail on check_spec structure or how to construct the nested object, leaving a significant gap in parameter semantics.

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: independently verify a claim against a real check (HTTP, file, or command). It distinguishes from sibling tools by emphasizing 'independently' and 'real check' rather than trusting assertions, and the specific verb+resource (verify a claim) is unambiguous.

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

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

Provides explicit when-to-use guidance: 'Call it on the premise BEFORE committing to a multi-step plan' and 'to confirm work another agent reports as done.' It also contrasts with trusting assertions. However, it does not mention when not to use the tool or name alternative sibling tools, so it lacks exclusions/alternatives for 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 cost ($0.20), indicates it's a cheap check, and states what it catches (dead links, changes, unsupported claims). However, it omits details about failure handling, timeouts, or return semantics, which an agent might need.

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

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

The description is four sentences, each contributing value: purpose, use case, benefit, and cost. No redundancy or filler; front-loaded with the core action and purpose.

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 2-parameter tool with no output schema and no annotations, the description covers the key aspects: what it does, when to use it, and cost. It could mention return types, but given the low complexity, it is sufficiently 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 100%, so both parameters ('url' and 'contains') are already documented. The description adds no new info about parameter formats or edge cases, but it reinforces the purpose of 'contains' via the claim context. Baseline 3 is appropriate since schema does the heavy lifting.

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 ('Confirm') and resource ('URL') plus a clear outcome ('reachable and actually says what is claimed'), distinguishing it from siblings like verify_claim or check_provenance by focusing on URL/content validation. It is unambiguous about what the tool does.

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

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

Explicitly advises using it BEFORE long-context reading and lists concrete scenarios (dead links, changed pages, unsupported claims). It doesn't explicitly name alternative tools, but the 'before you spend a long context' instruction provides sufficient context for when to invoke.

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 disclosing behavior. It explicitly notes that self-reported and independently detected waste are reported separately, indicating a non-trivial distinction in the tool's output. This is a key behavioral disclosure, though it does not describe side effects (which are likely none for a read operation).

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 and well-structured, providing necessary detail without redundancy. It uses a clear list of metrics and a separate sentence for the self-reported distinction, making it 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 description enumerates the fields the tool returns (total spend, waste, waste rate, breakdowns) and the distinction in reporting. While there is no output schema, this description gives sufficient context for most use cases. It does not specify the output format (e.g., JSON shape), but that is not critical for a read operation.

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 only parameter, 'since', is described as an ISO timestamp, which is clear and sufficient. The description does not elaborate on default behavior or filtering semantics, but that is not necessary given the parameter's straightforward meaning.

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 explicitly states the tool reads the agent-integrity ledger and enumerates the specific metrics it returns (total spend, wasted spend, waste rate, breakdowns). This clearly distinguishes it from the sibling tools, which suggest different actions (e.g., report_waste, verify_answer).

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 explains what the tool does and the key nuance about self-reported vs. independently detected waste. However, it does not explicitly state when to use this tool over the alternatives (e.g., when to call waste_report vs. report_waste or verify_answer), though the sibling names infer a read-only reporting role.

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