Nba

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds critical behavioral details: default model (Workers AI), optional Anthropic key with 'you pay directly' cost note, and return structure (per-model + combined view).

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

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

The description is a single paragraph of 3 sentences, front-loads the core function, and avoids redundancy. Every sentence adds essential information.

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

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

Despite no output schema, the description adequately details return values (per-model {score, confidence, signals, raw_response} + combined view). It covers all parameters, use cases, and key behaviors.

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

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

Schema coverage is 100%, but description adds value by explaining entity as 'thing to ask about', listing supported models, noting _apiKey pass-through, and describing context as disambiguation aid.

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 probes LLMs for knowledge about an entity and scores visibility (0-100). It distinguishes from siblings by specifying AI-marketing audits, pre-launch brand checks, and competitive monitoring as use cases.

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

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

The description gives clear usage context (AI-marketing audits, competitive monitoring) but does not explicitly compare to alternatives like scan_competitor_ai_presence or state when not 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. Description adds meaningful context: it routes to one of 5,347 tools, fills arguments automatically, returns stable pipeworx:// citation URIs, works on every tier, one fast call, handles news routing. Notably it invokes openWorldHint implicitly by covering vast real-world domains, aligning with the annotation. Slight gap: doesn't mention if citations are guaranteed or reliability limits.

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

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

The description is dense and front-loaded with the core value proposition before the examples. Every sentence earns its place — the guidance about sister tools and tier behavior is all actionable. Slightly long at the end with the news-routing caveat, but justified given the breadth. Could trim the trailing sentence about news feeds.

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 broad router tool with no output schema, the description fully covers when to use, what it routes, returns (structured answer + citation URIs), tier compatibility, and alternatives. Given the tool's inherently open-ended scope, this is complete. The examples span domains, and the alternative-tool guidance closes the completeness loop.

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 and 6 aliases, the schema already documents the question parameter thoroughly. The description adds value by explaining what the router does with the question (fills arguments, routes to right tool) which is beyond the alias list in schema. Small deduction: description doesn't clarify whether user should pick a canonical alias or if any works equally.

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 names a precise scope (authoritative structured data with citations across 5,347 tools/1,393 sources) and lists concrete domains. It distinguishes from siblings by naming ask_pipeworx_grounded and deep_research specifically. The 'PREFER OVER WEB SEARCH' framing and explicit examples make purpose unmistakable.

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 ('START HERE', 'default entry point', 'use whenever the user asks...') AND when to step up to alternatives (ask_pipeworx_grounded for hallucination-resistant single answers, deep_research for multi-part questions). Gives concrete trigger phrases and example questions. This is model 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond these: that it's an experimental edge with candidate routing under test, that results feed merge decisions, and critically that it 'falls back to nothing — this IS a full working router.' This addresses a common failure mode where agents assume beta tools are non-functional.

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 focused paragraph that efficiently establishes purpose, current state, usage guidance, and a caution against the 'non-functional beta' misconception. It's front-loaded with the purpose. Slightly longer than strictly necessary, but every sentence earns its place by resolving a likely confusion (what differs, when to use, what it falls back to).

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 router tool with comprehensive annotations (safe read, idempotent, open-world) and a well-documented single-parameter schema, the description is complete. It tells the agent exactly what's different from the stable sibling, current routing state with a specific date, and addresses the fallback question preemptively. No output schema is present, so no return-format burden applies, and for a router the agent needs usage parity clarification which is provided.

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% — all 5 alias parameters plus question are documented in the schema. The description highlights that the tool accepts the same arguments as ask_pipeworx ('same arguments'), reinforcing that the question parameter is the sole semantic input. With full schema coverage, the baseline is 3; the explicit statement about identical arguments to the sibling adds modest value, supporting a 4.

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 this is a beta variant of ask_pipeworx — a universal router with 5,347 tools and the same arguments/response shape. It distinguishes itself from the stable sibling by noting candidate routing improvements are tested live, and it explicitly says use it exactly like ask_pipeworx when wanting the newest routing.

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 'Use it exactly like ask_pipeworx when you want the newest routing' and explains the current state (no candidate active, matches ask_pipeworx exactly). It also contrasts against the stable router ('results are compared against the stable router'). This gives clear when-to-use guidance relative to its sibling.

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

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

Annotations already cover the safety profile (readOnly=true, idempotent=true, openWorld=true), and the description adds valuable detail: the exact success/failure return shapes including the refusal_reason enum values, the verbatim evidence behavior, and the single-extra-LLM-call cost. The openWorldHint annotation aligns with the tool auto-selecting from 5,347 tools, and idempotentHint aligns with grounded extraction being repeatable.

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 efficient — every sentence carries load: purpose, mechanism, return shape, refusal paths, when-to-use, and cost tradeoff are all covered in three sentences. Slightly longer than ideal but each clause earns its place given the tool's complexity and the number of refusal modes that must be documented.

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

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

For a complex routing+extraction tool with no output schema, the description thoroughly documents both return shapes (success and failure), the evidence mechanism, the refusal reasons, cost implications, and the sibling alternative. The tool is inherently complex, and the description matches that complexity without needing an output schema to compensate.

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 primary 'question' parameter well-described and five aliases (query, q, prompt, text, input) explicitly listed. The description adds the behavioral significance: the question routes through 5,347 tools and must be natural-language phrased, which goes beyond the bare schema definition. Minor gap: no guidance on question phrasing quality.

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 this is a hallucination-resistant answer mode that routes queries through a tool-discovery process and extracts answers only from the tool result, returning evidence and an explicit refusal mechanism. It distinguishes itself from its sibling ask_pipeworx by specifying the grounded extraction behavior and the refusal_reason field structure.

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'), gives concrete high-stakes examples (financial verdicts, legal claims, medical lookups, public statements), names the alternative (ask_pipeworx for casual lookups), and discloses the cost tradeoff (one extra LLM call). This is exemplary when-vs-alternative guidance.

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

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

Annotations already declare read-only, open-world, idempotent, non-destructive. Description adds extensive behavioral detail: safety (low-confidence short-circuits), closed market handling, spread warnings, cancellation rule parsing, news fallback/retry. 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?

Very detailed but verbose; multiple paragraphs. However, well-structured with clear sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.) and front-loaded with purpose. Some details could be condensed or moved to output schema.

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?

Complex tool with many fan-out paths, response shapes, resolver contract, parent event extraction, news fields, safety checks, and resolution-rule risk. Description covers all these comprehensively without output schema. No gaps noted.

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 100% with each parameter described. Description adds context for market parameter (resolve market, classifiers, fan-out examples) and briefly explains depth and include_raw beyond schema. Enriches understanding without repeating 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?

Clear verb 'Research' with specific resource 'Polymarket bet' and explicit inputs (slug, URL, question text). Distinct from siblings like ask_pipeworx by targeting betting edge 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?

Explicitly states when to use ('should I bet on X', 'what does the data say', 'is there edge') and provides numerous examples. Also mentions when not to proceed (low-confidence match, closed markets).

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. Description adds significant behavioral context: data sources (SEC EDGAR for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and return of paired data with 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 slightly long but front-loaded with example queries. Every sentence adds useful information, such as data sources, sorting, and output. No redundancy. Could be more compact, but efficient given the tool's complexity.

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

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

For a comparison tool with two entity types, external data sources, and specific output, the description is thorough. It explains data sources, edge cases (off-calendar fiscal years), sorting behavior, and return format (paired data + URIs). No output schema exists, so description fully covers return value.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value: for 'type', it explains what data each enum pulls; for 'values', it gives examples and constraints (tickers/CIKs vs drug names, 2-5 items). This provides more semantic meaning than 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?

Description clearly states it performs side-by-side comparison of 2-5 companies or drugs, citing specific examples like 'X vs Y' and 'compare these companies'. It distinguishes from siblings by explicitly preferring over sequential single-pack lookups and noting it replaces 8-15 lookups, differentiating it from entity_profile and deep_research.

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

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

Explicitly tells when to use: comparisons, ranking, head-to-head. Includes 'ALWAYS PREFER over sequential single-pack lookups', giving clear context for optimal usage. While not explicitly stating when not to use, the context implies it's for comparisons only, which is sufficient.

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 with strong annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true), the description adds substantial behavioral context: timing expectations (15-60s, thorough up to ~90s), the depth tier gap-recovery behavior, contradictions[] flagging, semantic excerpting behavior, and explicit 'never invented' honesty. It also discloses that 'thorough' requires a paid plan, which is critical cost/access transparency beyond any annotation.

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

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

The description is long but every sentence earns its place given the tool's complexity (decomposition, routing, depth tiers, gap behavior, contradictions, excerpts, timing, auth). It front-loads the auth requirement and gets to the tool's core purpose quickly. While verbose, the density of actionable information justifies the length for this highly complex tool.

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

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

For a tool with 2 params, no output schema, and high complexity (parallel tool routing, multiple depth tiers, gap recovery, contradictions, citation formats), the description covers authentication, timing, output structure (findings packet with verbatim evidence + confidence + source + fetched_at + citations), capability boundaries, and fallback tools. This is comprehensive for the tool's actual complexity.

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

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

Schema coverage is 100% and both parameters are well-documented in the schema itself. The description adds meaningful depth to the 'depth' parameter by explaining the actual behavioral differences between quick/standard/thorough (number of facets, gap-recovery, contradictions scan, paid tier). This enriches beyond the schema's facet-count description, though the schema already covers most of the parameter semantics.

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

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

The description is highly specific: 'Grounded multi-source research across Pipeworx's 1393 STRUCTURED data sources' with explicit examples of what it does (decomposes, routes to 5,347 tools, returns findings packet). It clearly distinguishes from siblings by stating 'this is NOT open-web search' and contrasting with ask_pipeworx for single lookups. Strong verb+resource+scope definition.

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?

Exceptionally explicit about when to use vs not: names ask_pipeworx as the alternative for single lookups and breaking/current-news topics, explains that deep_research returns empty gaps[] for non-catalog topics, and clarifies when 'standard' vs 'thorough' is beneficial. Also specifies the ACCOUNT REQUIRED condition and fallback to ask_pipeworx when not signed in. This is best-in-class sibling differentiation.

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

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

Annotations already declare readOnlyHint, idempotentHint, no destructiveness. Description adds that results include full schemas with examples and are ready to call, plus guidance to use first. 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?

Two well-structured sentences. The first states purpose, the second lists domains and return details. Slightly long but justified by the exhaustive domain list. Front-loaded.

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

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

Given the simple input and no output schema, the description fully explains what the tool does, when to use it, and what it returns. Annotations cover safety. Complete.

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

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

Schema description coverage is 100% and the description does not add much beyond what the schema already provides. The baseline of 3 is appropriate.

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

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

The description clearly states the tool finds tools by describing data or task, and lists specific domains. It distinguishes itself from sibling tools (which are individual data tools) by being a meta-discovery tool.

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

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

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Provides clear context but does not name specific alternatives.

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

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

Annotations already declare read-only and idempotent. Description adds specifics: fans out across sources, soft-fails for patents, returns up to 5 filings, and does not support names. 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?

Description is long but well-structured with examples first, then details. Every sentence adds value; slight verbosity justified by complexity.

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

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

For a complex tool with no output schema, description comprehensively covers inputs, outputs (fields like cik, filings, fundamentals), behavior (soft-fail, sorting), and limitations. Complete enough for correct agent invocation.

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

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

Schema coverage is 100% with descriptions. Description adds context: 'zero-padded CIK', 'names not supported', and enum restriction. Improves clarity 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 provides a full cross-source profile of a US public company, with examples like 'tell me about X' and contrasts with chaining single-pack lookups. This distinguishes it from siblings like compare_entities or resolve_entity.

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 for holistic views, advises using resolve_entity for name-only inputs, and implies not for single facts. Provides clear when-to-use guidance.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds context about deleting previously stored memories and clearing sensitive data, reinforcing behavioral traits 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 concise sentences: first sentence states core action, 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?

Simple tool with one required parameter, no output schema, and annotations covering destructiveness. Description fully covers usage context and pairing, making it complete for agent invocation.

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

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

Schema coverage is 100%, and the parameter description 'Memory key to delete' is sufficient. The description does not add new parameter-level details beyond the schema, meeting baseline.

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

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

Clearly states 'Delete a previously stored memory by key' providing a specific verb and resource. Distinguishes from sibling tools remember and recall by pairing with 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?

Explicitly states when to use: stale context, task done, clear sensitive data. Mentions pairing with remember and recall for context. No explicit when-not-to-use, but positive guidance is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: it fetches the page, extracts title/description/key links, and emits standard markdown format. 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 concise (4 sentences) and well-structured: purpose, process, output, use cases. Every sentence adds value with no redundancy.

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

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

Given the tool has 2 parameters with full schema coverage, no output schema, and annotations present, the description is fairly complete. It explains what is generated (single text blob) and mentions the format. Minor lack of details about error handling or accessibility requirements, but sufficient for a simple generation 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?

Both parameters are described in the schema (100% coverage). The description adds meaning by specifying the default value (25) and maximum (50) for max_links, which is not in the schema. It also clarifies the URL parameter as 'Full URL of the site to summarize'.

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 generates a production-ready llms.txt file for any URL, identifies the resource (URL) and action (generate), and distinguishes from sibling tools by focusing on AI crawler indexing. No ambiguity.

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

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

Explicit use cases are provided (getting client's site indexed, drafting for own project, auditing competitor). Though no explicit when-not-to-use or alternatives are given, the sibling list contains no similar tool, making the guidance clear.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. Description adds context about return fields and API key requirement, but does not cover pagination or error handling.

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, no wasted words, effectively communicates purpose and prerequisites.

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 output schema present, description adequately explains return data. Missing details on pagination or limit behavior, but acceptable for a simple GET 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?

Input schema covers all parameters with descriptions. Description does not add new meaning beyond what 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?

Description clearly states it gets NBA games for a season, returning specific fields. Distinguishes from sibling tools like get_player and get_teams by focusing on games.

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?

Implies usage for retrieving NBA game data but does not mention when to use this versus alternatives like search_players or other game-related tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds the critical tier restriction (403 response) and that metadata content overlaps with search_players. 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?

Two sentences, no filler. First sentence states purpose, second provides usage guidance, tier warning, and alternative. Every word earns its place.

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

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

Given tool simplicity (single lookup by ID), presence of output schema, and annotation coverage, the description covers purpose, usage, and constraints. No significant 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 descriptions for both parameters. Description doesn't add much beyond relabeling 'id' as 'BallDontLie player ID' and 'apiKey' as API key, which matches schema. Baseline 3 is appropriate.

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

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

Description clearly states 'direct lookup of a single NBA player by BallDontLie ID'—specific verb, resource, and identifier. Distinguishes from sibling search_players which serves a different use case.

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

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

Explicitly advises when to use this tool vs search_players: prefer search_players on free tier unless paid key is available. Also warns about tier-gated endpoint with specific error code.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds the API key requirement and indicates the static nature of teams. 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?

Two sentences, no redundancy, front-loaded with action and key details. Every sentence earns its place.

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

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

Given the simplicity (1 param, output schema exists), the description covers purpose, usage, and auth. Complete enough for an agent to select and invoke correctly.

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

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

Schema coverage is 100% with a clear description for the _apiKey parameter. The description repeats 'Requires a free BallDontLie API key' but adds no new semantic detail beyond the schema.

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

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

Description explicitly states 'Get all 30 NBA teams with full names, abbreviations, conference, and division,' providing a specific verb and resource. It clearly distinguishes from sibling tools like get_games and search_players.

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

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

Description advises 'Use to find team info or prepare for get_games queries,' giving clear context. It also specifies the API key requirement. Missing explicit exclusions but sufficient for this simple 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 already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds context that only active subscriptions are returned by default (param to include inactive) and lists return fields. 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?

Two succinct sentences covering purpose, return fields, and usage guidance. No superfluous text.

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

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

Tool is simple with one optional param and no output schema. Description lists return fields, making it complete enough for an agent to select and call the tool. The param is well-documented.

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 has 100% coverage with one boolean parameter (include_inactive). Description implies default behavior (active only) and that the param controls inclusion of cancelled subscriptions, which adds meaning beyond the schema 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?

Description clearly specifies 'List the caller's active subscriptions' and enumerates return fields (id, type, params, created_at, last_fired_at, fire_count). Distinguishes from sibling tools like subscribe 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?

Provides explicit usage guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' Implies when to use (before adding subscriptions or to get an id for cancellation) but does not explicitly state when not to use 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 provide limited info (non-readOnly, non-destructive). Description adds significant behavioral context: rate-limited to 5/day, free, not counted against quota, and that team reads digests daily. 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, well-structured: starts with purpose, then usage guidance, then behavioral notes. Every sentence adds value. 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 feedback tool with no output schema, description covers all necessary aspects: purpose, usage, behavior, parameters. Complete for agent selection and invocation.

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

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

Schema has 100% coverage (baseline 3). Description adds value by explaining enum meanings for 'type' and specifying message format (be specific, 1-2 sentences, 2000 chars) and context optionality.

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 verb 'Tell' and resource 'Pipeworx team', specifying purposes: bug, feature, data_gap, praise. Clearly distinguishes from sibling tools which are primarily query/research based.

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 lists when to use (bug, feature/data_gap, praise) and includes a 'don't' instruction (don't paste end-user prompt). Mentions rate limit and free usage. Lacks explicit comparison to siblings, but context makes it clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral details: caching (5min-1h), data source (CF analytics engine), no PII, and self-aggregating nature. 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 concise with three clear sentences: main purpose, use cases, and technical details. Every sentence adds value, and the structure is front-loaded with the primary function.

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 adequately explains what is returned (top tools, top packs, total call volume). It also covers caching behavior and data privacy, making it complete for a simple read-only tool with one parameter.

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 optional parameter (window) has an enum and schema coverage is 100%. The description enriches the enum values by explaining that shorter windows surface hot trends while longer windows show steady-state demand, adding meaning beyond the schema.

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

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

The description clearly states the tool returns trending data (top tools, top packs, call volume) over specified windows. It uses specific verbs and resources, and the purpose is distinct from sibling tools like ask_pipeworx or discover_tools.

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

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

The description provides three explicit use cases (discovering hot data sources, confirming popular tools, checking use case alignment). It does not explicitly mention when not to use or contrast with siblings, but the context is clear enough for an AI agent to infer appropriate usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds extensive behavioral details: semantic anchor (Jaccard similarity), partition filter (placeholder slugs), fill check (realizable edge), and response structure. This goes well 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 thorough but verbose, with several paragraphs of details that could be condensed. While structured with headings, it includes precise thresholds (e.g., 0.30 Jaccard, 3pp, 20%) that may be more than needed for initial understanding.

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

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

Given the absence of an output schema, the description thoroughly explains the response format (opportunities array, partition_check object, fill_check details). It also covers both input modes and edge cases, making it complete for agent understanding.

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 input schema already describes both parameters with 100% coverage. The description adds value by providing example values, explaining that full URLs are accepted, and clarifying the behavioral difference between event and topic modes.

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

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

The description explicitly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks, and clearly distinguishes three modes (no args for trending scan, event for specific market, topic for cross-event). This differentiates it from sibling tools like 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?

The description provides explicit guidance on when to use each mode and includes warnings about fill checks and when not to trade. However, it does not directly compare to alternative tools or state when to avoid using 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 already indicate readOnlyHint, openWorldHint, idempotentHint, no destructiveness. The description adds significant behavioral context: caching (1h KV-level), model details, edge calculation, diagnostics output. 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 and dense, including detailed model formulas and output structure. While well-structured with sections and front-loaded purpose, it could be more concise. A 3 reflects adequate but somewhat excessive length.

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

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

With no output schema, the description fully explains the response structure (by_segment, fed_candidates, _diagnostics) and per-opportunity fields. It handles edge cases like empty segments via filter_skips. For a complex tool, this is remarkably 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%, so the input schema already documents each parameter. The description adds some context via 'Tradeable-edge knobs' and mentions knobs, but does not substantially enhance semantics beyond the schema descriptions. 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 tool scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, with the explicit purpose 'what should I bet on today'. It distinguishes itself from siblings by detailing unique model families and segments, making the purpose specific and actionable.

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: 'agents discover opportunities without paging hundreds of markets' and explains when to use tradeable-edge knobs like min_liquidity and max_spread_pp. However, it does not explicitly compare to sibling tools like polymarket_arbitrage or provide 'when not to use' guidance, hence a 4.

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 extensively discloses behaviors: history bound by 60-day TTL, snapshot gaps due to cache misses, decay calculated from daily closes (not intraday), and detailed response structure. This adds significant context beyond the annotations (readOnly, idempotent, openWorld), which already indicate safety. No contradictions.

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

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

The description is front-loaded with the key purpose and each subsequent sentence adds value, but it is somewhat verbose with detailed response fields. It could be slightly more concise without losing clarity, but overall well-structured for a complex tool.

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

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

Given the tool's complexity and lack of output schema, the description fully details the response arrays (tracked, expired, snapshot_dates) with field explanations and limitations (60-day TTL, cache-miss gaps, intraday vs daily close). It is complete for agent invocation.

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

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

Schema coverage is 100% with descriptions already explaining defaults and clamping for days, and the window family for window. The description reiterates defaults and lists example values but does not add substantial new meaning beyond the schema, earning the baseline 3.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily snapshots. It answers a specific question ('how long has this edge existed and is it shrinking?') and distinguishes itself from siblings like polymarket_edges by focusing on historical tracking rather than current 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?

The description implies usage context by contrasting fresh wide edges with old wide edges, highlighting the tool's value for assessing edge decay. However, it does not explicitly state when to use this tool over alternatives (e.g., polymarket_edges) or provide conditions to avoid, so some guidance is left implicit.

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, but description adds significant behavioral details: walks the ladder, returns top_of_book, vwap_fill_price, slippage, verdict, thin_legs, forced_directional_risk. No contradiction; description enriches 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?

Description is verbose (two long paragraphs). While it front-loads purpose and modes, it could be more structured with bullet points or shorter sentences. Every sentence adds value, but overall density is high.

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 thoroughly lists return fields for both modes and explains verdict and risk legs. Provides context on when to use and potential pitfalls. Missing explicit exchange mention but implicit from name and sibling tools.

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

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

Schema coverage is 100% (baseline 3), but description adds important semantics: explains how size_usd is interpreted for basket mode (settlement notional), side auto-detection for basket, and default values. Adds value 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 it checks realizable-vs-theoretical edge against live order book depth, with two distinct modes (single-market and basket). It strongly differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by focusing on fillability, not just theoretical edge.

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: before acting on polymarket_arbitrage signals or trades above ~$500. Explains why: theoretical overround on thin books is not capturable and partial fills cause directional risk. Provides clear context and exclusions.

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

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

Annotations declare read-only, open-world, idempotent, non-destructive. Description adds extensive behavioral context: compatibility_warning triggers, temporal_alignment field, skipped_cross_type counters, and the rarity of real spreads. 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?

Description is lengthy but well-organized with sections for modes, response fields, and safety fields. Every sentence contributes, though slight trimming could improve conciseness.

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

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

No output schema exists, so description must cover return values. It thoroughly explains leg prices, top_spreads_pp, safety fields, and warning conditions, providing complete context 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%, so description need not repeat. The description adds value by explaining the two modes and the overriding behavior of explicit tickers over topic shortcuts.

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 computes cross-venue spread between Kalshi and Polymarket, detailing two modes (topic shortcuts and explicit tickers) and output format. It distinguishes itself from sibling tools like polymarket_arbitrage by focusing on venue comparison.

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 explains when to use (comparing same question across venues) and warns that most pre-mapped topics yield compatibility warnings. Provides detailed conditions where spreads are meaningful vs. not, such as temporal alignment and bet shape equivalence.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by explaining the listing behavior when key is omitted and the scoping to user identifier. 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 efficient: three sentences, front-loaded with the core action, and no extraneous information. Every sentence contributes 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 the tool's simplicity (one optional parameter, no output schema) and thorough annotations, the description fully covers purpose, usage, scoping, and behavior. No gaps.

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

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

The input schema covers all parameter details (100% coverage), but the description adds important nuance: omitting the key lists all saved keys. This goes beyond the schema's 'omit to list all keys' comment by explaining the behavioral effect.

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 saved via 'remember' or lists all keys when the key argument is omitted. It provides concrete use case examples (ticker, address, research notes), making the purpose 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 explicitly tells when to use the tool ('to look up context stored earlier') and mentions pairing with 'remember' and 'forget' for save/delete operations. It lacks an explicit comparison to alternatives 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 declare readOnlyHint=true, but the description states mark_read:true flags events as read, which is a write side effect. This is an annotation contradiction, severely reducing transparency score despite the description being otherwise clear.

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

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

The description is concise—three sentences that start with purpose, add key details, and end with alternative access. Every sentence adds value and is well-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?

Given no output schema, the description covers return fields (source, citation_uri, payload) and the mark_read side effect. It also mentions polling compatibility and an alternative URL. However, the 'raw event payload' is vague, and the response format could be more explicit.

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 value by giving an example for type ('sec_8k') and specifying since as ISO timestamp, but these are minor additions beyond the schema's own 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 'Pull fired events from your subscription feed,' specifying a clear verb and resource. It also identifies key return fields (source, citation_uri, payload). However, it does not differentiate from sibling tools like list_subscriptions, which may serve a similar purpose.

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

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

The description provides usage guidance: mentions an alternative endpoint for scripts/dashboards, explains mark_read usage for sequential polling, and clarifies that polls work fine. It does not explicitly state when to use this tool over siblings but offers practical 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 safe, idempotent behavior. Description adds valuable context: multi-source fan-out, GDELT-to-GNews fallback, PatentsView soft-fail, and return structure including pipeworx:// URIs.

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 a single paragraph but well-structured, starting with purpose and usage examples. Every sentence contributes information; no fluff. Slightly long but appropriate for the tool's complexity.

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

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

Given the complex multi-source nature and no output schema, the description adequately explains return structure (changes[], total_changes, citations), fallback logic, and limitations (PatentsView soft-fail). Complete for agent use.

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

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

Schema covers all parameters. Description enhances understanding by explaining accepted formats for 'since' (ISO date or relative shorthand) and providing example values for 'value' (ticker or CIK). Minor 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?

Description clearly defines the tool as a change feed for companies, listing specific sources (SEC, news, patents) and explicitly distinguishes it from entity_profile, which provides static profile 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?

Description provides explicit guidance on when to use this tool (dynamic changes) versus entity_profile (static profile), and includes example queries and fallback behavior explanation.

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 details beyond annotations: key-value pair scoped by identifier, persistence differences for authenticated vs anonymous users (persistent vs 24-hour retention). No contradictions with annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false).

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 is well-structured, starting with purpose, then usage, then technical details. Every sentence adds value; 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 no output schema, the description fully explains input, behavior (persistence rules), and pairing with other tools. No gaps remain for the tool's intended use.

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

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

Schema coverage is 100%, with key and value descriptions already clear. Description adds examples and context like 'any text' for value, but adds minimal meaning beyond schema. 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?

The description clearly states the tool saves data for reuse across conversations/sessions, with specific verb 'Save' and resource 'data'. It distinguishes from siblings 'recall' and 'forget' by mentioning pairing, and provides concrete examples of use cases.

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

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

Explicitly says 'Use when you discover something worth carrying forward' and gives examples. It doesn't include when not to use, but contrasts with recall and forget, providing sufficient 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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that each call cascades through several lookup endpoints, which provides extra behavioral context beyond annotations. However, it does not disclose potential rate limits, authorization needs, or what happens if resolution fails.

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

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

The description is concise yet informative. It starts with relatable examples, states the core purpose, provides a usage guideline, and then details supported types with output specifics. Every sentence serves a purpose 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?

Despite the tool's complexity (two entity types, multiple output fields), the description covers the input semantics, output structure, and usage context. Annotations cover safety and idempotency. No output schema exists, but the description adequately explains what is returned, making the tool complete 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% with descriptions for both parameters. The description adds valuable semantic information about the return values for each entity type (e.g., 'returns ticker + 10-digit CIK + company_name' for company). Since there is no output schema, these details are especially helpful for the agent to understand what the tool returns.

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

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

The description starts with clear examples of use cases and explicitly states 'resolve a user-spoken NAME to the canonical/official identifier'. It distinguishes the tool's role by saying 'other tools require as input' and lists supported types with return values, making the purpose unmistakable versus siblings like entity_profile.

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 'Use FIRST whenever you have a name but need an ID.' This is strong usage guidance. It also explains that each call cascades internally to replace multiple manual lookups, providing context. However, it does not mention when not to use or specify alternative tools among siblings.

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

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

Annotations already provide readOnly, idempotent, non-destructive hints. The description adds valuable behavioral context: it probes each entity using 'ai_visibility_check', ranks by score, and returns a list with score, confidence, signal density. 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?

Five sentences, each earns its place. Front-loaded with the main purpose, then explains how it works, gives a use case, and specifies return value. No redundant or vague phrasing.

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 the return format (ranked list with score, confidence, signal density). The tool complexity (4 params, composite with another tool) is well covered. Minor omission: no mention of error cases or rate limits, but not essential.

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

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

Although schema coverage is 100%, the description adds critical nuance: 'First entry treated as the subject for narrative; rest are competitors.' It also clarifies the purpose of the 'context' parameter with an example. This goes beyond the schema's basic type 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 compares AI visibility across multiple entities side-by-side, ranks them, and identifies the most/least recognized. It distinguishes itself from the sibling 'ai_visibility_check' by being a composite batch tool for competitive analysis.

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

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

It explicitly says it's useful for competitive AI-marketing audits and gives a concrete question example. It does not explicitly mention when not to use it or list alternatives, but the context of comparing multiple entities 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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: partial failure handling (bundlephobia timeout up to 30s, sources_failed listed), and the return format (summary block with specific fields, advisories, links, alternatives). 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 dense but well-structured, front-loading the main purpose and then adding behavioral and usage details. Every sentence provides necessary information without redundancy.

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

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

Given the tool's complexity (composite check across multiple sources), lack of output schema, and rich annotations, the description is comprehensive. It explains the return format (summary block with specific fields, advisories, links, alternative versions), failure modes (graceful partial failures), and ecosystem limitations.

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

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

Schema description coverage is 100% (both package and version described in schema). The description adds context beyond schema: scoped packages are accepted, and version defaults to latest published. This extra guidance improves parameter understanding.

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

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

The description clearly states it's a composite check for npm packages combining deps.dev and bundlephobia data. It uses specific verbs and resources ('scan_dependency', 'fans out across deps.dev... and bundlephobia'), and distinguishes from siblings by noting 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly.'

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: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me".' It also provides guidance on alternatives: 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version 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 exactly what is returned (position, height, weight, etc.) and what is NOT (per-game averages, career stats). Aligns with annotations (readOnly, idempotent, non-destructive). Adds context about API key tier and external endpoint limitation.

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 well-organized with examples, but slightly verbose with multiple example phrases. Each sentence adds value (purpose, exclusions, API key note). Could be more concise without losing clarity.

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

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

Given the tool's search nature and output schema existence, the description fully explains the return values, limitations, and prerequisites (API key). The warning about missing stats ensures the agent understands the scope.

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

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

Schema covers all parameters with descriptions (limit, query, _apiKey). The description adds no additional parameter-level details beyond the schema, but it does note that the free _apiKey works. Since schema coverage is 100%, baseline 3 is appropriate.

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

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

The description clearly states it searches NBA players by name on BallDontLie, lists returned fields (position, height, weight, etc.), and distinguishes itself by noting that per-season averages are not included. Examples like 'Find NBA player [name]' clarify 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?

Explicitly says when to use (search players by name) and when not (if stats needed, use /season_averages endpoint not exposed). Mentions free-tier _apiKey works and provides example queries. Differentiates from siblings by stating what data is absent.

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 details beyond annotations: 'BGE-base-en embeddings + cosine over 500-char overlapping windows; cap is 200K chars (longer inputs are truncated and flagged).' No contradiction with annotations (readOnlyHint, etc.).

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 effectively conveying purpose and key technical details. Front-loaded with purpose, but includes implementation specifics that are relevant.

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

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

Given 3 parameters and no output schema, the description covers input constraints, pairing with sibling, embedding model, window size, truncation, and return components (passages with offsets and similarity scores). Very 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 parameter descriptions. Description repeats the same info for 'text' and 'query', and does not mention 'limit' parameter. No additional value beyond schema, so baseline 3.

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

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

Description clearly states 'Semantic search INSIDE a fetched record,' specifying the resource (fetched record) and action (semantic search). It distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded and grounding over passages.

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

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

Explicit guidance: 'Use when the record is too big to cram into the prompt' and 'Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages instead of the whole document.' Clearly explains when to use and suggests alternative.

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

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

The description discloses behavioral traits beyond annotations: requires OAuth, phone verification for SMS, rate limit of 10/day, and delivery channels. Annotations already indicate it is not read-only and not destructive. However, it does not clarify idempotency behavior despite the idempotentHint annotation, missing an opportunity.

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 relatively long but well-structured: purpose, requirements, types, and delivery details are clearly separated. Front-loaded with key information, though slightly verbose; every sentence adds value.

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

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

Given the tool's complexity (multiple types, nested params, no output schema), the description covers most aspects but lacks details on the response structure beyond returning a subscription id. It does not specify whether the response includes status, errors, or additional metadata, which would be helpful.

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 significant value with detailed examples for each subscription type and delivery option. It explains type-specific params (e.g., sec_8k items, polymarket_edge topic) and delivery constraints (e.g., webhook signing secret, SMS verification).

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

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

The description clearly states the tool creates a subscription to a live-data event stream and returns the subscription id. It specifies the verb 'Create' and the resource 'proactive monitoring subscription', differentiating it from sibling tools 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 context on when to use the tool, including the requirement of a Pipeworx OAuth account and that anonymous/BYO cannot persist. It implies alternatives (e.g., recent_alerts for pulling) but does not explicitly state when not to use or compare with all 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?

Beyond annotations (readOnly, openWorld, idempotent), the description discloses the tool returns category-bucketed example questions with exact tool+argument shapes, and is drawn from a live catalog. 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?

Well-structured: starts with common queries, states purpose, lists categories, explains arguments, and gives usage order. 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?

For an onboarding tool with no output schema, the description fully explains what the tool returns (example questions with tool+argument shape) and covers all necessary context. Agent can decide to use it immediately.

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 covers 100% and gives topic options. Description adds value by explaining what happens when omitted (full spread) and gives additional examples, but mostly reinforces schema. Slightly above baseline due to clear omission behavior.

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 as an onboarding entry point that returns example questions with tool call shapes. It distinguishes itself from siblings (like discover_tools, ask_pipeworx) by focusing on suggesting questions rather than executing 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?

Explicitly tells when to use ('Use this FIRST when you do not yet know what Pipeworx can do') and provides guidance on arguments ('Call with no arguments for the full spread, or pass topic'). Mentions meta-tools as related.

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 mutation but not destruction; description adds that row is deactivated not deleted, preserving historical events. Also discloses 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, no wasted words, front-loaded with action and clear structure.

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?

Simple tool with one parameter; description explains behavior (deactivation, history preservation) adequately despite lack of 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 covers 100% of parameters with description; description adds that id is returned by subscribe, which is useful 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?

Description clearly states 'Cancel a subscription by id' with specific verb and resource. Distinguishes from sibling tools 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?

Specifies ownership enforcement and that id must come from subscribe. Provides clear context for when to use, though no explicit when-not or alternative mention.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral context beyond these: it details the two processing paths (structured vs. grounded), explains that company-financial claims use exact percent-delta math with SEC EDGAR, and describes the return verdict types (confirmed, approximately_correct, refuted, inconclusive, unsupported). This is comprehensive and does not contradict annotations.

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

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

The description is detailed but efficiently organized, front-loading with examples and key verbs. Every sentence adds value, though it could be slightly more concise without losing clarity. It balances completeness with 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 absence of an output schema, the description fully covers return values (verdict, actual value with citation, reasoning). It explains processing logic, parameter usage, and the tool's scope (company-financial vs. other claims). This provides sufficient context for an agent to use the tool correctly.

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

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

Both parameters have schema descriptions with 100% coverage. The description adds value for 'tolerance_pct' by explaining its use for hallucination detection and default behavior (implied by wording, capped at 5). The 'claim' parameter is restated, but the description provides context about natural-language claims. Overall, it enhances understanding 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's purpose: verify factual claims against authoritative sources. It provides specific examples of natural-language claims and explains the two processing paths (SEC EDGAR for company-financial claims, grounded pipeline for others). This distinguishes it from sibling tools like deep_research or ask_pipeworx_grounded by focusing specifically on claim verification with a verdict output.

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 'Use whenever the agent needs to check whether something a user said is factually correct.' This provides clear when-to-use guidance. However, it does not explicitly state when not to use it or suggest alternative tools for related tasks, which would improve separation from siblings.

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