Json

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

Annotations indicate read-only, open-world, idempotent, non-destructive. Description adds specifics: default model is free Workers AI Llama-3.3-70b, Anthropic probing requires BYO API key with direct billing, and return format per-model.

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: first covers core functionality and default, second covers optional key and return structure. Front-loaded, 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 4-param read-only tool with no output schema, description explains return structure (per-model objects with score, confidence, signals, raw_response + combined view) and cost behavior. 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 coverage is 100% (all 4 params described). Description adds value beyond schema by clarifying cost implications for _apiKey and disambiguation purpose for context.

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

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

Description clearly states the tool probes LLMs for brand visibility and scores it (0-100). It distinguishes from siblings like ask_pipeworx which focus on specific queries about Pipeworx.

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 use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It explains default vs. paid model usage but doesn't explicitly contrast with sibling tools 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 already establish read-only, open-world, idempotent, and non-destructive behavior. The description adds meaningful behavioral context by explaining that the tool routes to internal tools, auto-fills arguments, and returns citation URIs, and it makes the 'START HERE' default explicit. It doesn't cover error cases or rate limits, but there is no contradiction and the main behavior is well disclosed.

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

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

The description is longer than average but front-loaded with the most important routing directive ('PREFER OVER WEB SEARCH') and organized into purpose, examples, and alternatives. The only minor flaw is some repetition around ask_pipeworx_grounded and the slightly awkward 'Once poor answer quality or citations are needed' sentence, but overall the length is justified by the tool's breadth.

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 broadly scoped routing tool with a simple schema and no output schema, the description is complete: it defines the domains covered, the return shape (structured answer + citation URIs), the query patterns, and the when-not-to-use alternatives. An agent has enough information to select and call this tool correctly in most situations.

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%: the question parameter is documented and its aliases (q, text, input, query, prompt) are listed in the schema. The description provides useful invocation examples and phrasing triggers but does not add substantive parameter semantics beyond what the schema already states, so the baseline score 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 states a concrete action and resource: it routes a natural-language question to one of 5,798 tools across 1,517 verified sources, fills arguments, and returns a structured answer with pipeworx:// citation URIs. It also contrasts itself with web search and names sibling tools, so an agent can tell it apart without inspecting another schema.

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

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

It explicitly says to prefer this tool over web search for authoritative/factual/current data and gives trigger phrases plus example questions. It then names alternatives for edge cases: web search or ask_pipeworx_grounded for simple one-hop no-citation queries, deep_research for broad multi-part research, validate_claim for claims, and discover_tools for finding specific source packs.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the description's burden is lower. It adds valuable context beyond annotations: no candidate is currently active as of 2026-07-26, behavior currently matches ask_pipeworx exactly, and this is a full working router that 'falls back to nothing' rather than a stub or proxy.

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

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

The description is four sentences and every sentence earns its place: beta status, current routing state, usage instruction, and a clarification that this is a complete working router. It is slightly dense but not bloated, and the key identification is front-loaded.

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

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

Given the simple schema, safe annotations, and no output schema, the description covers everything an agent needs: how to invoke it, what it currently does, that it matches ask_pipeworx's response shape, and that its behavior may change when a candidate routing improvement is under test.

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

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

Schema description coverage is 100%, with all six parameters documented as aliases for the required question parameter. The description mentions 'same arguments' but adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states this is a beta version of ask_pipeworx and a universal router with the same 5,798 tools, arguments, and response shape. It explicitly positions the tool as the experimental edge relative to the stable ask_pipeworx, making its identity and scope 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 says to 'Use it exactly like ask_pipeworx when you want the newest routing' and explains that results are compared against the stable router. This gives a clear condition for selection, though it does not explicitly contrast with ask_pipeworx_grounded or state when to prefer the stable version.

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 set readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so there is no contradiction. The description adds significant behavioral context beyond annotations: the refusal contract with five explicit refusal reasons, the strict 'using ONLY what the tool result contains' grounding boundary, and the note about an extra LLM call. These are operational behaviors an agent cannot infer from the annotations alone.

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

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

The description is dense but every sentence carries operational information: the grounded/high-stakes mode, the routing contrast, the output shape, refusal reasons, usage conditions, and cost trade-off. The most important decision signal ('Hallucination-resistant answer mode') is front-loaded, followed by structured return and refusal details. There is no filler or repetition.

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?

Because there is no output schema, the description carries the full burden of explaining return values, and it does so thoroughly with both success and refusal object shapes, including all refusal reason enum values. It also covers the high-stakes usage context, the grounding guarantee, and the cost comparison with ask_pipeworx. For a read-only tool with one user-facing parameter, nothing critical is missing.

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

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

The input schema has 100% description coverage, with the 'question' property fully described as 'Your question in natural language' and its aliases listed. The description adds no additional meaning about the user-supplied parameter; its mention of 'fills arguments' refers to internal routing, not to the caller's question format. With high schema coverage, 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 opens with 'Hallucination-resistant answer mode for high-stakes reads' which names both the mode and its distinguishing value, and immediately contrasts with ask_pipeworx, a sibling tool with the same routing. It specifies the exact mechanism: picks a tool from 5,798 across 1,517 sources, fills arguments, fetches data, and extracts the answer only from the tool result. This clearly separates it from the 33 sibling tools, especially ask_pipeworx, ask_pipeworx_beta, and validate_claim.

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

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

The description explicitly states when to use this tool: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' and gives concrete high-stakes examples such as financial verdicts, legal claims, medical lookups, and public statements. It also provides the exclusion rule by saying 'prefer ask_pipeworx for casual lookups' and explains the cost trade-off. This is clear when/when-not guidance naming the correct alternative.

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

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

Annotations indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds rich behavioral details: resolver contract, parent event extractor, news fields, safety behaviors (low-confidence short-circuit, closed market handling), and response shapes. 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 long but well-organized with clear sections (RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, etc.). Every sentence adds essential information for a complex tool. Slight wordiness but justified by depth of behavior.

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

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

Despite no output schema, description thoroughly documents response shapes, all fields (market, analysis, evidence), edge cases (low confidence, closed markets, wide spreads, resolution rules), and blocking paths. 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?

Schema coverage is 100% with descriptions for all parameters. Description adds significant value beyond schema by explaining market flexibility, depth options (quick/thorough), include_raw for raw payloads, and default behaviors.

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 researches Polymarket bets by pulling Pipeworx data, lists input types (slug, URL, question text), and outputs evidence packet with comparison. It distinguishes from sibling tools like polymarket_edges and polymarket_arbitrage by focusing on 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?

Explicit use cases: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. Provides extensive guidance on classifiers, fan-out examples, and critical caveats about low-confidence matches, closed markets, resolution-rule risk, and tradeability.

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. The description adds behavioral context: it handles off-calendar fiscal years correctly, sorts results by primary metric, and returns citation URIs. It does not contradict annotations and provides useful operational details beyond the structured fields.

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 example queries and key preference guidance. Every sentence adds value: usage patterns, data sources, sorting, output format. While somewhat long, the complexity of the tool (two entity types, multiple metrics) justifies the length. Minor redundancy with schema constraints could be trimmed.

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

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

Despite no output schema, the description thoroughly explains what each entity type returns: for companies, specific financial metrics from SEC EDGAR; for drugs, FAERS adverse-event counts, approval counts, trial counts. It mentions sorting, citation URIs, and off-calendar handling. For a comparison tool replacing many lookups, this is complete and actionable.

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

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

Schema coverage is 100%, so the baseline is 3. The description enriches parameter meaning by explaining that 'type' determines the data source (company vs drug) and giving concrete examples for 'values' (tickers/CIKs for company, drug names for drug). It also reiterates the 2–5 range and adds sorting behavior, providing more context than the schema alone.

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

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

The description opens with concrete usage examples like 'Compare X and Y' and 'X vs Y', clearly stating it performs side-by-side comparison of 2–5 entities. It distinguishes between 'company' (financial data from SEC EDGAR) and 'drug' (FAERS data), and explicitly prefers this tool over sequential lookups, differentiating it from sibling tools 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 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', giving clear when-to-use guidance. It also implies alternatives by naming the sequential approach, and describes data sources and constraints, helping the agent decide when this tool is appropriate.

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

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

Annotations already mark the tool read-only, open-world, idempotent, and non-destructive, and the description adds substantial behavioral depth beyond that: it discloses the account/tier requirement, parallel decomposition across 5,798 tools, the findings packet structure, explicit gaps[] for unanswered facets, contradictions[] in standard/thorough modes, semantic excerpting rather than head truncation, and expected latency. No contradiction exists between the description and annotations.

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

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

The description is long but information-dense, with key routing information front-loaded at the top ('ACCOUNT REQUIRED... use ask_pipeworx instead'). Some sentences are run-on and dense, but every major clause contributes a distinct behavioral fact, so the length is justified for a tool this complex.

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 carries the burden of explaining return behavior: findings packet fields, confidence, source, fetched_at, citation_uri, gaps[], contradictions[], hop field, and citation resolution guarantees. It also covers prerequisites, fallback routing, depth differences, and latency. An agent has everything needed to invoke and interpret the tool correctly.

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

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

Schema coverage is 100% for both parameters, so the schema already documents question and depth. The description adds real value by explaining depth behavior in more operational terms ('gap-recovery hop', 'chases leads + recovers gaps', 'contradictions[] scan') and by clarifying that question can be broad/multi-part because decomposition is the point. This goes beyond the schema descriptions without redundant repetition.

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

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

The description names a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources' in one call, and explicitly contrasts itself with 'open-web search'. It also identifies its niche ('Best for broad/multi-part questions over structured data') and distinguishes itself from the sibling ask_pipeworx by telling the agent when to use that tool instead.

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

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

The description gives explicit routing guidance: 'If you are not signed in, use ask_pipeworx instead', and 'For a single lookup use ask_pipeworx'. It also explains which depth level is appropriate (quick/standard/thorough) and what each does, so the agent can select both the tool and its parameter reliably.

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, idempotentHint, and destructiveHint. The description adds that the tool returns top-N relevant tools with full schemas and curated examples, ready to call immediately. This goes beyond annotations and is accurate.

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

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

The description is front-loaded with the core purpose, followed by domain examples and then return behavior. It is slightly verbose but every sentence adds value. 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?

The tool has 6 parameters (100% schema coverage) and no output schema. The description fully explains the return format: top-N relevant tools with names, descriptions, and full input schemas. Given the absence of output schema, this is sufficient.

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

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

Schema description coverage is 100%, so baseline is 3. The description mentions aliases but does not add significant meaning beyond what the schema already provides. The examples in the schema input field are good but not part of the description text.

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 'Find tools by describing the data or task,' clearly stating the verb and resource. It lists many specific domains (SEC filings, FDA drugs, etc.) and distinguishes itself from sibling tools by being a meta-tool for discovering other 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 explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It also details use cases like browse, search, look up, discover. While it does not mention when not to use, the guidance is clear and actionable.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds far more: it lists the fan-out sources (SEC, XBRL, USPTO, USAspending, Purple Book, DOL LCA, news, GLEIF), explicitly explains that empty sections mean real no-data via sources_used/sources_failed, and discloses that private companies return resolved:false with a notes line rather than a bare failure. This is rich behavioral context beyond the annotations.

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

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

The description is extremely dense and mostly purposeful, covering all major behaviors, but it is a single block of text with no structural breaks. The opening five paraphrased user queries are somewhat redundant and could be trimmed. Still, given the complexity of a multi-source fan-out tool, the length is justified.

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

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

There is no output schema, so the description must carry the burden of explaining return values. It does so thoroughly: enumerates returned sections (cik, company_name, recent_filings, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI), explains how to interpret sources_used/sources_failed, and covers edge cases like private companies and name resolution. Very complete for a tool of this 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%, yet the description still adds significant value: concrete examples ('AAPL', '0000320193', 'Moderna'), emphasis on zero-padded CIK, explanation of SEC EDGAR name resolution, and clarification that 'company' and 'ticker' types are interchangeable. These details are not present in the schema alone.

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

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

The description states a specific verb+resource: it produces a 'full cross-source profile of a US public company in ONE parallel call.' It clearly distinguishes itself from single-pack SEC/XBRL/news lookups by stating 'ALWAYS PREFER over chaining single-pack...' when a holistic view is requested, separating it from sibling 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?

Provides explicit when-to-use guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also clarifies accepted input shapes (ticker, CIK, company name) and the expected behavior for private companies, leaving little room for incorrect invocation.

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

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

Annotations already provide destructiveHint and idempotentHint. The description adds usage context but not deeper behavioral traits (e.g., whether deletion is permanent or requires confirmation).

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

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

Two sentences with no wasted words; first sentence delivers the core action, second provides usage context.

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

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

For a simple deletion tool with one parameter and no output schema, the description is nearly complete; could mention return value 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?

Schema coverage is 100% with a clear description for 'key'. The description adds no additional meaning beyond what the schema provides.

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

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

The description clearly states 'Delete a previously stored memory by key' with a specific verb and resource, and distinguishes from sibling tools like 'remember' and 'recall' by its destructive action.

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 (context stale, task done, clear sensitive data) and pairs with 'remember' and 'recall', but does not explicitly state when not to use 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?

The description adds context beyond annotations by stating it is 'Keyless, offline' and explaining the behavior of the indent parameter. No contradictions with annotations.

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

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

Two sentences with no wasted words. The main purpose is front-loaded, and the parameter behavior is efficiently described.

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?

All essential information is provided: purpose, parameter behavior, and safety traits via annotations. No output schema needed. Sufficient 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?

The schema already covers both parameters (100% coverage), but the description adds value by specifying default indent of 2 and that 0 means minify, clarifying the parameter's 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 states 'Pretty-print or minify a JSON string,' providing a specific verb and resource that distinguishes it from sibling tools like validate_json or query_json.

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

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

The description mentions 'Keyless, offline,' clarifying that no external dependencies are needed, but does not explicitly guide when to use this tool versus alternatives like query_json.

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 discloses fetching, extraction, and output format (standard llms.txt markdown), adding value beyond annotations which already include readOnlyHint, idempotentHint, etc. 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?

Four sentences with no wasted words, front-loaded with core purpose, followed by behavioral details and use cases.

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 and clear annotations, the description adequately covers behavior and output. Could mention error handling or size limits but not required.

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

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

Schema coverage is 100% for 2 params, so baseline 3 applies. The description does not add parameter details but implies URL is primary and max_links is optional, which is sufficient.

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

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

The description uses a specific verb 'Generate' and resource 'llms.txt file for any URL', clearly distinguishes from siblings like scan_competitor_ai_presence by specifying the output format and target 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?

Provides explicit use cases (client indexing, own project, competitor audit) but lacks guidance on when not to use this tool or alternatives beyond implied 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, destructiveHint. The description adds that it lists only the caller's subscriptions and restricts to active ones by default, providing scope beyond annotations. No contradictions.

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

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

The description is two sentences, front-loaded with the purpose, followed by return fields and usage guidance. 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 low complexity (one optional param, no output schema), the description fully covers purpose, return fields, and usage context. No gaps are evident.

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 has full coverage (100%) with a description for the single optional parameter. The tool description does not add further parameter details, so baseline 3 is appropriate.

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

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

The description clearly states 'List the caller's active subscriptions' and specifies the returned fields (id, type, params, etc.), making the action and resource unambiguous. It distinguishes from sibling tools like subscribe/unsubscribe by focusing on listing.

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

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

The description provides explicit use cases: 'review what you're monitoring before adding more' and 'find an id to cancel'. This offers good guidance but doesn't explicitly mention when not to use it or alternative tools.

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

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

With all annotations set to false/absent, the description carries the behavioral disclosure burden. It discloses rate limiting (5/day), claim_token mechanics, that it's free, and the daily digest processing. It doesn't mention side effects like persistence, but the token mechanism implies it; still strong coverage.

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 dense paragraph with no filler. Every sentence adds value, from purpose to exclusions to behavioral details. Length is justified by the multi-faceted nature of the tool, and it is appropriately front-loaded with the core purpose.

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

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

Given the four parameters, nested context object, and lack of output schema, the description covers all necessary ground: what the tool does, when to use, how to format feedback, claim_token flow, rate limit, and routing. No output schema exists, so the description's explanation of claim_token return value fills that gap.

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

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

Schema covers all 4 params with descriptions (100%), so baseline is 3. The description adds extra guidance beyond schema, such as explaining claim_token usage ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})') and instructing users to describe issues in terms of Pipeworx tools rather than pasting user prompts, which enriches 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 opens with 'Tell the Pipeworx team something is broken, missing, or needs to exist,' a clear verb+resource statement. It further distinguishes itself from siblings by specifying categories (bug, feature, data_gap, praise) and routing constraints.

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 states when to use ('Use when a tool returns wrong/stale data...') and when not to ('if the tool came from a different MCP server... file it with that server instead'), naming alternatives. It also provides a disambiguation rule for identifying Pipeworx 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, openWorldHint, idempotentHint, destructiveHint false. Description adds value beyond annotations: 'Self-aggregating signal — derived from CF analytics-engine, no PII, just (pack, tool, count). Cached 5min-1h depending on window.' No contradiction.

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

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

Three substantial sentences with bullet-point-like list for use cases. No wasted words, though slightly verbose. Information is front-loaded with the core purpose.

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

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

For a simple tool with one optional parameter and no output schema, description covers purpose, usage, and behavior. Lacks detail on return format (e.g., structure of results), but the mention of 'top tools, top packs, and total call volume' provides sufficient context.

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

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

Schema coverage is 100% with one enum parameter. Description enriches semantics: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' Provides practical guidance beyond the enum values.

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 uses specific verb 'Returns' and lists resources (top tools, top packs, total call volume) with time windows. Clearly distinguishes from siblings like ask_pipeworx by being a discovery/trending 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 lists three concrete use cases (discovering hot data sources, confirming canonical tool, checking use case alignment). Provides clear context for when to use, though doesn't explicitly state when not to use or mention 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?

Beyond annotations (readOnly, idempotent), the description discloses scanning scope (top ~200 markets), threshold for signals (deviations >3pp), filtering mechanisms (semantic anchor Jaccard ≥0.30, placeholder fraction >20%), and response structure including fill check behavior. All behavioral traits are clearly explained without contradiction.

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

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

The description is well-structured with clear sections for each mode and technical details like fill checks, but it is slightly verbose (~250 words). Every sentence adds value, but some technical details (e.g., exact similarity threshold) could be condensed without loss.

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

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

Given no output schema, the description fully compensates by detailing the response fields (opportunities[], partition_check{...}, fill check with realizable_edge_pp). It also covers edge cases (placeholder filtering, low similarity) and links to a sibling tool for advanced usage. The tool is completely described 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 brief descriptions, but the tool description adds substantial value: explains that event expects a slug and triggers child market traversal with specific checks, while topic triggers cross-event search with comparator. Also explains recommended use for each parameter.

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 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks' and distinguishes between three call modes (no args, event, topic). It clearly identifies the tool's purpose and differentiates it from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

Provides explicit guidance for each mode: 'Call with NO args for a trending_scan... pass `event` for the strongest per-event partition_check, or `topic` for a themed cross-event scan.' Also explains when to avoid trading (realizable_edge_pp ≤ 0) and references a sibling tool for custom sizing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar for additional disclosure is lower. The description exceeds expectations by detailing caching ('Cached 1h at the KV level'), edge computation (net of slippage, per-model families), and response structure including diagnostics. 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 very long and dense, containing detailed technical explanations of model families and edge calculations. While informative, it could be more concise; the sheer length may overwhelm agents. Front-loading with the purpose helps, but some details like exact parameter values (e.g., 'tennis 1.02') are excessive for a summary.

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

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

Given the complexity (9 parameters, no output schema), the description thoroughly explains return values including per-opportunity fields (edge_pp_net, kelly_fraction, market stats) and top-level structure (by_segment, fed_candidates, _diagnostics). It also covers caching behavior and optional filters, making the tool fully understandable for 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%, providing baseline 3. The description adds significant context for some parameters (e.g., min_partition_leg_kelly explains why partition arbs have parent-level kelly=0 and how to filter per-leg). However, for most parameters, the description does not go beyond what the schema already provides.

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

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

The description clearly states the tool 'scan[s] top Polymarket markets and return opportunities where Pipeworx data disagrees with market price' and is built for 'what should I bet on today'. It is specific about the verb 'scan' and the resource 'Polymarket markets with Pipeworx data', but does not explicitly differentiate from sibling tools like polymarket_arbitrage, which may have overlapping 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 sets context by stating it is for discovering opportunities without paging, and includes exclusions like Fed bets being unreliable at meeting-month horizons. It implies when to use (daily betting decisions) but does not explicitly contrast with alternatives such as polymarket_edge_tracker or polymarket_arbitrage.

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

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

Annotations indicate read-only, idempotent, non-destructive behavior. The description adds context about data sources (snapshots, daily closes), constraints (60-day TTL, enabled date), and interpretation of 'decay' and 'edge_pp_net' sign. 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 extremely information-dense but somewhat lengthy and uses a run-on structure for the response fields. It could be more concise by using lists, but every sentence is substantive.

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

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

Despite no output schema, the description fully explains the return format (tracked, expired, snapshot_dates arrays), field meanings (trend, decay_pp_per_day, lifespan_days), edge sign convention, and limitations. No gaps for this complex tool.

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

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

Both parameters have schema descriptions (100% coverage). The description adds valuable context: 'days' lookback with default/max, 'window' as snapshot family with default. It explains how these affect the data retrieved, going beyond schema docs.

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

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

The description clearly states the tool provides 'edge persistence and decay telemetry' from daily snapshots, answering a specific question about edge duration and shrinkage. It distinguishes itself from the sibling 'polymarket_edges' by focusing on historical tracking, not just 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 gives a concrete example of when to use the tool (comparing fresh vs. old edges) and outlines the response structure. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for selection.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context such as walking the ladder, returning slippage, fill details, and forced_directional_risk, which is consistent 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?

Well-structured with clear sections (SINGLE-MARKET, BASKET), bold emphasis, and no wasted sentences. The length is appropriate given the complexity of the tool.

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

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

The description covers return fields and limitations, but lacks an output schema. It gives a good overview, but could be more systematic in listing all return fields. Almost 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?

Though schema coverage is 100%, the description adds significant meaning: explains dual modes, parameter interactions (market vs event exclusive), default values, size_usd interpretation differences, and clamp range. This goes well beyond the schema.

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

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

The description clearly states it performs a 'realizable-vs-theoretical edge check' against live order-book depth, and distinguishes between single-market and basket modes. It is a specific verb+resource that differentiates from sibling tools.

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

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

Explicitly states 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500', and warns about theoretical overround not being capturable and partial basket fills converting arbs to directional positions.

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

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

The description goes far beyond the readOnly/openWorld/idempotent annotations by disclosing matching limitations, compatibility warning codes, temporal alignment semantics, fee model exclusions, skipped pair counters, and the fact that returned pairs are keyword-matched rather than verified. This is exceptionally transparent about edge cases and interpretation.

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 comprehensive but verbose and somewhat redundant — compatibility warnings, temporal mismatches, and the gross-spread caveat are repeated multiple times. It is well-structured with labeled sections, but not every sentence earns its place, and the length may dilute key operational warnings.

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

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

For a tool with no output schema and a complex response contract, the description is exceptionally complete: it documents codes, per-pair flags, skipped classification behavior, temporal alignment semantics, fee disclosures, and warning conditions. An agent has enough context to call the tool and interpret a response 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%, giving the baseline of 3, but the description adds substantial meaning beyond the schema: it explains how `topic` maps to shortcuts, how explicit tickers override the mapped side, and how both modes run the same matcher. This gives the agent a better model of parameter behavior than the schema alone.

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

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

The description clearly identifies the tool as computing a cross-venue spread between Kalshi and Polymarket for the same resolving question, which is a specific function. However, it lacks a direct action verb and does not explicitly differentiate itself from related siblings like polymarket_arbitrage.

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

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

It provides strong usage context by describing two distinct modes — pre-mapped topic shortcuts versus explicit event ticker/slug pairing — and warns that pre-mapped topics are not necessarily tradeable. It stops short of naming when-not-to-use this tool or pointing to alternatives among the sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds 'Keyless, offline' as extra behavioral context, but does not discuss edge cases like missing keys or invalid paths. Moderate value beyond annotations.

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

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

The description is very short, consisting of one sentence with an example. No wasted words, but could be slightly more structured. Effectively concise.

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

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

For a simple tool with 2 fully described parameters and no output schema, the description is mostly complete. It covers the core functionality, example, and key behavioral traits (keyless, offline). Could mention error handling, but adequate.

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 an example but no new semantic meaning beyond what the schema provides. 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 extracts a value from JSON using dot/bracket notation, with a concrete example. It distinguishes from siblings like format_json and validate_json by specifying the action and resource.

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

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

The description mentions 'Keyless, offline', implying no auth or network needed, but does not explicitly state when to use vs alternatives or when not to use it. Usage context is somewhat implied by the sibling tools' purposes.

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 readOnly, idempotent, non-destructive. Description adds scoping detail ('Scoped to your identifier') and the listing behavior when key is omitted. No contradictions.

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

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

Three sentences, all essential: action, use case, pairing advice. No wasted words. Front-loaded with the primary action.

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

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

For a simple tool with one optional parameter and no output schema, the description covers both usage modes, scoping, and practical examples. Combined with clear annotations, it's fully 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 has 100% coverage for the single parameter. Description adds real-world context (e.g., 'user's target ticker, an address, prior research notes') and clarifies the dual behavior of retrieval vs listing, going beyond schema's generic description.

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

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

The description uses specific verbs ('Retrieve'/'list') and resource ('value saved via remember'/'all saved keys'). It distinguishes from siblings by name-dropping remember and forget, and gives concrete use examples (user ticker, address, notes).

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 ('look up context stored earlier'), why it's beneficial ('without re-deriving from scratch'), and how it pairs with siblings ('Pair with remember to save, forget to delete'). Also mentions scoping.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive. Description adds behavioral context: explains the mark_read flag's effect on next call, lists returned fields (source, citation_uri, payload). No contradictions.

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

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

Three sentences: purpose, return+parameters, advanced behavior and alternative access. Front-loaded, no fluff.

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

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

Covers return fields, key parameters, mark_read semantics, and polling suitability. Omits unread_only param description but schema handles it. No output schema, but description adequate 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 coverage is 100%, baseline 3. Description adds meaning beyond schema: explains mark_read behavior, implies type filtering, notes limit range (1-200, default 50). Unread_only not mentioned but schema covers it.

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

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

Starts with 'Pull fired events from your subscription feed' – a clear verb+resource pair. Distinguishes itself from siblings like list_subscriptions by focusing on alert events and their payload.

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?

Clearly states the tool is for pulling recent alerts with optional filters. Mentions that polling works fine and provides an alternative endpoint for scripts/dashboards. No explicit when-not-to-use, but context 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?

Beyond annotations (readOnlyHint, idempotentHint), the description reveals that the tool fans out to multiple data sources (SEC EDGAR, GDELT→GNews fallback, USPTO), explains fallback behavior, and mentions soft-fail conditions (USPTO). This exceeds the annotation baseline.

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

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

The description is a single, well-structured paragraph that front-loads examples and key details. While efficient, it includes some redundancy with the schema descriptions of parameters, preventing a perfect score.

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 explains the return structure (changes[ ] grouped by source, total_changes count, citation URIs). It covers parameters fully, addresses error conditions, and distinguishes from a sibling tool. For a tool with this complexity, no gaps remain.

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

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

Schema coverage is 100%, and the schema already contains detailed parameter descriptions (e.g., 'since' format with examples). The description adds no new parameter-level information beyond what is in the schema, meeting the baseline but not exceeding it.

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

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

The description clearly states the tool serves as a change feed for a company, with examples like "What's new with X". It explicitly distinguishes itself from the sibling tool `entity_profile`, which provides static profiles.

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

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

The description provides explicit guidance on when to use this tool vs. alternatives (e.g., 'Use entity_profile instead when you want the static profile'). It includes example queries and context for typical 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 indicate idempotent and non-destructive. Description adds that data is key-value scoped by identifier, with persistent memory for authenticated users and 24-hour retention for anonymous sessions. No contradictions.

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

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

Three concise sentences cover purpose, usage, and behavioral details. Front-loaded with verb and resource, 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?

No output schema, but description explains storage behavior and pairing with recall/forget. Could mention return value (e.g., success confirmation), but still complete for a simple save operation.

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

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

Schema coverage is 100% with descriptions for key and value. Description provides examples but adds little beyond the schema. Baseline 3 is appropriate.

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

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

The description states 'Save data the agent will need to reuse later', specifying the verb (save) and resource (data). It distinguishes from sibling tools recall and forget, which are mentioned as pairs.

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 ('when you discover something worth carrying forward') and provides alternatives ('Pair with recall to retrieve later, forget to delete'). Also details scoping by identifier and persistence duration.

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

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

The description adds substantial behavioral context beyond the annotations: it discloses cascading internal lookups, graceful degradation when GLEIF or OpenFIGI is unavailable, explicit handling of unresolved identifiers via an `unresolved` field, behavior when a name maps to multiple instruments (`figi_candidates`), and source labeling for each identifier. This is far beyond the readOnly/openWorld/idempotent hints already present.

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 use case and 'Use FIRST' guidance, which is ideal. It is long and dense, but most sentences earn their place given the tool's complexity and the lack of an output schema. A few parenthetical asides add length without much new information, so it is not maximally concise.

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

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

For a two-parameter tool with no output schema, the description is remarkably complete. It covers supported types, accepted input formats, edge cases (ambiguous matches, non-equity securities, unavailable external sources), and expected behavior around unresolved identifiers. An agent has enough context to know when this tool applies and what it will return in tricky situations.

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

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

The schema already covers both parameters thoroughly, so the baseline is 3. The description adds meaningful extra semantics: it introduces ISIN as an accepted input not listed in the schema, explains the distinction between exact ticker mapping and name search, and provides a concrete negative example ('NEW YORK ST DORM AUTH revenue bonds') to clarify what should not be passed in `value`. This exceeds what the schema alone provides.

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

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

The description states a clear, specific purpose: resolving a user-spoken name or identifier into canonical/official identifiers required by other tools. It lists concrete example queries, supported entity types (company, drug), and distinguishes itself from sibling tools like entity_profile by framing it as the first step when an ID is needed.

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 to use this tool 'FIRST whenever you have a name but need an ID,' which is strong usage guidance. It also enumerates accepted input forms (ticker, CIK, ISIN, company name, brand/generic drug name) and supported entity types. However, it does not explicitly mention when not to use it or name specific alternatives, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds transparency by revealing that it probes each entity with ai_visibility_check and returns a ranked list with score, confidence, and signal density. No contradictions.

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

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

Two sentences, front-loaded with the main purpose, no wasted words. Every sentence adds value.

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

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

With 4 parameters and no output schema, the description adequately explains the tool's function and output format. It mentions the ranked list with three fields, which is sufficient for an agent to understand the result. Could be more detailed, but acceptable.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal context (first entity treated as subject) but does not significantly elaborate 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 verb 'Compare AI visibility' and the resource 'multiple entities'. It explicitly names the internal tool ai_visibility_check and mentions ranking by score, distinguishing it from sibling tools like compare_entities by focusing on AI visibility.

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: 'Useful for competitive AI-marketing audits' and gives an example question. It implies when to use but does not explicitly mention 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 already declare readOnlyHint, idempotentHint, and non-destructive. The description adds critical behavioral details: partial failure degradation, bundlephobia's first measurement taking 5-30s, and the sources_failed field. This goes beyond the structured annotations.

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

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

The description is a single dense paragraph containing all essential information: purpose, usage, limitations, and return structure. Every sentence contributes value, but it could be slightly restructured for clarity (e.g., bullet points). Efficient overall.

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 bears full burden. It lists all return fields (summary block fields, per-advisory detail, links, alternative versions) and explains partial failure behavior. This is fully sufficient for an agent to understand what the tool returns.

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

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

Schema description coverage is 100%, so baseline is 3. The description repeats the package name scoping and version defaults already present in the schema, adding no new parametric meaning. Agent gets no extra value from description regarding parameters.

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

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

The description clearly states the tool is a composite check for adding npm packages, combining data from deps.dev and bundlephobia. It specifies the exact purpose: evaluating safety, popularity, size, and cost. This distinguishes it from siblings like 'entity_profile' which are more general.

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

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

Explicitly says 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"' and notes the NPM-only limitation for v1. While it doesn't name an alternative tool for other ecosystems, it indirectly points to deps.dev for those. This is clear context but lacks explicit exclusion.

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

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

Beyond readOnly/idempotent annotations, description details BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap with truncation flag. Completely transparent about internal mechanics.

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

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

Front-loaded with core purpose, then expands with usage and technical details. Each sentence adds unique value, though slightly dense. 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, description adequately explains return format (passages with offsets and similarity scores) and input limits (200K chars, truncation). Fully informs agent of expectations.

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 descriptively. Description adds value by giving natural-language query examples and stating the text parameter is for already-pulled content. Enhances schema without redundancy.

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 'Semantic search INSIDE a fetched record' with specific examples (SEC 10-K, article). It distinguishes from siblings by mentioning 'ask_pipeworx_grounded' as a pair, making it unique among sibling tools.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and pairs with 'ask_pipeworx_grounded'. No explicit when-not scenarios, but 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 indicate idempotentHint=true and destructiveHint=false, but the description adds significant behavioral context: requires OAuth account, returns subscription id, delivery constraints (phone verification, 10/day SMS cap, webhook auto-disable after 10 failures). No contradiction with annotations.

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

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

The description is well-structured: purpose first, then requirements, type details, delivery channels. It is informative but somewhat lengthy; could be slightly 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 3 parameters with full schema coverage, no output schema, the description covers all necessary aspects: return value, type-specific filters, delivery options with constraints, and prerequisites. Highly complete for a subscription creation tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value with type-specific examples and delivery channel constraints, providing meaning beyond the schema's basic descriptions.

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream and returns the new subscription id. It distinguishes from siblings like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation and specifying supported types and delivery channels.

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 this tool (create subscription) and who can use it (requires Pipeworx OAuth account, excluding anonymous/BYO). It details type-specific conditions, but does not explicitly contrast with sibling tools or state when not to use it.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by detailing the return format (category-bucketed example questions) and that results are drawn from a live catalog of thousands of tools, plus the onboarding entry point context. 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 example questions and is comprehensive without being overly verbose. Every sentence adds value, though it could be slightly more concise by combining some elements. Still, it earns its length.

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

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

Given the single optional parameter, no output schema, and rich annotations, the description thoroughly explains the tool's purpose, usage, and return format. It covers when to use it, how to invoke it, and what to expect, making it complete for an agent.

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 description for the topic parameter. The description adds meaning beyond the schema by explaining that omitting the argument gives a full spread and listing possible topic values (finance, pharma, etc.). This provides practical usage context.

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

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

Description clearly identifies the tool as the onboarding entry point for Pipeworx, listing example user queries and explicitly stating what it returns (category-bucketed example questions with exact tool+argument shapes). It provides a specific verb+resource and distinguishes from sibling tools like ask_pipeworx and discover_tools.

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

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

Explicitly states when to use this tool: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' It also gives guidance on arguments, such as omitting the topic parameter for a full spread or passing a specific topic to focus.

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 that the row is deactivated (not deleted), which is important behavioral context beyond annotations. It also states ownership enforcement, adding value.

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

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

Three efficient sentences, front-loaded with purpose. Every sentence is necessary and 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 simple tool with one parameter and no output schema, the description covers purpose, usage constraints, behavioral effects, and parameter source, making it fully 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%. The description adds 'returned by subscribe' linking parameter to a sibling tool, providing extra context beyond the schema.

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

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

The description clearly states 'Cancel a subscription by id.' with a specific verb and resource. It distinguishes itself from siblings like 'subscribe' and 'list_subscriptions'.

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

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

It explicitly mentions ownership enforcement ('you can only cancel your own subscriptions') and the deactivation effect. While it doesn't provide explicit when-not-to-use or alternatives, the context is clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context beyond these: it defines the verdict taxonomy (confirmed, approximately_correct, refuted, inconclusive, unsupported, could_not_verify), explains the verification_error structure, and warns that could_not_verify must not be treated as evidence. This enriches the safety and failure-mode understanding beyond what annotations alone 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 and well-structured but somewhat long. It front-loads trigger phrases, then explains routing, return values, and special caller warnings. Each sentence adds value, though the 'IMPORTANT for callers' clause could arguably be merged with the verdict definitions to reduce redundancy. Overall, it's efficient for a tool with this complexity, so a 4 is appropriate.

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 return values: a verdict, the actual value with a pipeworx:// citation, and reasoning. It also explains error handling (could_not_verify with verification_error) and differentiates unsupported. It covers both financial and non-financial routing and mentions tolerance semantics. This is complete for a verification tool with these inputs and annotations.

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

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

Schema coverage is 100%, with both claim and tolerance_pct fully documented in the schema. The description adds examples but does not introduce new parameter semantics beyond what the schema already states (e.g., tolerance_pct range and override behavior). Per the rubric, baseline 3 is appropriate when schema does the heavy lifting, and the description doesn't compensate with extra details.

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

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

The description clearly identifies the tool's purpose: natural-language claim verification against authoritative sources. It lists trigger phrases like "Is it true that…" and "fact check," and explains the two paths (SEC EDGAR/XBRL for company-financial claims, grounded pipeline for others). This distinguishes it from sibling tools like compare_entities or ask_pipeworx_grounded by explicitly stating what it verifies and how.

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

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

The description explicitly states when to use: "Use whenever the agent needs to check whether something a user said is factually correct." It also clarifies the meaning of special verdicts (could_not_verify vs unsupported) and notes that it replaces 4–6 sequential calls, giving efficiency context. No exclusions are needed because it covers both financial and non-financial claims through routing.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral details about returning validity and error info, which goes beyond annotations. No contradictions.

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

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

The description is a single, clear sentence with no redundant information. It is front-loaded with the purpose and efficiently covers key details.

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

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

For a simple validation tool with one parameter and no output schema, the description sufficiently covers purpose and return values. It could mention common pitfalls like input escaping, but overall it is adequate.

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 json parameter ('The JSON text to validate'). The description adds the qualifiers 'keyless, offline' which provide minor additional context but are not critical given the schema coverage.

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

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

The description clearly states the verb 'Validate' and the resource 'JSON string', and specifies that it works offline and returns validity, error message, and character position. It effectively distinguishes from sibling tools like format_json and query_json.

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 for validating JSON strings offline and without keys, but does not explicitly state when to use this tool over alternatives like format_json or query_json, nor does it mention when not to use it.

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