Arcgis Seattle

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 clear. The description adds valuable behavioral context: default model (Workers AI Llama-3.3-70b free), BYO key for Anthropic with payment responsibility, and return format per model. 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, each adding distinct value: main action, default/BYO model, return format and use cases. Front-loaded and no redundant statements.

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 explains the return structure (per-model {score, confidence, signals, raw_response} + combined view). It covers use cases and parameter overview adequately.

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 each parameter. The description echoes the schema details (default model for 'models', Anthropic key for '_apiKey') without adding substantial new semantics. 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 the action: 'Probe one or more LLMs for what they know about a business / brand / product / topic and score visibility (0-100) per model.' It distinguishes from sibling tools like 'deep_research' or 'ask_pipeworx' by specifying its focus on visibility scoring and AI-marketing audits.

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 good context: 'Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring.' It does not explicitly state when not to use or list alternatives, but the context is clear enough for an agent to decide.

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 (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) already carry the safety profile; the description adds genuine behavioral context beyond them: automatic dispatch across thousands of tools, automatic argument filling, and stable pipeworx:// citation URIs in the return. No contradiction with annotations. Does not disclose failure/latency behavior, but the annotation coverage lowers the bar.

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?

Strongly front-loaded ('PREFER OVER WEB SEARCH'), but the tail is visibly redundant: 'even if web search could also answer it', the full six-item examples list, and 'STERT HERE for most questions' are each repeated, adding a substantial chunk that earns no new information. Front-loading saves it from a 1, but the duplication is a real defect.

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 a single required parameter and rich annotations, the description covers when to use it, trigger phrasing, domains, mechanism, and return format (structured answer with citations) — nothing needed to invoke it correctly is missing. Gaps: no stated limitations and no routing rules among the ask_pipeworx family, which matters for a router 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%: the description documents the 'question' parameter and its five aliases (q, text, input, query, prompt) with clear semantics. The description's example queries ('What was Apple's revenue in 2024?') reinforce expected format but add little beyond the schema's own examples, so the 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 concrete function: routes a natural-language question to one of 5,710 tools across 1,494 verified sources, fills arguments, and returns a cited structured answer with pipeworx:// URIs. The domain list and six examples make scope unmistakable. Penalized to 4 because sibling variants (ask_pipewor_x_beta, ask_pipewor_x_grounded) are never mentioned, so an agent can't distinguish this flagshop from its neighbors.

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?

Extremely directive with explicit trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), explicit precedence over web search ('even if web search could also answer it'), and a 'STERT HERE' directive with concrete examples. Lacks exclusions or named alternatives (when to pick deep_research or ask_pipeworx_grounded instead), so it stops short of 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?

Goes well beyond the annotations by disclosing the current state (no candidate active, matches ask_pipeworx exactly), the fact that it is a full working router rather than a fallback, and that results are compared against the stable router to decide merges. This gives an agent an accurate mental model of live behavior.

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

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

The description is slightly longer than strictly needed, but it is structured well: it front-loads the identity and relationship to ask_pipeworx, then adds current status and usage guidance. Each sentence contributes meaningful information, though a few words could be trimmed.

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 a single conceptual parameter and no output schema, the description is complete enough. It explains the beta status, how to use it, what it does, and its relationship to the stable alternative. The only minor gap is that it assumes knowledge of ask_pipeworx, but that sibling is present in the context.

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% — every parameter is documented as an alias for 'question' with the core parameter fully described. The description adds no new parameter detail, but the baseline of 3 applies because the schema already carries the burden completely.

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

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

The description clearly identifies the tool as a beta version of ask_pipeworx, an identical universal router with the same 5,710 tools, arguments, and response shape. It specifically differentiates it from the stable sibling by calling out the experimental routing edge, so an agent can distinguish it 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?

Provides explicit usage direction: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also explains the experimental comparison role against the stable router. It could be stronger by explicitly saying 'use the stable version when you need reliability,' but the context is clear enough.

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, openWorldHint=true, idempotentHint=true, destructiveHint=false. Beyond these, the description discloses the full refusal contract with specific reason enums (not_in_source, no_tool_match, tool_error, data_truncated, llm_error), the evidence format (verbatim quote), and the extra LLM-call cost. This is rich behavioral context that the annotations do not provide, and it contradicts nothing.

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 clause earns its place: mechanism, success return shape, refusal shape, usage guidance, and cost tradeoff. Purpose is front-loaded in the first clause. It could be tightened slightly, but for a tool with this much behavioral nuance (refusal enums, evidence format, routing), the density is justified.

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 present, the description fully specifies return values on both success and refusal paths, covers when to use and when not to use it, names the sibling alternative, and discloses the cost. The 100%-covered input schema handles parameters. An agent has everything needed to decide, call, and interpret the result 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%, and the schema already documents the question parameter well ('Your question in natural language. Accepts query, q, prompt, text, input as aliases'). The description adds only the routing context ('fills arguments') and the cross-reference 'same routing as ask_pipeworx,' which is useful but not parameter-level detail. Baseline 3 is appropriate since the schema carries the 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?

Opens with 'Hallucination-resistant answer mode for high-stakes reads' — a specific behavioral promise ('answer only from fetched data') tied to a clear resource (Pipeworx's 5,710 tools across 1,494 sources). It differentiates itself from the sibling ask_pipeworx by name and by the extraction guarantee, so an agent can distinguish them 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?

Explicitly states when to use: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts,' with concrete domains (financial verdicts, legal claims, medical lookups, public statements). It also states when not to use: 'prefer ask_pipeworx for casual lookups,' naming the alternative and the cost tradeoff (one extra LLM call). Nothing is left to inference.

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 read-only, idempotent, open-world. Description adds extensive detail: fan-out patterns, response shapes, resolver contract, parent event extraction, news fallback, safety short-circuits, wide-spread handling, cancellation rule parsing. 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 very long (400+ words) and dense, but well-organized with sections and front-loaded core purpose. Length is justified by the tool's complexity but could be more concise.

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

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

Given 3 parameters and no output schema, the description covers all relevant behavior: inputs, classification, fan-out examples, response structure, edge cases, safety, resolution rules. No gaps remain 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?

Schema coverage is 100% with descriptions, but the tool description goes far beyond: explains how market accepts slug/URL/question, depth modes, include_raw use cases and size implications, and how inputs drive classification and fan-out.

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 tool researches a Polymarket bet by pulling Pipeworx data, accepts three input formats (slug, URL, question text), and returns an evidence packet plus comparison. Distinguishes from siblings by specifying use cases like 'should I bet on X'.

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 (e.g., 'should I bet on X') and provides context for edge cases (low-confidence matches, closed markets). Does not explicitly contrast with siblings but the use cases are 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 declare read-only, open-world, idempotent, non-destructive. Description adds data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), fiscal year handling, sorted results by primary metric, and citation URIs. 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?

Description is front-loaded with example queries and key instruction to prefer this over sequential lookups. Every sentence adds value, though slightly verbose; could trim some examples without loss.

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 2-param tool with no output schema, description covers purpose, exact data sources, sorting behavior, return format (paired data + URIs), and constraints (2-5 items). Sufficient for an agent to invoke correctly without 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% with enums. Description explains that type='company' retrieves specific financial fields and type='drug' retrieves adverse event counts, FDA approvals, trials. Also explains values array format with examples (tickers/CIKs for company, drug names). Adds significant 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 clearly states the tool compares 2-5 entities side-by-side, specifying two entity types and the exact metrics retrieved. It distinguishes from sibling tools like entity_profile by emphasizing parallel bulk comparison over sequential single-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?

Explicitly advises 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' Provides example user queries that trigger this tool and states it replaces 8-15 sequential lookups, making when-to-use and when-not-to-use 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?

Even though annotations already mark this as read-only, idempotent, and open-world, the description adds substantial behavioral context beyond those hints: account/paid-tier requirements, parallel routing to 5,710 tools, the findings-packet structure, explicit gaps[] for unanswered facets, contradictions[] scanning, semantic excerpting behavior, citation_uri fetchability guarantees, and expected latency. This fully discloses what the agent should expect when calling the tool.

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

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

The description is long, but nearly every sentence provides decision-relevant information and the most critical constraints (account requirement, alternative tool, not open-web) are front-loaded. The prose is dense and somewhat run-on, and there is a minor textual artifact ('and ... deep_research') that slightly harms readability, but the structure is organized around action, scope, results, and limits rather than 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?

There is no output schema, so the description carries the full burden of explaining return behavior. It covers the findings packet fields, evidence confidence, sources, fetched_at timestamps, pipeworx:// citations, gaps[], contradictions[], hop metadata, large-record excerpting, timing expectations, and auth prerequisites. An agent has everything needed to decide to call this tool and interpret its result 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?

Input schema coverage is 100%, so the schema already documents both parameters thoroughly. The description adds value beyond the schema by linking depth values to concrete behavior (quick=3 facets single hop, standard=3 with gap-recovery, thorough=6 with iterative lead-chasing), by noting the paid-plan restriction for 'thorough', and by clarifying that the question parameter is intended for broad/multi-part natural-language questions. This exceeds the baseline but is not exceptional because the schema already carries most of 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 description clearly identifies a specific action ('Grounded multi-source research'), a concrete resource ('Pipeworx's 1494 STRUCTURED data sources'), and an explicit differentiator ('this is NOT open-web search'). It also distinguishes itself from ask_pipeworx by positioning deep_research for broad/multi-part structured-data questions, so an agent can accurately select it among 31 siblings.

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 ('Best for broad/multi-part questions over structured data'), explicit when-not-to-use guidance ('For a single lookup use ask_pipeworx'), and even a prerequisite-based alternative ('If you are not signed in, use ask_pipeworx instead'). It also explains which depth levels resolve multi-step questions, making the selection criteria 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?

Description adds behavioral context beyond annotations: it returns top-N tools with full schemas and curated examples, ready to call. Aligns with readOnlyHint, idempotentHint, destructiveHint annotations, 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?

Single paragraph, front-loaded with purpose, followed by use cases and output description. Every sentence adds value, 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, but description fully explains what is returned (top-N tools with names, descriptions, full schemas, curated examples). 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 description coverage is 100%, so baseline is 3. Description adds value by listing aliases for the query parameter and noting limit default/max, plus providing examples.

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 finds tools based on a description of data or task, lists numerous specific domains, and distinguishes itself by advising to call it first when many tools are available.

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 'Use when you need to browse, search, look up, or discover what tools exist for:' followed by domains, and ends with 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Provides clear guidance on when to 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 read-only, open-world, idempotent, non-destructive. Description adds valuable context: fans across multiple sources, returns specific fields, patents soft-fails until May 2025. 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 verbose but well-structured with examples, capabilities, return fields, and constraints. Every part adds necessary context, though it could be trimmed slightly without losing meaning.

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

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

Given no output schema, the description thoroughly details return content (CIK, filings with URIs, fundamentals sorted, patents, news, LEI). It also notes limitations (patents sunset, name unsupported). Complete for agent decision-making.

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 reinforces input formats (ticker/CIK) and explicitly states unsupported inputs (names), adding value 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 provides a full cross-source profile of a US public company, with numerous example queries. It distinguishes itself from siblings like resolve_entity by specifying when to use this tool and when to use alternatives.

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

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

Explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Also specifies input requirements (ticker or CIK, not names) and advises to use resolve_entity first for names.

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 provide destructiveHint=true and readOnlyHint=false. The description adds 'Delete' which matches but does not provide additional behavioral context beyond what annotations convey.

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 very concise with only two sentences. The first sentence clearly states the action, and the second provides usage guidance. 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?

For a simple tool with one parameter and no output schema, the description covers purpose and usage adequately. It could mention idempotency but annotation already covers that.

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 description does not add extra meaning to the 'key' parameter beyond what is in 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 'Delete a previously stored memory by key', which is a specific verb and resource. It distinguishes from sibling tools like 'remember' and 'recall' by using 'delete' rather than 'store' or 'retrieve'.

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: 'when context is stale, the task is done, or you want to clear sensitive data...' It also suggests pairing with 'remember' and 'recall', but does not mention when not to use or alternative tools.

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

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

Annotations already indicate it's read-only and idempotent. The description adds useful behavioral context: fetching the page, extracting key elements, and emitting standard markdown format.

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?

Description is concise (single paragraph ~60 words) and well-structured: action, method, output, use cases. 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?

The tool's complexity is low; the description covers purpose, mechanism, output, and usage contexts fully. No output schema needed.

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

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

Schema coverage is 100%, so the description adds minimal value beyond what the schema already provides. The mention of 'max links' is already in 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 generates llms.txt files for URLs, specifies the output format, and lists concrete use cases that distinguish it from sibling tools like ai_visibility_check.

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 scenarios for using the tool (client sites, own projects, competitor auditing) but does not mention when not to use it or list 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 indicate readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds value by detailing the specific output (fields, geometry, count, capabilities), complementing the annotations 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?

The description is a single, well-structured sentence that conveys the necessary information efficiently. Every part is useful 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?

For a simple tool with one parameter and robust annotations, the description covers all essential aspects (input, output, behavior). No gaps are 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?

The single parameter 'url' has 100% schema coverage, so the description adds minimal extra semantics. The example URL format is helpful but not critical; baseline 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 the action ('Get'), the resource ('ArcGIS Feature/Map Service layer's schema'), and specifics like fields, geometry type, record count, and capabilities. It distinguishes the tool from siblings like query_layer by focusing on schema rather than data.

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

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

The description only explains what the tool does, with no guidance on when to use it versus alternatives (e.g., query_layer, search_datasets). No exclusions or contextual triggers are provided.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description does not contradict them. It adds behavioral context by specifying it returns active subscriptions (with optional inactive inclusion) and lists returned fields, which is useful 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-loaded with core functionality and return fields, then usage guidance. Every sentence adds value with 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 the simple parameter set and no output schema, the description is complete. It explains the purpose, return fields, and usage context, leaving no gaps for an agent to misinterpret.

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 only parameter 'include_inactive' having a description. The tool description does not add any additional meaning to this parameter beyond what the schema provides, so a baseline score 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 the tool lists the caller's active subscriptions, specifying the verb 'list' and resource 'subscriptions'. It distinguishes 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 use cases: 'review what you're monitoring before adding more' and 'find an id to cancel'. This guides the agent when to use it, though it does not explicitly exclude other scenarios or contrast with 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 are all false, so the description carries the full behavioral burden. It discloses the claim_token return flow, the polling workflow with claim_token, rate limiting (5 per identifier per day), quota exemption, digest cadence, and a data-privacy instruction (don't paste end-user prompts). 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?

Despite being a single long paragraph, it is front-loaded with purpose and every sentence earns its place: usage cases, exclusion, claim_token mechanics, rate limit, quota, and digest cadence. No repetition or filler; dense but organized.

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 explains what filing returns (a claim_token) and what polling with that token returns (status and changes once resolved). Combined with the detailed parameter schema and explicit usage exclusions, the tool is fully understood for both main interaction modes.

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?

Input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the claim_token round-trip workflow (pass it back to read results) and instructing users to describe issues in terms of Pipeworx tools/packs, which enriches the messaging semantics beyond the schema's plain field 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 opens with 'Tell the Pipeworx team something is broken, missing, or needs to exist,' which precisely states the action (send feedback) and the resource (Pipeworx team). It clearly distinguishes this from sibling tools by framing it as a feedback channel rather than a data retrieval or research 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?

It explicitly enumerates when to use the tool (bug, feature/data_gap, praise) and provides a hard exclusion: ONLY for tools served by this Pipeworx connection, with instructions to file elsewhere for other MCP servers. It even offers a disambiguation rule for identifying Pipeworx tools, making alternatives and boundaries 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 indicate read-only and idempotent. Description adds value by explaining data source (CF analytics-engine), no PII, and caching behavior (5min-1h). 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 concise sentences plus a bulleted list of use cases. Every sentence adds value: purpose, use cases, data origin, caching. Front-loaded with core action.

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

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

For a simple trending tool, description covers all needed context: output structure, data freshness, privacy, and use cases. No output schema required given clear textual explanation.

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 parameter fully with description. Description goes beyond by explaining trade-offs: shorter windows for 'hot right now', longer for 'steady-state demand'. Adds strategic nuance.

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 returns top tools, packs, and call volume over a window. Verb 'returns' and specific resource 'trending' make purpose unambiguous. Differentiates from siblings like 'discover_tools' by focusing on trending/recent usage.

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 three explicit use cases (discovering hot data sources, confirming canonical tools, aligning use case). Lacks explicit when-not-to-use or alternative tools, but context is highly 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 (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are consistent. The description adds rich behavioral details: monotonicity checks, partition filter, semantic anchor (Jaccard similarity), fill check with book depth, and conditions for avoiding trades. 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 lengthy but well-structured with clear sections. It front-loads the core purpose. Could be slightly more concise, but every sentence adds value and is organized logically.

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 of arbitrage detection and no output schema, the description fully covers inputs, processing logic (monotonicity, partition check, fill check), and response format. It also addresses edge cases like low similarity and placeholder filters.

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?

Both parameters (event, topic) have descriptions in the schema, but the description goes further with examples, recommended usage, and explanation of behavior in each mode. It adds semantic value 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 on Polymarket via monotonicity violations and partition-sum checks. It distinguishes between modes (no args, event, topic) and specifies the resource (Polymarket markets). It differentiates from siblings like polymarket_fill_risk by explicitly referring to it for custom sizing.

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 on when to use each mode: no args for trending scan, event for a specific market (recommended), topic for cross-event scanning. It also states when not to trade (realizable_edge_pp <= 0) and refers to polymarket_fill_risk for custom sizing.

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 and idempotentHint=true, but the description goes far beyond by detailing internal model families, caching behavior (1h at KV level), diagnostics fields, and tradeable-edge 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 very long but well-structured, starting with the purpose, then listing model families, opportunity fields, response structure, and caching. While front-loaded and information-dense, it could be more concise; the verbosity slightly detracts from 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?

Given the complexity (9 parameters, no output schema), the description thoroughly covers expected behavior: output segments, diagnostics for empty segments, field descriptions (edge_pp_net, kelly_fraction, etc.), caching, and parameter interactions. No gaps remain 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?

All parameters are described in the schema (100% coverage), and the description adds meaningful context beyond schema descriptions—e.g., slippage_pp explains zero fees but bid/ask impact, min_partition_leg_kelly clarifies why min_kelly doesn't apply to partitions, and max_spread_pp is explicitly labeled as a tradeable-edge filter.

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 a specific verb (scan, return) and resource (Polymarket markets), distinguishing it from sibling tools like polymarket_arbitrage or polymarket_edge_tracker.

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 it is 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets,' providing clear context for use. It explains three opportunity segments and tradeable-edge knobs, though it does not explicitly list alternatives or when not to use it.

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

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

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description reveals behavioral traits: it returns tracked, expired, and snapshot_dates; explains decay computation from daily closes; and notes limits such as the 60-day snapshot TTL and data gaps due to cache misses. This adds meaningful context.

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

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

The description is moderately concise for the amount of information. It front-loads the core concept, then lists arguments, response structure, and limitations in a logical order. Every sentence adds value, though it could be slightly tighter.

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 lacking an output schema, the description thoroughly explains all return fields (tracked, expired, snapshot_dates) and their sub-fields (e.g., first_seen, trend, decay_pp_per_day, lifespan_days). It also covers limits and data generation specifics, making it 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?

With 100% schema coverage, the baseline is 3. The description repeats parameter names, defaults, and constraints (e.g., max 30 days), but does not significantly add new semantics beyond what the schema already provides. The explanation of 'window' values is already in 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: analyzing edge persistence and decay from daily snapshots. It specifically answers the question of how long an edge has existed and whether it is shrinking, which distinguishes it from sibling tools like polymarket_edges that provide raw edge data without temporal analysis.

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

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

The description implies usage by contrasting fresh wide edges with older ones, suggesting when to use this tool (when temporal context matters). However, it does not explicitly state when not to use it or name alternative tools, 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 declare readOnlyHint, openWorldHint, idempotentHint as true, and destructiveHint as false. The description adds significant behavioral context: walks the ladder, returns fields like slippage, shares_filled, verdict, thin_legs, forced_directional_risk, and explains clamping of size_usd. 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 fairly long but every sentence provides necessary information. It is front-loaded with the main purpose and then details. Could be slightly more concise, but given the complexity of the tool, it is well-structured 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?

No output schema is provided, so the description must explain return values. It lists all return fields for both modes (top_of_book, vwap_fill_price, slippage_pp, etc. for single-market; theoretical_sum, realizable_sum, capture_ratio, etc. for basket) and explains critical implications like thin_legs and forced_directional_risk. 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 coverage is 100%, so baseline is 3. The description adds meaning by explaining how size_usd is interpreted differently for single-market vs basket, and the auto default for side in basket mode. This goes 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 it checks 'realizable-vs-theoretical edge against live CLOB order-book depth' and distinguishes between single-market and basket modes with specific details. It uses specific verbs and resources, and the purpose is distinct from sibling tools 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?

Explicitly tells when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. Also explains why (theoretical overround not capturable, partial fills lead to directional risk), providing clear alternatives and 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 already indicate a safe read-only, idempotent operation, and the description goes far beyond that by detailing compatibility codes, pairing exclusions for unknown metric types, skipped counters, temporal alignment, and per-entry flags. There is no contradiction between the description and 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 and well-organized with labeled sections, and nearly every sentence adds necessary operational detail. It is longer than typical tool descriptions, but the lack of an output schema justifies the thoroughness; it could be slightly more skimmable.

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 full burden of explaining what the tool returns and it does so thoroughly: leg-by-leg prices, top_spreads_pp, compatibility_warning/codes, skipped counters, and temporal_alignment. An agent has enough information to call the tool in either mode and interpret the results correctly.

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

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

The schema already documents all three parameters with 100% coverage, but the description adds real value by listing the exact topic shortcut values and explaining how kalshi_event_ticker and polymarket_event_slug override the topic-mapped side. It also ties parameters to the response fields they affect.

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 very specific purpose: computing the cross-venue spread between Kalshi and Polymarket for the same resolving question. It clearly distinguishes this tool from the other polymarket_* siblings by the two-venue pairing and by naming its two modes: pre-mapped topic shortcuts and explicit ticker/slug pairings.

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 usage context for both modes and warns that most pre-mapped topics currently return compatibility_warning, with 'pre-mapped ≠ tradeable'. It does not explicitly compare against sibling tools like polymarket_arbitrage or polymarket_edges, but it gives enough context for choosing topic vs explicit pairing.

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, openWorld, idempotent, and not destructive. The description adds that the tool returns attribute rows and geometry, and explains the SQL-like where clause behavior, including pagination via limit and offset. This goes beyond annotations to clarify operational details and data returned.

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

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

The description is extremely concise: two sentences that front-load the purpose and then succinctly list parameters. Every sentence adds value, with no redundancy or filler. The sample usage is efficiently integrated.

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

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

For a tool with no output schema, the description adequately covers the return type (attribute rows and geometry), key parameters, and source. It mentions the URL comes from search_datasets. It might benefit from noting default limit behavior, but the schema provides that detail. Overall, it is complete enough for an AI agent to understand 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 coverage is 100%, so baseline is 3. The description adds meaningful context: it describes the SQL-like nature of the where clause, the formatting of out_fields and order_by, and provides a concrete example of how to sample data. This enhances understanding beyond the schema's property 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 queries an ArcGIS Feature Service or Map Service layer by URL, specifying parameters like SQL-like where, out_fields, order_by, limit, offset. It distinguishes itself by referencing 'from search_datasets', linking to a related tool. The verb 'Query' and resource description are specific and unambiguous.

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

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

The description provides clear context that the tool is used for querying a layer from an ArcGIS service, with a sample usage. However, it does not explicitly state when to use this tool versus alternatives like layer_info or search_within, nor does it provide exclusions. The recommendation to use where='1=1' and out_fields='*' for sampling is helpful but not a full usage guide.

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 adds useful context beyond annotations (listing all keys, scoping), but does not cover failure modes for missing keys.

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 concise, well-structured sentences that front-load the main action and avoid superfluous content.

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

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

Covers both retrieval and listing use cases, pairing with siblings, and scoping—complete for a simple retrieval 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 covers the single parameter fully; description repeats the omit-to-list-all behavior, adding little extra 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 clearly states the tool retrieves a value by key or lists all keys when omitted, uses specific verbs and distinguishes from siblings like 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 mentions pairing with remember and forget, explains scoping to identifier, and provides clear context for when to use this tool.

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=true, but description describes mark_read as flagging events read, which modifies state. Also idempotentHint=true is contradicted because mark_read changes results on subsequent calls. The description adds some behavioral details (polling, feed location) but the contradictions severely undermine trust.

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?

Description is 3-4 sentences, front-loaded with the primary action, and every sentence adds value. No unnecessary words or repetition of schema fields.

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?

Covers what is returned (source, citation_uri, payload), all parameters with examples, and mentions an alternative endpoint. Without an output schema, it provides enough for an agent to use correctly, though it could include default limit value (already in 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 coverage is 100%, and description adds concrete examples (e.g., filter by type 'sec_8k'), clarifies the meaning of 'since' as ISO timestamp, and explains the side effect of mark_read. This goes beyond the schema's brief 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?

Clearly states the tool pulls fired events from a subscription feed and returns recent alerts with specific fields (source, citation_uri, raw event payload). It explicitly describes filtering by type and since, and distinguishes itself implicitly from sibling tools by focusing on the persisted alert feed.

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: polls work fine and mentions an alternative HTTP endpoint for scripts/dashboards. Does not explicitly state when not to use this tool or provide exclusions, but covers typical use cases well.

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 annotations (readOnlyHint, idempotentHint, destructiveHint), the description details parallel fan-out to multiple sources, GDELT→GNews fallback, soft-failure for USPTO, and return structure changes[] grouped 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 all sentences earn their place. Front-loaded with example queries, covers fallbacks, limitations, and alternatives. No redundancy or waste.

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 adequately describes return structure (changes[], total_changes, citation URIs). All parameters detailed, source behavior and limitations covered, alternative tool mentioned.

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, and description adds value: explains `since` format (ISO date/relative shorthand), `value` (ticker or CIK), and notes `type` only supports 'company'. Provides example recommendations.

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

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

The description clearly states the tool provides a change feed for a company over a time window, fanning out to SEC, news, and patents. It provides query examples and distinguishes from entity_profile which is for static profiles.

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 tells when to use this tool versus entity_profile, provides typical query examples, and gives parameter guidance (e.g., 'Use "30d" or "1m" for typical monitoring'). Also notes limitations like PatentsView API sunset.

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 annotations (idempotentHint=true, destructiveHint=false), the description adds valuable context: memory scoping by identifier, persistence details (authenticated users get persistent memory; anonymous sessions retain for 24 hours). 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 efficiently convey purpose, usage, and behavior. Some slight redundancy (e.g., 'across this conversation or across sessions') but overall concise.

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

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

Given simple parameters, no output schema, and no nested objects, the description fully covers behavior, persistence, and use cases, making it complete.

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

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

Schema coverage is 100% with clear descriptions for key and value. The description adds usage examples but does not significantly enhance parameter 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 explicitly states 'Save data the agent will need to reuse later' and clearly distinguishes from sibling tools 'recall' and 'forget' by mentioning them as companions.

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 on when to use ('when you discover something worth carrying forward') and mentions alternatives ('Pair with recall to retrieve later, forget to delete').

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, and destructiveHint as false/true. The description adds significant behavioral context: graceful degradation (if GLEIF/OpenFIGI unavailable, EDGAR identifiers still return), cascading internal lookups, explicit labeling of sources, and declaration of unresolved identifiers. This goes well beyond the annotations and provides critical behavioral insight for an AI agent.

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 informative but quite lengthy, with multiple example queries and detailed explanations of enrichment behavior. It is front-loaded with usage examples ('What's the ticker for…'), which helps an agent quickly grasp the scope. However, it could be slightly more concise by grouping less critical details (e.g., the full explanation of identifier sources) into a shorter summary, earning a 4 rather than a 5.

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 that there is no output schema, the description does an excellent job of explaining what the tool returns: canonical/official identifiers (CIK, ticker, LEI, FIGI, RxCUI), with source labels and an explicit list of unresolved identifiers. It also covers edge cases like graceful degradation. The only minor gap is not specifying the exact output format (e.g., JSON structure), but the description is still sufficiently complete for an AI agent to infer the behavior.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: for 'value', it clarifies that company input can be a ticker, CIK, or name, and that an ISIN resolves to the legal entity via GLEIF mapping. For 'type', it expands on what each type returns (cross-source identifiers, drug with RxCUI + ingredient + brand). This additional detail justifies a score of 4, though it could be more precise about exact accepted formats.

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 ('resolve') and clearly defines the resource: converting user-spoken names (ticker, CIK, ISIN, company name, drug names) into canonical/official identifiers. It provides multiple query examples and explicitly distinguishes the two supported types ('company' and 'drug'), making the purpose unambiguous. The description also differentiates this tool from sibling tools like 'compare_entities' or 'entity_profile' by emphasizing ID resolution as its core function.

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: 'Use FIRST whenever you have a name but need an ID.' It also explains that the tool replaces multiple manual lookups, reinforcing its primary use case. It does not explicitly state when NOT to use it or list alternative tools, but the context (sibling tools) and the clarity of the purpose make the usage boundaries fairly clear. Some mention of exclusions (e.g., if an ID is already known) would push it to 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 read-only, idempotent, non-destructive. Description adds that it probes each entity with ai_visibility_check, ranks by score, and returns list with score, confidence, signal density. 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: action, mechanism, use case + output. No wasted words, 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 4 params with full schema coverage, rich annotations, and no output schema, the description sufficiently explains what it does, how it works, and what it returns. Complete for agent usage.

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

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

Schema covers 100% parameters with descriptions. Description adds that first entity is 'subject' for narrative, entities must be 2-8, models default to workers-ai, and _apiKey needed for anthropic. Valuable context 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 states the tool compares AI visibility across multiple entities, uses ai_visibility_check for probing, and ranks results. It distinguishes from sibling ai_visibility_check which likely handles single entities.

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 case ('competitive AI-marketing audits') with example question. Does not explicitly state when not to use, but context implies multi-entity comparison. Could mention alternatives more directly.

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?

Discloses important behavioral traits beyond annotations: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, and sources_failed field lists failures. 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?

Concise yet comprehensive; front-loaded with purpose, then usage, scope, and behavior. Every sentence earns its place with 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?

Despite no output schema, the description fully explains the return value structure (summary block, advisory details, links, alternative versions), covering all necessary information for a composite 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 the description adds value by noting scoped packages are accepted and that version defaults to latest, clarifying usage 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 is a composite check for evaluating npm packages, distinguishing it from sibling tools like scan_competitor_ai_presence or direct deps.dev queries.

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 an agent asks...' and specifies scope (NPM only) with alternatives for other ecosystems, providing 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 declare readOnlyHint and idempotentHint; description adds specific output fields and data source (City of Seattle GIS), confirming safe read behavior 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?

Two tight sentences: first states purpose and scope, second details return fields and actionable guidance. No extraneous words, front-loaded with key information.

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

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

Given 3 well-documented parameters, no output schema, and comprehensive annotations, the description sufficiently covers what the tool does, returns, and how to use the output. Missing details like pagination or field types are minor given schema examples.

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 parameter descriptions. The description adds context about default org and suggests downstream tool usage, which aids agent understanding beyond 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 uses specific verb 'search' and resource 'City of Seattle GIS open geospatial datasets', lists return fields, and distinguishes from sibling tools 'query_layer' and 'layer_info' by mentioning passing the url to them.

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 downstream usage guidance (pass url to query_layer/layer_info) and implies default org, but does not explicitly state when not to use or contrast with other search tool siblings like 'search_within' or 'deep_research'.

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 reveals behavioral traits beyond annotations: embedding model (BGE-base-en), window size (500-char overlapping), cosine similarity, character cap (200K) with truncation flag, and offset inclusion for verification. This adds substantial transparency.

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

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

The description is a single, well-structured paragraph that front-loads purpose and action. Every sentence serves a purpose: explaining usage, technical details, and pairing. No superfluous 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, the description explains return values (passages with offsets and similarity scores). It covers technical constraints, pairing with sibling tools, and ideal use cases. Completeness is high for a 3-parameter tool with rich 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 description coverage is 100%, so baseline is 3. The description adds value with examples for query parameter and clarifies the truncation for text. This provides meaningful context beyond schema definitions.

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

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

The description clearly states the tool performs semantic search inside a fetched record, specifies the resource (e.g., SEC 10-K, article), and distinguishes it from siblings like ask_pipeworx_grounded. The verb 'search within' and resource are explicit.

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 using this tool when the record is too large for the prompt, saving context. It pairs with ask_pipeworx_grounded, providing an alternative workflow. While no direct 'when not to use' is given, 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?

The description discloses behavioral traits beyond annotations, such as the 10 SMS/day cap, webhook auto-disable after 10 failures, and the need to verify phone. 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 somewhat lengthy but all sentences are informative and contribute value. The main purpose is front-loaded. A slight trim could be made, but overall it is 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?

The description is extremely comprehensive: explains subscription types, parameters, delivery channels with constraints, prerequisites, and edge cases (webhook auto-disable). No output schema exists, but the description covers return behavior.

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

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

Schema coverage is 100%, and the description adds substantial meaning: examples for each type, detailed delivery channel constraints, phone verification, and webhook signing. This far exceeds 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's purpose: 'Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id.' This is specific and distinguishes it from siblings like 'list_subscriptions' and 'unsubscribe'.

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 prerequisites (requires Pipeworx OAuth account) and lists supported types with examples. It does not explicitly state when not to use, but the context is clear enough.

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, and destructiveHint=false. The description adds valuable context: the tool returns category-bucketed example questions with exact tool+argument shape drawn from a live catalog, which is 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 fairly concise and front-loaded with trigger phrases ('What can I ask?'). It packs essential info but could be slightly more streamlined.

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 annotations and simple schema, the description is comprehensive. It explains the return type (category-bucketed example questions with tool+arg shape), when to use, and how to use the parameter. No output schema needed as description covers expected output.

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 the single optional parameter. The description adds context about omitting it for a full spread and lists the topic values, supplementing the schema's description.

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

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

The description clearly states the tool's purpose: answering 'what can I ask?' and returning category-bucketed example questions with tool+argument shapes. It distinguishes itself from sibling tools by being the onboarding entry point for learning Pipeworx capabilities.

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, or to learn how to call the meta-tools.' Provides clear context for when to use and implies alternatives (other tools for specific tasks).

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

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

Adds critical info beyond annotations: deactivation not deletion, historical availability via recent_alerts, and ownership enforcement.

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

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

Two sentences, front-loaded with purpose, then constraints and effects. 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?

Fully explains behavior, side effects, and ownership for a single-parameter tool. No gaps despite no 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 coverage is 100% and description merely restates the schema's parameter description. No additional semantic 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?

Uses specific verb 'Cancel' and resource 'subscription by id'. Clearly distinguishes from siblings like subscribe and 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?

States ownership enforcement and deactivation behavior. Could mention when not to use, but provides strong 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?

The description discloses rich behavioral context beyond the annotations: the dual-path routing (SEC/EDGAR vs. grounded pipeline), the verdict enumeration, the critical caveat that could_not_verify is not evidence, the meaning of unsupported, and the return format with citations. This aligns with and complements the annotations (readOnly, openWorld, idempotent, non-destructive) 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?

The description is dense but every sentence earns its place: trigger phrases, routing specifics, verdict semantics, error handling, and performance benefits. It is front-loaded with examples and structured logically from usage to return values to caveats, with no filler or 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 fully explains return values (verdict, actual value with citation, reasoning), handles edge cases (could_not_verify, unsupported), and describes the internal decision path. Given the tool's complexity, this is complete and self-contained for an agent to 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the percent-delta math ('exact percent-delta math') and referring to tolerance implied by claim wording, which contextualizes the tolerance_pct parameter and its default behavior. It doesn't repeat schema details but enhances understanding of how parameters interact.

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+resource ('natural-language claim verification against authoritative sources') and provides trigger phrases, making the tool's purpose unmistakable. It clearly differentiates from sibling tools by positioning itself as a consolidated verification tool that 'replaces 4–6 sequential calls', which is a distinct role among the listed alternatives.

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

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

It gives explicit usage guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the routing logic for financial vs. other claims. While it doesn't name specific sibling tools to avoid or explicit exclusions, the broad 'any other factual claim' phrasing covers all use cases, and the consolidation note implies alternatives are less efficient.

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