Fara

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral context beyond these: it discloses the cost model (free default, BYO key for Anthropic), the return structure (per-model {score, confidence, signals, raw_response} plus combined view), and the probing nature. No contradictions with annotations.

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

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

The description is a single, well-structured paragraph covering function, defaults, optional parameters, return format, and use cases. Every sentence adds value. Slightly longer than necessary but still 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?

For a tool with moderate complexity (4 parameters, read-only, no output schema), the description covers purpose, usage, parameters, and return format. Use cases are given. No output schema exists, but the description states what is returned. Sibling tools are present but not cross-referenced.

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%, so baseline is 3. The description adds minimal extra meaning beyond the schema—e.g., examples for entity and clarification that _apiKey is only needed for anthropic. However, the schema already describes all parameters well; the description does not provide critical missing semantic details.

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 defines the tool's purpose: probing LLMs for knowledge about an entity and scoring visibility. It uses specific verbs ('probe', 'score') and specifies the resource ('one or more LLMs'). The description distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on individual entity visibility scoring, not competitive scanning.

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

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

The description explicitly states when to use the tool: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also explains that the default model is free while Anthropic requires a paid key. However, it does not mention alternatives from the sibling list or specify when not to use this tool in favor of 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 annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds valuable behavior beyond them: it routes to 5,743 tools across 1,500 verified sources, fills arguments automatically, and returns structured answers with stable pipeworx:// citation URIs. It also describes the output style and cites real-world data coverage, making the tool's behavior and limitations transparent. No contradiction with the 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 dense but efficiently organized: preference statement, domain list, routing behavior, trigger phrases, examples, and alternative-tool routing. It is front-loaded with the key 'PREFER OVER WEB SEARCH' decision and each sentence earns its place by adding actionable information. Length is justified by the breadth of the tool.

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

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

For a one-required-parameter, read-only lookup tool, the description is highly complete: it explains when to use it, what it does internally, what kind of answers it returns, and which sibling tools to choose instead. The absence of an output schema is mitigated by describing the structured-answer and citation-URI return format. No significant contextual gap remains.

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

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

Schema coverage is 100%, with the 'question' property fully described as accepting natural language and aliases (query, q, prompt, text, input). The description adds helpful example phrasings, but it does not meaningfully extend parameter semantics beyond the schema. Baseline 3 is appropriate because the schema already carries the parameter-level burden.

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 and resource: it 'routes the question to the right one of 5,743 tools' and covers a concrete topical scope including SEC filings, FDA data, economic statistics, and patents. It also distinguishes itself from siblings by explicitly naming ask_pipeworx_grounded and deep_research as alternatives. This leaves no doubt 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?

The description gives explicit guidance: 'PREFER OVER WEB SEARCH' and 'START HERE for most questions,' with trigger phrases like 'what is', 'look up', 'find', 'get the latest', and 'current'. It also provides clear when-not guidance by naming ask_pipeworx_grounded for verbatim-evidence questions and deep_research for broad multi-part research. This is strong, actionable routing guidance.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds significant context beyond that: beta status, live candidate routing when under test, the retired-candidate date, and clarification that this is a full working router rather than a fallback. No contradiction with annotations exists.

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?

Four sentences with no filler, front-loaded with identity and scope, then state, usage, and a clarifying correction. Every sentence contributes unique useful 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?

For a complex router covering 5,743 tools, the description fully equips an agent: what the tool is, its relationship to siblings, current runtime state, exact usage guidance, and response-shape equivalence. Annotations and schema cover side effects and parameters, leaving no critical 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 100%, with every parameter documented as an alias for question or the main question input. The description adds no parameter-level detail, but the schema already carries the full burden, so the baseline score of 3 applies.

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

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

Description identifies the tool as a beta variant of ask_pipeworx, a universal router with the same 5,743 tools, arguments, and response shape, and distinguishes it from the stable sibling via experimental routing improvements. This is specific, uses a clear verb-resource relationship, and avoids tautology.

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 instructs to use it 'exactly like ask_pipeworx when you want the newest routing,' implicitly naming ask_pipeworx as the stable alternative. It also states that results are compared against the stable router to decide what merges, and notes no candidate is active, so current behavior matches stable exactly.

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?

Beyond the readOnly/openWorld annotations, the description details that the answer is extracted only from tool results, defines the refusal contract with specific reasons, and quantifies the extra LLM-call cost. This gives the agent a precise model of what the tool will and will not do.

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 dense but front-loads the core purpose, then packs behavioral guarantees, response shape, refusal reasons, and cost into later clauses. Every clause adds decision-relevant information; no filler or tautology.

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?

Even without an output schema, the description defines the success and refusal response shapes, usage criteria, cost tradeoff, and relationship to ask_pipeworx. An agent has everything needed to decide and invoke 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?

Schema coverage is 100%, so the parameter is already documented in the input schema; the tool-level description adds little about the 'question' parameter beyond the general behavior of routing it to internal tools. This meets the baseline expected when the schema carries the semantic load.

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 opening phrase 'Hallucination-resistant answer mode for high-stakes reads' names a specific mode and its purpose, and the body explains it is the grounded variant of ask_pipeworx. This makes its function and relationship to the main sibling tool immediately identifiable.

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 'Use whenever an answer will be quoted, cited, or acted on' and contrasts with ask_pipeworx: 'prefer ask_pipeworx for casual lookups.' This tells an agent exactly when to select this tool over the nearest alternative.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds extensive behavioral details such as fan-out logic, resolver confidence handling, safety short-circuits for low-confidence matches and closed markets, and cancellation rule parsing – all beyond what annotations provide.

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 lengthy but well-structured with clear headings (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.). Every section earns its place given the tool's complexity, though it could be slightly more concise without losing 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?

No output schema exists, but the description comprehensively covers return shapes (RESPONSE SHAPES, RESOLVER CONTRACT), edge cases (illiquid markets, closed markets, 429 retries), and resolution rules (cancellation_rule). All parameter semantics and behavioral nuances are fully explained.

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%, so parameters are documented. The description enriches understanding by providing examples for the market parameter (slug, URL, text) and explaining the include_raw parameter's impact on response size ('summarized to the few fields agents actually use' vs 'full upstream payloads').

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: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It distinguishes itself from siblings by focusing on a single bet's research pipeline, with specific classifiers and fan-out examples.

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 use cases: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' However, it does not explicitly guide when to use alternatives among the many 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?

Annotations declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description adds detailed behavioral context: it pulls latest 10-K data for companies including handling off-calendar fiscal years, FAERS data for drugs, sorts results by primary metric, and returns citation URIs. No contradictions.

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 paragraph that front-loads with trigger phrases and examples. It is slightly long but every sentence adds value, making it efficient and 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?

Given the tool's complexity (two entity types, no output schema), the description explains return data (revenue, net income, cash, debt for companies; FAERS counts for drugs) and includes citation URIs. It covers sorting and replacement of multiple lookups, making it fully informative.

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

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

Schema coverage is 100% with clear descriptions. The description adds real-world examples (tickers/CIKs for company, drug names) and clarifies maxItems=5 and minItems=2, which provides context beyond the schema.

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

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

The description clearly states it performs side-by-side comparison of 2-5 entities (companies or drugs) in one parallel call. It gives specific example prompts and explains the data retrieved for each type, distinguishing it from sequential lookups.

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

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

The description explicitly advises preferring this tool over sequential lookups and provides example queries. It covers both entity types but does not explicitly state when not to use it, though the context is clear.

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

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

Annotations already cover safety (read-only, idempotent, open-world), but the description adds substantial behavior beyond them: parallel decomposition across 5,743 tools, findings packets with gaps[] and never invented answers, contradictions[] scans, semantic excerpting, and latency expectations. No contradiction with annotations.

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

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

The description is long but unusually dense; the account/sign-in warning is front-loaded, followed by purpose, differentiation, output format, and runtime. A few clauses could be tightened, but nearly every sentence carries operational weight.

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 complex tool with no output schema, the description covers selection criteria, prerequisites (account/plan), invocation semantics, return contents, citation fetchability, gap handling, and timing. An agent has everything needed to decide, call, and 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 coverage is 100%, so the baseline is 3; the description adds real value by tying the depth parameter to account tier and paid plan, and by explaining hop/recovery behavior for standard and thorough. It does not duplicate the schema's enum details, making this a clear increment over 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 names the verb and resource precisely: grounded multi-source research across Pipeworx's structured data sources, explicitly distinguishing itself from open-web search and from ask_pipeworx. It differentiates from siblings by scope (broad/multi-part over structured data) and by decomposition/parallel-routing behavior.

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?

Gives explicit conditions: use ask_pipeworx when not signed in or for single lookups; use deep_research for broad/multi-part questions. It also states the paid-plan requirement for thorough depth, leaving no ambiguity about when to choose this tool over its siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that results are 'ready to call directly, no second schema lookup needed' and mentions top-N relevance. It doesn't contradict 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 a single paragraph that front-loads purpose and domain list, then explains return value and usage. It is effective but could be slightly more concise by separating usage guidance.

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, the description fully explains what is returned (names, descriptions, schemas with examples). It also provides context for when to use it. Complete for a discovery 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 coverage is 100%, so the description adds limited value beyond the schema. It includes example queries and notes aliases, but these are already in the schema. Baseline of 3 is appropriate.

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

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

The description clearly states 'Find tools by describing the data or task' and enumerates specific domains (SEC filings, FDA drugs, etc.). It distinguishes itself from sibling tools by being the discovery mechanism, not a specific data tool.

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

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

Explicitly advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives clear when-to-use guidance and implies it precedes tool invocation.

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 goes far beyond the readOnly/openWorld/idempotent annotations, detailing the parallel fan-out across many sources, the meaning of sources_used/sources_failed, the expected-empty behavior for certain company types, and the resolved:false path for private companies. This gives an agent a realistic model of what the call returns and what counts as success or null data.

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 long but dense and the tool is complex, so the length is mostly justified. It front-loads trigger phrases and the core 'one parallel call' value proposition, then organizes output semantics and edge cases. The repeated mention of type interchangeability is slightly redundant with the schema, but the overall structure earns its place.

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

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

Given no output schema, the description provides remarkably complete context: input variants, source coverage, resolved/unresolved behavior, source-failure semantics, expected empty sections, and a note about patents API soft-failing. An agent has what it needs to invoke the tool correctly and 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 coverage is 100%, so both parameters are already documented. The description adds meaningful behavior: type values are interchangeable, value can be ticker/CIK/name, and names resolve through SEC EDGAR's company-name match. This extends the schema rather than merely repeating it.

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 precise action: produce a full cross-source profile of a US public company in one parallel call. It clearly differentiates itself from narrower single-source lookups and lists the accepted input forms (ticker, CIK, name).

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 gives explicit trigger scenarios ("Tell me about X", "research Acme", "brief me on Tesla") and instructs to prefer this over chaining single-pack SEC/XBRL/news lookups for holistic questions. It does not name specific sibling alternatives or state when NOT to use it, but the guidance is strong and actionable.

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 indicate destructiveHint=true and idempotentHint=true. Description confirms deletion and adds context about clearing sensitive data. No contradictions, but could mention irreversibility or security implications.

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 zero waste: purpose first, then usage guidance. Perfectly 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?

For a simple tool with one parameter and no output schema, the description, combined with annotations, covers purpose, usage, safety, and idempotency. No gaps identified.

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

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

Schema coverage is 100% with the 'key' parameter described as 'Memory key to delete'. Description adds no additional meaning beyond the schema, so baseline score is appropriate.

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

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

Description clearly states 'Delete a previously stored memory by key' with specific verb, resource, and method. It distinguishes from sibling tools like 'remember' and 'recall' by implying deletion versus creation or retrieval.

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 use cases: 'Use when context is stale, the task is done, or you want to clear sensitive data.' It also suggests pairing with related tools, though it lacks explicit 'do not use' guidance.

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

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

Adds behavioral details beyond annotations: fetches page, extracts title/description/key links, outputs standard markdown. No contradictions with annotations.

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

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

Two well-structured sentences: first states purpose and output, second lists use cases. Front-loaded, no 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?

No output schema; description explains output as 'single text blob ready to drop at site-root/llms.txt'. Covers parameters and process adequately for a simple 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 coverage is 100%; description adds concrete example for 'url' ('e.g. https://example.com'), enhancing meaning beyond 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?

Description states specific verb 'Generate' and resource 'llms.txt file for any URL'. It distinguishes from siblings by noting use cases like 'getting a client's site indexed by AI' vs other tools like scan_competitor_ai_presence.

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

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

Provides clear use cases (client indexing, own project, competitor audit) but does not explicitly state when not to use or mention 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?

Annotations already declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds that results are capped, filters are client-side, and each row includes foreign principal details and a PDF URL, which are useful behavioral details beyond 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 two sentences, front-loads the main action, and is generally concise. The term 'Keyless' is somewhat cryptic and could be clearer, but overall it is efficiently structured.

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 schema fully describes parameters and annotations provide key traits, the description covers output structure (foreign principal, PDF URL), limitations (capped), and filter behavior. It is complete for a read-only listing tool, though 'Keyless' is vague.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces the source of registration_number and mentions client-side filtering, but does not add significant new meaning beyond the schema.

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

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

The description clearly states it lists FARA filings for a registrant by registration_number, specifies document types (registration statements, supplemental, etc.), and references the sibling tool search_registrants, distinguishing its 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 indicates that registration_number comes from search_registrants, and mentions optional client-side filters by document_type or country. It lacks explicit when-not-to-use guidance, but provides clear context for use.

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

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds value by disclosing that filtering is applied client-side, listing the return fields, and noting 'Keyless' (implying no authentication key required). This is sufficient extra context beyond 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 concise and well-structured. It starts with the core purpose, then explains prerequisites and optional usage, and ends with return fields. Every sentence adds value without redundancy.

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

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

Given the simplicity of the tool and the lack of an output schema, the description is complete. It covers the required parameter, optional parameters with usage hints, the dependency on search_registrants, and the fields returned.

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%, so baseline is 3. The description adds meaningful usage guidance: it clarifies that the name and country filters are substring-based and client-side, and that status defaults to active. This enriches the understanding beyond 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 the tool lists foreign principals for a given FARA registrant, with a specific verb ('List') and precise resource description. It distinguishes itself from sibling tools like search_registrants by explicitly noting where to obtain the required registration_number.

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 excellent context on how to use the tool: retrieve a registration_number from search_registrants first, then call this tool. It also explains optional client-side filtering and the use of the status parameter for terminated relationships. However, it doesn't explicitly state when not to use this tool or mention alternative tools for other 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?

Annotations already cover readOnlyHint and destructiveHint. The description adds behavioral context: returns specific fields, defaults to active subscriptions, and explains the include_inactive parameter. No contradictions.

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 extraneous information. Every sentence adds value: first explains what the tool does, second gives usage advice.

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 read-only tool with one optional parameter and no output schema, the description is complete. It covers purpose, return fields, default behavior, and usage context. Annotations handle safety.

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

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

Schema coverage is 100%, and the parameter's description in the schema is clear. The tool description does not add further meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states it lists the caller's active subscriptions and specifies the returned fields (id, type, params, etc.). It distinguishes itself from sibling tools like subscribe and unsubscribe by focusing on listing existing subscriptions.

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 guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' While it doesn't list alternatives, it gives clear when-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?

Annotations are all false (neutral), so the description carries the burden and does so excellently. It discloses the return of a claim_token without an account, how to read status later, rate limiting (5 per identifier per day), and cost (free, doesn't count against quota). It also describes the team's digest review and roadmap impact, giving a full picture of the tool's behavior and consequences.

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?

Although longer than average, every sentence earns its place: purpose, use cases, exclusions, content guidance, token mechanism, review cadence, rate limit, and cost. The structure is front-loaded with the core purpose and flows logically. No fluff or redundancy exists; it is dense but highly scannable.

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 4 parameters (one deeply nested), no output schema, and no annotation hints, the description comprehensively covers all behavior and edge cases: when to use, when not to use, how to reference Pipeworx tools, the claim-token lifecycle, rate limits, and cost. It fully compensates for the lack of an output schema by explaining what filing returns. The tool is simple, but the description leaves no gaps.

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%, but the description adds significant semantic value beyond the schema. It explains the 'type' categories in context, clarifies the 'claim_token' flow with a concrete example, advises on 'message' specificity, and provides guidance on using 'context' for tool/pack/vertical references. The description enriches each parameter with practical usage 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 opening sentence, 'Tell the Pipeworx team something is broken, missing, or needs to exist,' clearly states the tool's purpose with a specific verb and resource. It distinguishes itself from sibling tools (which are all research/query tools) by being the only feedback mechanism. The description immediately establishes its unique role.

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

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

The description provides explicit when-to-use criteria: bug, feature/data_gap, praise, and other. It also gives a clear exclusion rule: 'ONLY for tools served by this Pipeworx connection… file it with that server instead.' It further explains what to include ('in terms of Pipeworx tools/packs') and the claim-token workflow, offering comprehensive decision 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?

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds: data source (CF analytics-engine), no PII, caching behavior (5min-1h), self-aggregating nature. Adds significant behavioral context beyond 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?

Five sentences, well-structured with numbered use cases. No wasted words; 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?

Tool is simple (1 optional param, no output schema). Description fully covers purpose, usage, behavioral context, and caching. No gaps.

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?

Only one parameter (window) with enum and description already in schema. Description adds context that shorter windows surface hot trends and longer windows show steady-state demand, adding meaning beyond the schema.

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

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

Description clearly states it returns top tools, top packs, and total call volume over time windows. Distinguishes from siblings by focusing on trending data rather than general AI visibility or research.

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?

Describes three explicit use cases (discovering hot data, confirming canonical choice, checking alignment). No when-not-to guidance but the use cases are clear and actionable.

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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant context: scanning top ~200 markets, event/topic modes, partition_check conditions, fill check against live CLOB depth, and edge cases like placeholder filters. No contradictions with annotations.

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

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

The description is lengthy but well-structured with sections (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK). It is informative but could be slightly more concise. However, every paragraph 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?

No output schema provided, but the description thoroughly explains the response structure (opportunities array with gap_pp, suggested_trade, reasoning, etc.) and partition_check object. It covers input modes, behavior, and edge cases. Sufficient for a 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 coverage is 100% with descriptions for both parameters. The description vastly expands: provides usage examples, explains how each mode works, details about semantic anchor, partition filter, and fill check. Adds meaning far beyond the schema.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes between 'event' and 'topic' modes and mentions fill check. This specificity differentiates it from sibling tools like polymarket_edges or polymarket_fill_risk.

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 states when to call with no args (trending scan), pass 'event' for per-event partition check, or 'topic' for cross-event scan. Recommends event for specific markets and explains when not to trade (realizable_edge_pp <= 0). Provides clear context and exclusion criteria.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds significant behavioral context: caching (1h at KV level), output structure (by_segment with diagnostics), and what happens when segments are empty. It also explains the origin of edges (model families) and knobs for tradeability, providing useful transparency beyond 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 quite lengthy (multiple paragraphs) and includes detailed technical explanations. While it is well-structured with sections, it could be more concise. Some information is redundant with the input schema, and the depth of detail may overwhelm users seeking a quick understanding.

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

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

Given the complexity (9 parameters, no output schema), the description is exceptionally complete. It explains the output structure in detail (by_segment, diagnostics), caching behavior, model families, and filter knobs. It compensates well for the lack of an output schema, leaving little ambiguity about what the tool returns and how it behaves.

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%, so baseline is 3. The description does not add much beyond the already detailed parameter descriptions in the input schema. While it reiterates some points (e.g., slippage_pp context), it does not significantly enhance understanding of parameter behavior or constraints 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 clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It uses specific verbs and resources, and the context of 'what should I bet on today' helps clarify its intent. However, it does not explicitly differentiate from sibling tools like polymarket_arbitrage or polymarket_edge_tracker, which could lead to confusion.

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 mentions it is 'built for "what should I bet on today"—agents discover opportunities without paging hundreds of markets,' implying a use case. However, it lacks explicit guidance on when not to use this tool versus alternatives, and does not mention sibling tools that might be more appropriate for specific tasks (e.g., arbitrage or fill risk).

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context: history bounded by 60-day snapshot TTL, data starts from when snapshotting was enabled, decay numbers from daily closes, not intraday. This exceeds annotation coverage without contradicting.

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 well-structured, starting with a summary, then listing arguments, response structure, and limitations. Every sentence adds value without redundancy. It is front-loaded with the core question, and technical details are organized in separate sections.

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 no output schema, the description comprehensively explains the return structure: tracked[], expired[], snapshot_dates[], with field meanings and edge cases (e.g., median lifespan as competition clock). Limitations are stated. This fully equips the agent to understand and 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 100%, so baseline is 3. The description adds minor clarifications: default and max values for 'days', and 'snapshot family' context for 'window'. This slightly enhances understanding but does not significantly exceed the schema.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily snapshots. It answers the specific question 'how long has this edge existed and is it shrinking?' with detailed outputs (tracked, expired, snapshot_dates). This distinguishes it from sibling tools like polymarket_edges, which likely focus on current state.

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 (to evaluate edge persistence and decay) but does not explicitly state when not to use it or mention alternatives. The example about a fresh wide edge vs. a 3-week-old edge provides context but no direct usage exclusion.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details like walking the ladder, returning verdicts (clean|degraded|cannot_fill), and warning about forced directional risk. No contradiction with annotations.

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

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

The description is well-structured with clear sections for single-market and basket modes, and usage guidance at the end. It is slightly verbose due to listing all return fields, but every sentence adds value. Could be slightly tighter but overall good.

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

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

Despite having no output schema, the description fully enumerates all return fields for both modes (e.g., top_of_book, vwap_fill_price, slippage_pp, theoretical_sum, realizable_sum, etc.), covering all necessary behavioral aspects. Complete for a 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 100%, but the description adds significant meaning: it explains the required one-of market or event, defaults for side and size_usd, and how size_usd is interpreted differently in single-market vs basket mode. This goes beyond the schema.

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

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

Description clearly states the tool checks realizable vs theoretical edge against live CLOB order book depth, distinguishing between single-market and basket modes. The verb 'check' and resource 'fill risk' are specific, and the tool is differentiated from siblings like polymarket_arbitrage and polymarket_edges.

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?

Description explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500' and explains the risks of partial fills and unhedged directional positions. This provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already cover readOnly/openWorld/idempotent/no-destructive hints, and the description goes well beyond them: it documents safety fields (compatibility_warning, compatibility_codes[]), clarifies that temporal_alignment_unknown is not confirmed-aligned and null ≠ aligned, discloses that spreads are gross and do not model Kalshi fees, and explains skipped_cross_type/subtype counters. It also states explicitly that unclassified legs are never paired. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose and organized with CAPS-labeled sections for modes, response, safety fields, and caveats. It is long, but each sentence carries non-redundant operational detail; the density is justified by the tool's complexity, though a more compact summary of edge cases would improve readability.

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, but the description fully enumerates the response shape: leg-by-leg prices, spread[].top_spreads_pp, compatibility_warning, compatibility_codes[], per-entry flags[], skipped_unclassified, low_confidence_pairs[], temporal_alignment, fees_note, and skip counters. It also explains how to interpret null values and non-empty safety fields, so an agent has everything needed to invoke and parse 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?

Schema coverage is 100%, but the description adds meaningful semantics: explicit ticker/slug parameters 'Override the topic-mapped' side, both modes run the identical token-overlap matcher, and concrete example values (KXFED-26OCT, fed-decision-in-june-825) are provided. This is more than the schema's field descriptions 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 opening sentence is a precise statement of function: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It names the exact resources and operation, and the cross-venue framing distinguishes it from Polymarket-only siblings like polymarket_edges or polymarket_arbitrage.

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

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

The description explicitly lays out TWO MODES — topic shortcuts vs explicit kalshi_event_ticker + polymarket_event_slug — and explains when each applies. It also sets expectations with 'pre-mapped ≠ tradeable' and warns that most topics return compatibility warnings. No alternative sibling tool is named, but the mode-level usage guidance is clear and actionable.

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

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

Annotations already indicate readonly and nondestructive. Description adds scoping (by identifier) and pairing context. No contradiction with annotations.

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

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

Four sentences, each adding unique value: core function, use cases, scoping, and pairing. No wasted words.

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

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

Given simplicity of tool (one optional parameter, no output schema, rich annotations), description provides complete context for correct agent 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?

Adds meaning beyond schema by explaining behavior when key is omitted (list all keys). Schema coverage is 100% but description enhances understanding.

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?

Clearly states the verb (retrieve/list) and resource (values saved via remember). Distinguishes from sibling tools remember and forget.

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 provides when to use (look up context stored earlier) and alternatives (pair with remember/forget). Includes concrete examples like ticker, address, notes.

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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds valuable behavioral details: return fields (source, citation_uri, raw payload), mark_read side effect, polling suitability, and the alternative endpoint. No contradictions.

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: four sentences, each carrying distinct information without redundancy. It front-loads the primary purpose and progressively adds filter options, behavior, and alternatives. 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?

The description covers the main use case, return fields, filtering, and mark_read behavior. It lacks details on pagination beyond the limit parameter, and error scenarios. However, given the rich annotations and schema, the description is largely complete for effective tool selection.

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

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

Schema coverage is 100% with descriptions for all parameters. The tool description adds usage examples (e.g., 'sec_8k' for type) and clarifies behavior (e.g., mark_read:true to flag read). This adds value beyond the schema, justifying a score above the baseline of 3.

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

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

The description clearly states the tool's purpose: 'Pull fired events from your subscription feed. Returns the most recent alerts the evaluator has written to your persisted feed.' It specifies the verb (pull) and resource (recent alerts), distinguishing it from sibling tools like list_subscriptions or subscribe.

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

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

The description provides guidance on when to use filters ('Filter by type and/or since'), how to manage read state with mark_read, and mentions an alternative access method (direct URL). It lacks explicit when-not-to-use guidance but still offers clear context for usage.

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

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

Describes multi-source fan-out, fallback behavior (GDELT→GNews), and soft-fail for USPTO after May 2025. Annotations already indicate read-only and non-destructive nature; the description adds behavioral detail without contradiction.

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

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

Front-loaded with concrete query examples, but description length is justified by covering multiple sources and fallback logic. Could trim slightly but retains necessary detail.

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 (multiple sources, fallback, soft-fail) and absence of output schema, the description fully explains return structure (changes[], total_changes, URIs) 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 coverage is 100%, baseline 3. Description adds value by clarifying 'since' accepts ISO or relative shorthand with examples, 'value' as ticker or CIK, and 'type' enumeration scope.

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 defines the tool as a change feed for a company in a time window, with specific verb+resource and example queries. It distinguishes from sibling 'entity_profile' by specifying static vs. change-oriented use cases.

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 states when to use alternative tool 'entity_profile' for static data. Provides context for typical monitoring durations but lacks explicit when-not-to-use scenarios beyond that.

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

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

Adds details beyond annotations: scoped by identifier, persistent for authenticated users, 24h for anonymous, and pairing with recall/forget. No contradiction with annotations.

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

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

Three sentences, front-loaded with purpose, each sentence adds value: what, when, how, and pairing.

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?

No output schema, but description adequately covers usage context and persistence. Could mention if return value includes confirmation, but not essential for a write 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?

Schema coverage is 100%, so baseline is 3. Description adds examples for key naming (e.g., 'subject_property') but no additional format or constraints beyond 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?

Description clearly states the tool saves data for reuse, gives specific examples (resolved ticker, target address, user preference), and distinguishes from siblings recall and forget.

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

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

Explicitly says when to use (discovering something worth carrying forward) and mentions alternatives (pair with recall/forget) for related operations.

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

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

Annotations already mark it read-only/idempotent/non-destructive, and the description adds extensive behavioral context: source-specific fields returned (EDGAR, GLEIF, OpenFIGI, RxNorm), conditional parent/children ownership, graceful degradation if GLEIF/OpenFIGI is unavailable, and internal cascade behavior. No statement contradicts the 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 front-loaded with trigger examples and the 'Use FIRST' directive, and nearly every clause adds useful information. However, it is written as one dense run-on paragraph with heavy parentheticals and jargon ('cross-source identity spine'), so it is less skimmable than it could be.

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, yet the description explains what each type returns, includes edge cases (non-equity instruments, ISINs, non-US issuers), and notes fallback behavior when enrichment sources are unavailable. An agent has enough information to select the right type and value and anticipate 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?

Although the schema already describes both parameters (100% coverage), the description goes well beyond it with concrete examples, valid value formats, and an explicit warning to pass the entity name only rather than the full noun phrase, including the bond issuer edge case. This materially improves the agent's chance of forming a correct value.

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 concrete user phrasings and states the core action: resolve a user-spoken name to canonical/official identifiers required by other tools. It further differentiates by supported types (company/drug) and declares 'Use FIRST whenever you have a name but need an ID,' so an agent can recognize when this tool is the intended lookup.

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 gives an explicit trigger condition ('Use FIRST whenever you have a name but need an ID') and explains that one call replaces 2-3 manual lookups. It does not name specific alternative tools or state when NOT to use resolve_entity, so it stops short of full exclusion 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?

Description reveals internal behavior: probes each entity with ai_visibility_check, ranks by score, and describes output fields (score, confidence, signal density). This adds detail beyond annotations (readOnlyHint, idempotentHint, destructiveHint false). No contradiction.

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

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

Three sentences, front-loaded with main action. No fluff, every sentence provides essential information. Efficient and well-structured.

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 4 parameters, full schema descriptions, no output schema, the description explains output format and when to use. It references sibling tool 'ai_visibility_check' implicitly. Complete enough for an agent to select and invoke 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?

Description adds meaning beyond the schema: explains that first entity is treated as subject for narrative and rest as competitors, and clarifies usage of 'context' parameter to disambiguate. Schema already has 100% coverage, but description adds valuable 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?

Description clearly states the tool compares AI visibility across multiple entities side-by-side, with specific verb 'compare' and resource 'AI presence'. It distinguishes from sibling 'ai_visibility_check' by focusing on multiple entities and 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?

Explicitly says it's useful for competitive AI-marketing audits and gives an example question. Provides context on when to use, though does not explicitly list when not to use or name alternatives like 'ai_visibility_check' for single entity.

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

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

Annotations already indicate safe read-only operation. Description adds important behavioral details: partial failures, bundlephobia first measurement delay (5-30s), and sources_failed listing. No contradictions.

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

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

Three sentences, front-loaded with purpose and use cases, followed by edge cases and ecosystem scope. Efficient but slightly verbose in the middle 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?

No output schema, but description clearly describes return structure (summary block, advisories, links, alternative versions) and failure behavior. Comprehensive for a tool with good annotations.

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 covers both parameters fully (100% coverage). Description adds no additional semantic value beyond what the schema already provides for package and version.

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?

Clearly states it performs a composite npm package check using deps.dev and bundlephobia. Distinguishes from sibling tools, which are unrelated to dependency scanning.

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

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

Explicitly says when to use (questions about safety, popularity, size) and when not (non-NPM ecosystems, which are handled by other tools). Provides alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds critical behavioral details: client-side filtering, data fetched once, row counts and sizes, result capping. Fully transparent.

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?

Four sentences, front-loaded with purpose and key mechanics. No fluff; every sentence adds essential information.

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

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

Despite no output schema, description lists all returned fields (name, registration_number, address, registration_date). Annotations cover safety. All necessary context is present.

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% but description adds value: 'case-insensitive' for name, 'omit to return first page', explains the implication of status='terminated' (larger dump size). Provides concrete examples in schema as well.

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 'Search FARA registrants' and clearly explains what FARA registrants are. It implicitly differentiates from siblings by mentioning how registration_number connects to other tools like list_foreign_principals and get_registrant_documents.

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

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

Provides clear context: FARA has no server-side search, so client-side filtering is used; explains status='terminated' for larger dump. Lacks explicit when-not-to-use or direct alternative comparisons, but references sibling tools indirectly.

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

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

Adds significant context beyond annotations: embedding model (BGE-base-en), chunking (500-char overlapping windows), character cap (200K with truncation flag), and note that passages include offsets for verification.

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 paragraph, front-loaded with key action, every sentence adds value with no redundancy.

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

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

Despite no output schema, the description adequately covers return values (top-N passages, offsets, scores) and limitations, making it complete for a search 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 coverage is 100%, but description adds value with query examples and clarifies limit range (1-20, default 5), enhancing understanding beyond schema.

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

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

The description clearly defines the tool as semantic search inside a fetched record, specifying use case (record too large for prompt) and distinguishing from siblings by mentioning pairing with ask_pipeworx_grounded.

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 states when to use (record too large), provides pairing guidance with ask_pipeworx_grounded, but does not explicitly list when not to use, though context makes it clear.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds significant context: requires OAuth, details on type-specific parameters, delivery channel constraints (SMS cap, phone verification, webhook auto-disabled after failures), and the always-on feed behavior. No contradictions.

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 front-loaded with the core purpose, then efficiently covers requirements, types, and delivery in a well-organized manner. Every sentence adds value, and the length is justified by the tool's complexity.

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?

Without an output schema, the description only states 'Returns the new subscription id' but omits details about the full response structure, such as whether other fields like status or secret are included. For a creation tool, more detail on return value semantics would be expected.

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%, but the description enriches parameters with concrete examples (e.g., items:['5.02'] for sec_8k) and detailed constraints (webhook signing, verification requirements). This adds meaning beyond the 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 clearly states the tool creates a subscription to a live-data event stream and returns the subscription ID. It also details supported types and delivery channels, making the purpose very specific and distinguishable from sibling tools like unsubscribe or list_subscriptions.

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 includes prerequisites (OAuth account, phone verification) but does not explicitly instruct when to use this tool over alternatives. Usage is implied by naming and context, but there are no direct when-to-use or when-not-to-use statements comparing to 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?

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds that it returns live catalog examples with tool+argument shape, which is valuable behavioral context beyond the 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?

Front-loaded with common user phrase aliases, then structured explanation. Slightly long but every sentence adds value. Could be tighter but effective.

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 one-param tool with no output schema, description fully covers purpose, usage, return format, and relationship to siblings. No gaps remain.

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 covers the single optional parameter with description. Description adds meaning by listing valid focus area values, explaining that omitting gives full spread, and connecting topic to filtered output.

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?

Clearly states it's an onboarding tool that returns category-bucketed example questions. Specific verb and resource, distinguishes from sibling tools (e.g., ask_pipeworx) by positioning as the entry point.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and explains when to pass topic vs call with no arguments. Lacks explicit when-not-to-use, but context is clear.

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

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

The description adds behavioral context beyond annotations: ownership is enforced, the row is deactivated (not deleted), and historical events remain accessible via 'recent_alerts'. This complements the annotation hints (idempotent, non-destructive). No contradiction.

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

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

The description is two sentences long, front-loaded with the action, and contains no extraneous 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?

Given the tool's simplicity, one parameter, and no output schema, the description fully covers the purpose, behavior, ownership, deactivation, and post-cancellation data access. It is complete for a successful selection and 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?

The single parameter 'id' is fully documented in the schema (100% coverage). The description does not add additional semantic detail beyond referencing the id, but it reinforces that ownership applies. Baseline 3 is appropriate.

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

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

The description explicitly states 'Cancel a subscription by id' using a specific verb and resource, and distinguishes itself from sibling tools like 'subscribe' (create) and 'list_subscriptions' (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 specifies when to use the tool (to cancel a subscription) and notes ownership enforcement, implying you should only cancel your own subscriptions. It does not explicitly list alternatives but the context of sibling tools provides differentiation.

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?

Beyond the readOnly/idempotent annotations, the description discloses critical behavioral nuances: the distinction between could_not_verify and unsupported, the meaning of verification_error, the special handling of company-financial claims with exact percent-delta math, and the routing to live sources with verbatim evidence. This is valuable context an agent needs to interpret results correctly, especially that could_not_verify is not evidence for or against the claim.

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 long but every sentence earns its place: trigger phrases, routing logic, return values, caller warnings, and efficiency rationale. It is structured with a clear progression from examples to internal behavior to output semantics. No redundant fluff despite the complexity.

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 and absence of an output schema, the description fully compensates by explaining the verdict enum, citation format, reasoning, and the specific meaning of failure statuses. It also provides operational context (when to use, why it replaces sequential calls) and aligns with sibling differentiation. Complete enough for an agent to select and 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 100%; both parameters (claim and tolerance_pct) are already fully documented with examples, ranges, and defaults. The tool description mentions 'exact percent-delta math' but adds no essential meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly defines the tool as natural-language claim verification against authoritative sources, with a specific verb and resource. It distinguishes itself from sibling tools by detailing the two distinct internal paths (SEC EDGAR/XBRL fast path and grounded pipeline) and explicitly stating it replaces 4–6 sequential calls, making its composite purpose unambiguous.

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

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

Provides clear context: "Use whenever the agent needs to check whether something a user said is factually correct." It also implies the alternative of sequential manual calls ("Replaces 4–6 sequential calls") but does not explicitly state when not to use it or name a specific sibling alternative. Good but not perfect exclusion guidance.

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