Pipeworx

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description still adds real behavior: single fast call, works on every tier, routing across a large catalog, and the pack-scope fallback contract (unknown slugs reported in _meta.pack_scope.ignored, fallback to _meta.pack_scope.full_catalog:true, never an empty answer). That fallback disclosure is exactly the kind of non-obvious behavior an agent needs before relying on pack restriction.

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 the decision-critical claim ("PREFER OVER WEB SEARCH") and ordered from default use to escalation to the optional packs knob. There is mild redundancy — the example list and the "START HERE" sentence overlap with the routing claim, and the escalation guidance appears twice in compressed form.

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 routing tool with no output schema, the description covers entry conditions, alternatives, catalog scale, and the shape and provenance of the return value (structured answer plus citation URIs). Nothing material is left for the agent to infer.

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 alias set and packs semantics are already fully documented and the description mostly echoes them. It does add intent-level framing the schema lacks — packs means "answer this using THESE packs" and omitting it means full-catalog routing — which helps an agent decide whether to scope at all.

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?

States a specific action with concrete machinery: routes a natural-language question to one of 7,176 tools across 1863 sources, fills arguments, and returns a structured answer with stable pipeworx:// citation URIs. It explicitly differentiates itself from siblings by naming ask_pipeworx_grounded and deep_research and the conditions that select them, so an agent can pick without opening another schema.

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 when-to-use triggers ("what is", "look up", "get the latest", "how much", factual questions about real-world entities), an explicit preference over web search, and named alternatives with escalation conditions for grounded answers and multi-part fan-out. It also covers the breaking-news case, closing the most likely ambiguity.

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 the safety profile (readOnly, idempotent, non-destructive), but the description adds substantial context beyond them: the full success payload, the five refusal_reason values, the refusal_cause subcodes for llm_error, and the one-extra-LLM-call cost. It does not discuss latency, rate limits, or how partial truncation is detected, which keeps it out of the top band.

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 the core distinction and the use case, with return shape and refusal codes following in a logical order. It is dense but nearly every clause carries information; the parenthetical breakdown of refusal_cause values is the one section that could be tightened without losing selecting power.

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

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

There is no output schema, and the description compensates by specifying the exact success object and every refusal shape, including nested refusal_cause semantics. For a tool whose failure modes are the main selection risk, nothing an agent needs is missing.

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

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

Schema description coverage is 100%, so the required question field and its seven aliases are fully documented in the schema itself, and the baseline of 3 applies. The description adds routing context ('picks the right tool... fills arguments') that implies how the free-text question is consumed, but it never mentions prefer_tool or that it accepts tool names from alternatives[], which is the one non-obvious parameter here.

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?

States a specific verb+resource: grounded answer mode that routes to one of 7,176 tools, fetches data, and extracts the answer strictly from the tool result. It explicitly distinguishes itself from the sibling ask_pipeworx ('costs one extra LLM call... prefer ask_pipeworx for casual lookups'), so an agent can choose between them without opening a schema.

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 an explicit trigger ('use whenever an answer will be quoted, cited, or acted on') with concrete examples (financial verdicts, legal claims, medical lookups), plus an explicit when-not ('prefer ask_pipeworx for casual lookups'), and names the cost tradeoff that drives the decision.

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 only declare the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false). The description goes far beyond that, disclosing the never-substitute-latest guarantee, never-return-0, currency non-conversion, the YTD-minus-YTD derivation with `reported:false` and named derivation paths, per-share/balance-sheet non-derivation, and the full set of named non-answer statuses. This is exceptional behavioral disclosure.

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 key purpose and the 'prefer over' routing are front-loaded, and every sentence carries substantive information for a high-complexity tool. It is dense and long, but the density is largely earned by the derivation and status semantics; minor trimming is possible but nothing is filler.

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

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

There is no output schema, so the description carries the full burden — and it does: it enumerates return fields (us-gaap concept, measure, accession, sec.gov link, restatement trail, contract/derivation version), the derivation marker, and all named status outcomes. Nothing an agent needs to call or interpret the result is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description nevertheless adds conceptual meaning beyond the schema: the NetIncomeLoss-vs-ProfitLoss concept distinction, the dei cover-page basis and cover-date period for shares_outstanding, and mixed units (shares vs USD/shares). Some overlap with the schema's own attribute descriptions keeps it from a 5.

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?

States a precise verb+resource+scope: typed, deterministic financial facts for a US public company for an explicitly named reporting period, with concrete examples ('Apple revenue for fiscal 2023'). It explicitly differentiates itself from entity_profile and get_company_financials, so an agent can select it without opening any schema.

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?

Names the alternatives (entity_profile / get_company_financials) and the exact condition that selects this tool ('whenever the period matters'), then explains the failure mode of the alternatives (returning FY2025 for an FY2019 question, conflating discrete quarters with YTD). This is textbook when-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 declare read-only/idempotent/open-world/non-destructive, but the description adds substantial behavior beyond them: it refuses to guess and returns match_status 'ambiguous' with both candidates, exposes searched[] with per-register as-of dates and errors (unreachable register ≠ zero rows), and explains related[] collapsing. This is exactly the extra context the annotation bar rewards.

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 the core action and return value, then progressively details registers, ambiguity behavior, and exclusions in well-signposted blocks. It is dense and slightly repetitive (the register list and 'refuses to guess' theme recur), but length is largely 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?

With no output schema, the description carries the burden and discharges it: it describes return fields (searched[], related[], match_status), error semantics, scope (not a people search), and register coverage. An agent has everything needed to call and interpret this complex tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds decision-relevant meaning: it explains that a short name is often ambiguous and that passing country is 'frequently the difference between an answer and ambiguous', reinforcing schema semantics with usage guidance. It largely echoes the schema's name/limit detail, so it does not fully exceed the 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?

States a specific verb+resource ('Search the NATIONAL BUSINESS REGISTERS by company name') and the precise return artifact ('get the register's own id back — a Companies House number, ...'), with concrete examples of the identifier types. It also carves out its sibling explicitly ('For US public companies prefer resolve_entity'), so an agent can distinguish it from the nearest alternative without opening a schema.

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?

Explicit when-to-use ('when you want the OFFICIAL REGISTERED ENTITY and the country is not the US, or when you do not know which country it is'), explicit when-not (US public companies → resolve_entity, natural persons excluded), and explicit advice on passing country to avoid ambiguity. Alternatives and conditions are named, not inferred.

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?

Goes well beyond the readOnly/idempotent annotations by naming data provenance (SEC EDGAR/XBRL for companies, FAERS + FDA approvals + trial counts for drugs), disclosing the off-calendar fiscal-year handling, the sort order (primary metric descending so "largest" reads off the top), and the citation URIs returned. That is exactly the behavioral context annotations cannot express.

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 the natural-language triggers, then capability, then return shape — good ordering with no filler sentences. The trigger-phrase enumeration is long and slightly redundant across "vs"/"versus"/"versus X", costing a bit of density without adding 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, and the description compensates by describing the return: paired data sorted by the primary metric plus per-entity pipeworx citation URIs. Combined with the annotations and full schema coverage, an agent needs nothing else to invoke it correctly.

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

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

Schema coverage is already 100%, yet the description still adds meaning: it explains what type="company" retrieves (10-K revenue, operating income, net income, cash, long-term debt) versus type="drug" (adverse-event, approval, trial counts), and clarifies value formats (tickers/CIKs vs drug names). It does not add anything about the 2–5 boundary beyond what the schema's minItems/maxItems already state.

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?

States a specific verb and resource ("side-by-side comparison of 2–5 companies or drugs in ONE parallel call") and enumerates the query shapes it answers ("X vs Y", "which is bigger", "rank these companies"). It is clearly separable from siblings like entity_profile, company_facts and archive_compare, which are single-entity or archive-scoped.

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?

Explicit routing rule: "ALWAYS PREFER over sequential single-pack lookups when comparing entities," plus the cost argument "Replaces 8–15 sequential lookups." The agent is told both when to pick this tool and which pattern it supersedes.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: free-account requirement, paid-plan gating on depth:thorough, expected latency of 15-60s rising to ~90s for thorough, and the fact that it fans out across 7,176 tools in parallel. It also discloses failure semantics that matter operationally — gaps[] for unanswerable facets and mostly-empty gaps[] on non-catalog news topics — rather than inventing results. No conflict 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?

Front-loading is correct: the account gate and the ask_pipeworx fallback land in the first sentence, before any capability claims. It is dense and long — the depth/iteration explanation partially restates the depth parameter's own schema text — but nearly every sentence carries decision-relevant information, so the length is mostly earned.

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, so the description carries the return-value burden itself, and it does: a findings packet with verbatim evidence, confidence, source, fetched_at, a resolvable pipeworx:// citation_uri, a hop field, plus gaps[] and contradictions[]. For a fan-out tool with nine parameters and a paid tier, nothing an agent needs to call it correctly or interpret the result is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the depth tiers behaviorally (gap-recovery hop vs. lead-chasing hop, facet counts 3/6, contradictions[] only on standard and thorough) in terms an agent can weigh against its latency budget. The alias set is left entirely to the schema, which is the right division of labor.

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?

States a specific verb and resource — grounded multi-source research across 1863 structured data sources in one call — and explicitly negates the wrong reading with 'this is NOT open-web search'. It also names the exact sibling it is not (ask_pipeworx) and the conditions separating them, so an agent can discriminate it without opening any schema.

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 when-to-use ('broad/multi-part questions over structured data', with two concrete example questions), when-not ('for a single lookup use ask_pipeworx', 'for BREAKING or colloquial CURRENT-NEWS prefer ask_pipeworx'), and a prerequisite branch ('if you are not signed in, use ask_pipeworx'). Alternatives and exclusions are named outright rather than implied.

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, idempotent, non-destructive behavior; the description adds substantial value by disclosing the exact return shape: top-N relevant tools with names, descriptions, full input schemas and curated examples, and that results are ready to call without a second schema lookup. This is especially useful because no output schema is provided.

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

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

The description is front-loaded with the core purpose, followed by use cases, return value, and a clear first-step instruction. Each sentence earns its place, and the domain list is dense but directly relevant.

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 discovery tool with straightforward parameters, high schema coverage, and no output schema, the description fully compensates: it explains what the tool does, when to use it, and exactly what the response contains. Nothing materially needed by an agent is missing.

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

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

Schema coverage is 100%, and the schema already documents query, all aliases, and limit defaults/max. The description only restates that the input is a natural-language description of a data/task, adding no parameter-level 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 first sentence names a specific action and resource: 'Find tools by describing the data or task.' It also lists concrete domains and frames the tool as a discovery/meta tool, which distinguishes it from the many operational sibling tools and clarifies it is not itself a domain-specific search.

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 says when to use it ('Use when you need to browse, search, look up, or discover what tools exist') and instructs to call it FIRST when many tools are available. It does not name specific alternative tools or give explicit exclusions, though 'not just one answer' hints at when a direct tool is more appropriate.

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 cover the safety profile (readOnly/idempotent/openWorld/non-destructive), and the description adds substantial context beyond them: the three-state sources_used/sources_failed/sources_skipped model, the meaning of an empty section, the PatentsView soft-fail, and the deliberate Purple-Book skip. This is exactly the operational detail an agent needs.

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 useful use-case examples are front-loaded, but the body is a single enormous sentence with deeply nested parentheticals (the diluted-EPS cover-page aside, the fallback-tag aside, the Purple-Book aside). The density of genuinely relevant detail does not excuse the wall-of-text structure that makes it hard to scan.

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

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

With no output schema and a highly complex multi-source fan-out, the description carries the burden well: it enumerates every returned section, the per-source state tokens, and the name-resolution behaviour. An agent knows what to expect back and how to interpret partial 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 schema already documents type/value/country, and the description largely restates that (type interchangeability, accepted value shapes). It adds some real meaning — country 'only affects a NAME lookup' and the resolved:false path for private companies — but not enough to exceed the baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource — a 'full cross-source profile of a US public company in ONE parallel call' — and enumerates the exact data legs (SEC EDGAR, XBRL, USPTO, USAspending, etc.). It clearly distinguishes itself from siblings like company_facts, deep_research and resolve_entity by covering the holistic-view use case.

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 selection rule: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' with concrete trigger phrasing ("Tell me about X", "research Acme"). The alternative and the condition that selects it are both stated.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety and write profile are covered. The description aligns with those hints but adds little behavioral context beyond the use cases; it does not, for example, state whether deleting a missing key is an error or what the response looks like. With annotations carrying the main burden, a 3 is appropriate and there is 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?

Two sentences with no filler: the core action and key-based scoping come first, followed directly by usage guidance and sibling pairing. Every sentence earns its place.

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

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

For a simple deletion tool with a fully documented schema, explicit destructive/idempotent annotations, and no output schema obligations, the description covers what an agent needs: what it deletes, when to use it, and how it relates to remember and recall. Nothing critical is missing.

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

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

Schema description coverage is 100%, and the schema already explains that key, k, name, and label are aliases for the memory key. The description adds no parameter-level details, but since the schema fully documents the single meaningful parameter, it does not need to; baseline 3 is correct.

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

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

The description opens with a specific verb-resource pair: 'Delete a previously stored memory by key.' It clearly distinguishes the tool from its siblings remember and recall by naming them and positioning forget as the deletion counterpart, so an agent can select it correctly without opening the schema.

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 triggering conditions: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also names the complementary tools remember and recall, routing the agent to its siblings and making the when-to-use decision unambiguous.

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 this a safe, idempotent, read-only lookup (readOnlyHint, idempotentHint, destructiveHint=false). The description adds useful disclosure of the return content ('tool names, descriptions, parameters, and requirements'), but does not go beyond that with rate limits, caching, or failure behavior.

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

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

Three short sentences, front-loaded with purpose and then usage, with no filler. It is appropriately sized for a simple lookup tool, though the example duplication with the schema is slightly redundant.

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

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

For a one-parameter, read-only lookup with no output schema, the description covers what the tool returns and when to call it. An agent has enough to invoke it correctly; only the sibling routing detail is left implicit.

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% and there is a single well-documented 'slug' parameter with its own examples. The description's inline pack examples ('weather', 'polygon-io') largely duplicate what the schema already provides, so it adds no syntax or format meaning beyond the schema baseline.

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

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

The description uses a specific verb ('Get') and resource ('tool definitions for a specific pack') and grounds it with concrete examples ('weather', 'polygon-io'). It is clearly distinguishable from the resource itself, though it does not explicitly contrast itself with siblings like discover_tools or list_packs.

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 timing guidance: 'Use before calling a tool to verify its interface.' This tells the agent when the tool is valuable. However, it names no alternative and provides no exclusion conditions (e.g., when to prefer discover_tools instead).

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, so the safety profile is covered. The description adds real value by stating the return shape (pack names, categories, tool counts, gateway URLs), which no output schema provides, though it omits pagination or result-size behavior.

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

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

Three short sentences, front-loaded with the action and return payload, with no filler. Tight and readable.

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 carries the return-value burden and does so adequately for a read-only list tool with one optional filter. Only minor gaps remain around result volume and the natural next step into get_pack_tools.

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

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

Schema coverage is 100% and the schema itself explains the free-text category matching thoroughly (slugs, descriptions, tool names). The description adds nothing about the filter and even says "all available packs," mildly downplaying the optional category parameter. Baseline 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?

Clear verb+resource ("Browse all available Pipeworx packs") with the returned fields enumerated. However, it never distinguishes itself from the sibling search_packs, which appears to be the filtered/full-text variant, leaving an agent to guess which to call.

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?

"Use to discover data sources or explore what's available" implies a discovery use case but gives no when/when-not guidance and never names search_packs or get_pack_tools as the alternative for narrower or deeper queries.

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?

Goes far beyond the annotations: discloses the claim_token return-and-lookup flow, rate limit (5/day/identifier), cost (free, no quota), and operational facts (team reads digests daily, signal affects roadmap). Also instructs on content policy (describe in terms of Pipeworx tools, don't paste user prompts). 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?

Dense but every sentence earns its place: purpose is front-loaded, the critical exclusion comes early, then workflow, then operational constraints. The length is justified by the tool's nuance (claim tokens, rate limits, server-scoping) and there is zero filler.

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

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

Despite no output schema, the description fully covers what an agent needs: when to call, what to include, what to expect (claim_token), how to follow up later, and operational limits. No important behavioral aspect is left unexplained.

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 all parameters at 100%, giving baseline 3. The description adds real value beyond schema by explaining the claim_token round-trip workflow and the message content rule (mention specific tool/pack, avoid pasting user prompts). These clarify how to use the parameters correctly, lifting the score above 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?

Description opens with a clear verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It names the three content categories (bug, feature/data_gap, praise) and explicitly excludes tools from other MCP servers, so an agent can immediately distinguish this from any sibling or external 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?

Gives explicit when-to-use conditions (wrong/stale data, missing catalog entry, positive experience) and an explicit when-not-to-use with an alternative action: file with the other server instead. Also provides a disambiguation heuristic ('Pipeworx tool names are the ones this connection lists'). This is exemplary 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds genuine value by disclosing the dual behavior (retrieve vs. list-all-keys when omitting the argument) and the scoping to the agent's identifier (anonymous IP, BYO key hash, or account ID). 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 with zero waste: core action first, then usage context with examples, then scoping and sibling pairing. Every sentence earns its place, and the key behavioral distinction (omit key to list all) is front-loaded.

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 low-complexity read/list tool with annotations carrying the safety profile and a schema fully documenting the parameters, nothing an agent needs to call it correctly is missing. The dual behavior, scoping, and sibling relationship are all covered despite the absence of an output schema.

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 fully documents all four parameters (which are all aliases for the same key). The description's note about omitting the key to list all keys is mirrored in the schema, so it adds little beyond what structured data already provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Retrieve a value previously saved via remember, or list all saved keys') with concrete use examples (target ticker, address, research notes). It explicitly differentiates from siblings by naming remember (save) and forget (delete), so an agent can distinguish recall without inspecting other schemas.

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 clear context on when to use the tool ('look up context the agent stored earlier... without re-deriving it from scratch') and routes to alternatives ('Pair with remember to save, forget to delete'). It lacks an explicit when-not statement, but the scoping and sibling pairing make the intended usage unambiguous.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it fans out to multiple sources in parallel, has a GDELT→GNews fallback, notes the PatentsView API sunset causing soft-fail, and describes the return shape (changes[] grouped by source, total_changes, pipeworx:// citation URIs). It doesn't detail pagination or rate limits, but the disclosed behavior is substantial.

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 well-organized: example queries first, then the core function, then source details, then parameter formats, then return shape, then the sibling distinction. Every sentence adds information, though the source-fallback details make it slightly long. The front-loading of example queries is effective for an agent scanning for intent.

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 read-only, idempotent tool with 100% schema coverage and no output schema, the description covers the main things an agent needs: what it does, what inputs look like, what sources it hits, and when to use the sibling instead. It doesn't specify pagination or exact output field types, but the return shape is summarized and the annotations cover safety. A small gap is not explaining how 'changes' are structured beyond grouping by source, but this is acceptable given the tool's complexity.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds meaning by explaining the `since` accepted formats (ISO date or relative shorthand) and giving typical usage ('30d' or '1m'), plus clarifying that `value` can be a ticker or zero-padded CIK. This goes beyond the schema's descriptions and helps an agent construct valid calls.

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 natural-language queries ('What's new with X', 'latest on Y') and then states the exact function: a change feed for a company over a time window in one parallel call. It names the data sources (SEC EDGAR, GDELT→GNews, USPTO) and explicitly contrasts with entity_profile, so an agent can distinguish it from the closest sibling without opening schemas.

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 when-to-use guidance via example queries, specifies the `since` window formats, and states the alternative: 'Use entity_profile instead when you want the static profile... regardless of window.' It also discloses fallback behavior (GDELT preferred, GNews on rate-limit/5xx) and the USPTO soft-fail, which helps an agent decide whether this tool fits the task.

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 idempotentHint=true and destructiveHint=false, so the description adds useful extra context: memory is scoped by identifier, authenticated users get persistence, and anonymous sessions retain memory for 24 hours. 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 compact, front-loaded with the core purpose, and every sentence adds value: usage trigger, storage model, persistence behavior, and related tools. No filler.

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

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

Given the simple write-tool nature, the absence of an output schema is not a serious gap. The description covers what to store, when to store it, persistence limits, and sibling operations. A marginally stronger version would state return behavior or overwrite semantics.

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

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

Schema coverage is 100%, and the schema already documents the key/value aliases and examples. The description only restates the key-value concept without adding deeper semantics, so it meets but does not exceed the baseline for high schema coverage.

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

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

The description opens with a specific verb and resource: 'Save data the agent will need to reuse later.' It clearly differentiates itself from sibling tools by naming recall (retrieve) and forget (delete), so an agent can tell which operation to invoke.

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 when you discover something worth carrying forward...' and lists concrete examples. It does not state when not to use it, but the guidance is clear enough for most 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 establish read-only/idempotent/open-world, and the description layers genuine behavioral detail on top: graceful degradation when GLEIF/OpenFIGI fail (EDGAR IDs still return), ambiguity asserted via figi_candidates rather than a guess, unresolvable IDs surfaced under `unresolved`, and every identifier labelled by source.

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?

Information-dense but poorly structured: a long list of example questions precedes the actual purpose, and the middle is a run-on of deeply nested parenthetical asides. The content earns its keep, but it is not front-loaded and is far from tight.

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 3-param, no-output-schema tool, the description compensates by explaining return artifacts (`figi_candidates`, `unresolved`, source labels) and degradation behavior. An agent has everything needed to call it correctly and interpret the result.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds real meaning beyond the schema: it introduces ISIN as an accepted input and explains how an ISIN resolves to a legal entity via the GLEIF ISIN-to-LEI mapping. It largely echoes the schema's `country` and `value` guidance rather than extending 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?

States a specific verb+resource: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It also distinguishes itself from siblings with 'Use FIRST whenever you have a name but need an ID' and scopes the two supported entity types precisely.

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?

Explicit sequencing guidance ('Use FIRST whenever you have a name but need an ID') and a clear statement that it replaces 2-3 manual lookups. It never names a specific sibling alternative or states a when-not condition, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds that results include 'community and hosted servers,' which is useful result-type context, but gives no detail on pagination, ranking, or rate limits.

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 short sentences, front-loaded with the core action, followed by result scope and usage. Every sentence carries distinct information with no filler.

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

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

For a read-only search tool with full schema coverage and clarifying annotations, the description is nearly complete; it even discloses result composition. It stops short of explaining result ordering or how to page beyond the limit parameter, but nothing essential for invocation is missing.

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

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

Schema description coverage is 100%, so all three parameters (query, limit, category) are documented in the schema with defaults. The description's example queries ('database', 'email', 'calendar') and category hint add marginal color but no meaning beyond what the schema already provides.

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

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

States a specific verb (search) and resource (MCP servers/directory) with scope ('thousands of MCP servers by use case'). The clause 'Use to find tools beyond Pipeworx' distinguishes it from the Pipeworx-oriented siblings like ask_pipeworx and discover_tools.

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

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

'Use to find tools beyond Pipeworx' gives a clear context for selection, signaling it covers the external ecosystem rather than the local catalog. It lacks explicit when-not conditions or named alternatives, but the usage context is clear.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds real value beyond them: best-first ranking, what each result contains (matched terms, cost, auth, reliability), and the query-normalization rule that question filler and proper names are ignored.

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 the core action and fields, then returns, then usage. Efficient overall, though the parenthetical example list and the trailing filler-name caveat make it slightly longer than strictly needed.

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 carries the return-value burden and does so by naming matched terms, cost, auth, and reliability. Covers purpose, returns, and usage adequately; only alternative-routing detail is missing.

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

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

Schema coverage is 100%, so both parameters are already documented. The description restates the matching semantics (subject words match, proper names do not) but adds no syntax or format detail beyond what the schema already provides, so baseline 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?

States a specific verb (search) and resource (Pipeworx packs), names the searched fields (pack names, descriptions, tool descriptions), and shows concrete example queries. This clearly distinguishes it from list_packs and get_pack_tools.

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

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

Explicitly says 'Use to find which pack covers a capability before connecting to it,' giving a clear when-to-use context and a downstream action. It does not, however, name or exclude the plausible alternatives (list_packs, discover_tools, search_mcp_directory).

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap, truncation flagging, and character offsets for verification. This goes beyond the annotations and helps the agent predict output characteristics.

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 every sentence earns its place: it states the core function, the use case, the pairing with a sibling, the embedding/algorithm details, and the input cap. It is front-loaded with the most important information and has no filler.

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

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

For a read-only search tool with 100% schema coverage and no output schema, the description is complete. It explains the return characteristics (top-N passages, offsets, similarity scores), the algorithm, the size cap, and the truncation behavior. An agent has everything needed to decide when to call it and what to expect.

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 three parameters. The description adds context about the 200K char cap and the nature of the query, but it doesn't add much beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation 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 states a specific verb and resource: semantic search inside a fetched record, with a clear contrast to alternatives. It names the sibling ask_pipeworx_grounded and explains the pairing, so an agent can distinguish this tool from the broader ask_pipeworx family without opening schemas.

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 says when to use it: when the record is too big to fit in the prompt, and it names the alternative ask_pipeworx_grounded for grounding over relevant passages. It also gives a concrete workflow: fetch with the gateway, then search within. This is explicit usage guidance with an 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 declare readOnly, idempotent, openWorld, non-destructive. The description adds significant behavioral context: the distinction between 'could_not_verify' (check did not happen) and 'unsupported' (no source exists), the exact percent-delta math for financial claims, and the return structure. It even warns callers not to treat could_not_verify as evidence. This goes far 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 longer than ideal, but every sentence carries weight: trigger phrases, dual-path explanation, verdict list, error semantics, and the efficiency gain. It front-loads the purpose and trigger phrases, and the critical 'IMPORTANT for callers' note is placed prominently. Slight redundancy in the phrase list could be trimmed, but it's 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?

Given the tool's complexity (two pipelines, six verdicts, error handling), the description covers everything an agent needs: when to use, what happens under the hood, what it returns, and how to interpret ambiguous outcomes. It even explains why it replaces multiple sequential calls. No gaps for correct invocation.

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

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

Schema coverage is 100% for both parameters. The description adds value by explaining tolerance_pct's role in hallucination detection (set 1–2 for strict checking) and noting the default is implied by wording capped at 5. It also provides a concrete example of the claim parameter. This goes beyond the schema's bare 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 it performs natural-language claim verification with specific trigger phrases ('fact check', 'verify the claim that...'), and explicitly defines its scope: company-financial claims via SEC EDGAR/XBRL fast path, all other claims via grounded pipeline. It distinguishes itself from siblings by naming the exact function and output verdict types.

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 whenever the agent needs to check whether something a user said is factually correct.' It also explains the two routing paths (structured vs grounded) and mentions it replaces 4–6 sequential calls, making it clear this is the go-to tool for claim verification without ambiguity.

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