Bart

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

Annotations (readOnlyHint, openWorldHint, idempotentHint) already indicate safety, but the description adds behavioral details: probing multiple models, scoring mechanics, and that _apiKey is passed through to Anthropic. No contradictions with annotations.

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

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

The description is three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, default behavior, return format, use cases. No redundancy.

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

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

Despite no output schema, the description specifies return structure (per-model score, confidence, signals, raw_response + combined view). It covers key aspects: default model, optional Anthropic, context disambiguation, and use cases. Slightly lacking in timeout or error handling details, 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%, providing baseline. The description adds context beyond schema: explains default model, that _apiKey is passed to Anthropic (not stored), and context parameter purpose. This aids agent understanding.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and scores visibility (0-100). It specifies the default model and optional Anthropic probing. This differentiates it from sibling tools like scan_competitor_ai_presence and deep_research.

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

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

The description explicitly mentions use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It also provides context for when to pass _apiKey. However, it does not explicitly state when not to use this tool 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?

Annotations already convey read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: it routes questions, fills arguments, returns structured answers with stable citation URIs, works on every tier, and is a single fast call. It does not overclaim or contradict the annotations.

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

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

The description is front-loaded with the essential 'PREFER OVER WEB SEARCH' guidance and is well organized, but it is lengthy and somewhat repetitive. The domain list and example questions are valuable, yet the same routing message is restated multiple times ('routes to the right one', 'START HERE', 'works on every tier, one fast call'), making it less punchy than needed for a 5.

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

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

For a complex router with no output schema, the description covers what the tool does, when to use it, how it behaves, and what it returns (structured answers with citations URI). It also mentions fallback/alternative tools. It doesn't cover error behavior or output formatting in detail, but given the annotations and the tool's straightforward single-parameter input, the description is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description enriches the single 'question' parameter by listing supported domains (SEC, FDA, FRED, USPTO, clinical trials, etc.), triggering phrases, and concrete example questions. This helps the agent decide what content belongs in the parameter beyond the schema's generic 'natural language' note.

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 action: route a factual question to the appropriate one of 5,706 tools across 1,493 sources and return a structured answer with citations. It also explicitly distinguishes itself from siblings ask_pipeworx_grounded and deep_research by stating scope and output differences.

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 'PREFER OVER WEB SEARCH' and 'START HERE for most questions', then gives explicit escalation paths: use ask_pipeworx_grounded for hallucination-resistant single answers and deep_research for broad/multi-part fan-out. It also lists trigger phrases and examples, leaving no ambiguity about when the tool should be chosen.

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, openWorldHint, and non-destructive. The description adds context beyond these: it is an experimental edge with live candidate routing improvements, results are used for merge decisions, and it falls back to nothing because it is a fully functional router. This clarifies the experimental but working nature of the tool without contradicting 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?

Four sentences, each earning its place: identity and scope, current experimental state with a specific date, usage instruction, and a reassurance that it is a full working router. The information is front-loaded and dense without any redundant filler.

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

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

The description covers what the tool is, how it differs from the stable router, its current parity state, and when to use it. It references 'same response shape' without detailing the return format, but since it is explicitly identical to ask_pipeworx, an agent familiar with the sibling has enough context. No output schema exists, making that reference 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%, with all six parameters fully documented, including the canonical 'question' and its five aliases (q, text, input, query, prompt). The description adds no parameter-specific information, but the schema already carries the burden, 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 identifies the tool as the beta version of ask_pipeworx, an identical universal router with the same 5,706 tools, arguments, and response shape. It distinguishes itself from the stable sibling by its experimental status and explicitly states it is a full working router. The purpose is discernible, though it relies somewhat on prior knowledge of ask_pipeworx rather than being fully self-contained.

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

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

It gives an explicit condition: 'Use it exactly like ask_pipeworx when you want the newest routing.' This tells the agent when to choose this tool. It also reveals the current state (no active candidate, matches ask_pipeworx exactly) and that results are compared with the stable router. It doesn't explicitly say 'use ask_pipeworx for stable routing,' but the stable sibling is clearly implied as the alternative.

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

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

Annotations already signal read-only, idempotent, and non-destructive behavior, and the description adds substantial context: refusal reasons, evidence as verbatim quote, confidence, source, and the exact refusal reasons list. It also explains that the answer uses ONLY the tool result, which is critical behavioral context.

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

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

The description is dense but every sentence serves a purpose: use case, routing behavior, return contract, refusal contract, when-to-use, and cost tradeoff. It is front-loaded with the core differentiator and structured clearly with success and refusal shapes.

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 rich annotations and a simple one-required-parameter schema, the description provides everything needed to call the tool correctly: return format, refusal reasons, evidence semantics, cost implications, and clear usage guidelines. No output schema exists, so the detailed return contract is especially valuable.

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

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

Schema description coverage is 100%, and the description adds no new meaning about the question parameter beyond saying it is in natural language, which the schema already states. The routing details describe internal behavior, not parameter semantics, so a 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 identifies this as a hallucination-resistant answer mode that routes like ask_pipeworx, fetches data, and extracts answers only from tool results. It names the specific return shape and refusal behavior, distinguishing it from the casual ask_pipeworx variant.

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: whenever an answer will be quoted, cited, or acted on and the agent must not invent facts. It also gives the alternative, ask_pipeworx, for casual lookups, and mentions the cost tradeoff of one extra LLM call.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that it returns current advisories and elevator status but does not discuss data freshness, rate limits, or other behavioral details.

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 three sentences plus an example call, front-loaded with the main purpose, and contains no unnecessary information. Every sentence adds value.

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

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

For a read-only tool with no required parameters and no output schema, the description adequately conveys what the tool returns. However, it could be more explicit about the output format or data structure, though the example questions hint at the response style.

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 single optional _apiKey parameter described in the schema. The description reinforces its optionality via the example call bart_advisories({}), but adds no new semantic details 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 it provides current BART service advisories, delays, and elevator outage status, with example questions that distinguish it from sibling tools like bart_departures and bart_trip_planner.

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 example queries indicating when to use the tool, such as asking about delays or elevator outages. It does not explicitly state when not to use it or mention alternatives, but the context from siblings is clear.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint false. The description adds valuable behavioral details: real-time data, accept 4-letter codes or station names, and lists all response fields (platform, direction, train length, line color, delay, bikes allowed). No contradiction.

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

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

The description is compact (3 sentences), front-loads the key purpose, and ends with a concrete example. No redundant 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 2 parameters and no output schema, the description fully explains inputs and expected output fields. It is complete for an agent to understand and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context that station can be code or name and provides an example, but does not significantly augment the schema's parameter 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 uses a specific verb ('Real-time BART departures') and resource ('station'), lists output fields (next departure times in minutes, per destination, platform, direction, train length, line color, delay, bikes allowed). It distinguishes from sibling tools like bart_advisories and bart_trip_planner by focusing on immediate departures.

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 states the tool answers 'when is the next BART train' and gives an example query. It does not explicitly mention when not to use or compare to siblings, but the purpose is clear enough for an agent to select appropriately.

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, openWorldHint, and destructiveHint false. Description adds return fields but no additional behavioral traits 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?

Two sentences with no waste. Front-loaded with action, includes example call. 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?

Lists all output fields (code, name, city, address, coordinates). Explains filtering. Since no output schema exists, description fully explains return values.

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

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

Schema covers both parameters (100% coverage). Description adds extra context with example usage and clarifies filter matches station name or city, going beyond schema descriptions.

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

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

The description uses specific verb 'List' and resource 'all 50 BART stations' with clear output fields. It distinguishes from sibling tools like bart_departures by stating its purpose for finding station codes.

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 to find the station code for departures, trips, or fares.' Provides a concrete example with filter parameter, but does not explicitly mention 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 mark it as read-only, idempotent, and non-destructive. The description adds value by detailing the output contents (times, fare, legs) and input flexibility (codes/names). 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 three sentences, front-loading purpose and output, then providing an example. Every sentence is informative with no redundancy.

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

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

Despite no output schema, the description explains what the tool returns and how inputs work. It could mention default trips or optional API key, but overall it is complete for the tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description reinforces input formats with examples but does not add new semantic meaning beyond the schema.

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

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

The description clearly states it plans a BART trip between two stations, specifying return details like departure/arrival times, duration, legs, and fare. It distinguishes from sibling tools like bart_departures by focusing on end-to-end trips.

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 examples of typical trips but does not explicitly state when to use this tool over alternatives like bart_departures or bart_advisories. Usage is implied but lacks explicit 'when-not-to' or alternative guidance.

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

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

The description richly details behavioral traits beyond annotations: resolution contract with confidence levels, parent event extraction, news fallback mechanisms, safety tripping for low confidence, handling of closed markets, wide spread warnings, and cancellation rule parsing. Annotations only indicate readOnly and idempotent; the description adds extensive operational context.

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

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

The description is comprehensive but verbose, containing many detailed sections (RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, NEWS FIELDS, SAFETY, etc.). While each sentence adds value, the length could be streamlined for quicker agent reading. It is well-structured with clear headings but sacrifices conciseness for completeness.

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

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

Given no output schema, the description thoroughly explains all response fields (result.market, result.analysis, result.evidence), edge cases (low-confidence matches, closed markets, wide spreads), and special behavior (cancellation rules, news fallback). It fully prepares the agent for what to expect, leaving no significant gaps.

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

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

With 100% schema coverage, the description adds significant meaning: it explains the input formats (slug, URL, question), the depth parameter's effect ('quick' vs 'thorough'), and the include_raw parameter's impact on response size. Examples further clarify usage. This goes 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 researches Polymarket bets by pulling Pipeworx data, specifying inputs (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison). It distinguishes from sibling tools like ask_pipeworx by targeting betting decisions ('should I bet on X'), making its purpose specific and unambiguous.

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

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

The description explicitly lists use cases ('should I bet on X', 'what does the data say about Y', 'is there edge in Z'), providing clear when-to-use guidance. It does not explicitly name alternative tools for different cases, but the use cases are well-defined and contextually differentiate from siblings.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds valuable behavioral context: it specifies data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), mentions handling of off-calendar fiscal years, and notes that results are sorted by primary metric. This goes 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 front-loaded with trigger phrases and key action. It is somewhat lengthy but each sentence adds value. Could tighten minor redundancies but overall well-structured for AI agent parsing.

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 the description partially covers return values (paired data + citation URIs). However, it lacks details on response structure, what happens if data is missing or an entity is not found, and any error handling. Given the tool's complexity, more completeness would be beneficial.

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

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

Schema coverage is 100% with clear descriptions. The description adds meaning by explaining what each 'type' value retrieves (e.g., company gets latest 10-K revenue, net income, etc.; drug gets FAERS counts, trial counts) and gives examples for 'values'. This enhances the schema descriptions.

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

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

The description clearly states the tool performs side-by-side comparisons of 2-5 companies or drugs in a single call, using explicit trigger phrases like 'compare X and Y' and 'which is bigger'. It distinguishes itself from sibling tools like entity_profile by emphasizing parallel lookup over sequential lookups.

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

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

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', providing strong usage guidance. It also lists example queries. However, it does not mention when NOT to use it (e.g., when needing non-financial/drug data) or alternatives like deep_research for more comprehensive analysis.

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

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

Annotations already indicate read-only, idempotent, and open-world behavior, and the description adds substantial behavioral detail beyond that: parallel routing across thousands of tools, gap[] reporting with no invented findings, contradictions[] for standard/thorough, per-hop fields, semantic excerpting rather than head-truncation, and latency expectations. It also clarifies that this is NOT open-web search, which directly informs agent expectations. No contradiction with annotations exists.

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

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

The description is long, but every sentence contributes: account constraints, primary use, alternative routing, output format, behavior on missing data, depth semantics, citation resolvability, and latency. It is front-loaded with the most decision-critical facts (account requirement and alternative tool) and contains 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?

For a tool with only two parameters and no output schema, this description is unusually complete. It covers prerequisites, alternatives, input semantics, output structure, edge-case behavior (gaps[], contradictions[]), citation guarantee, and performance expectations. An agent has everything needed to select, invoke, and interpret results correctly.

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

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

Schema coverage is 100% and both parameters are already described well. The description adds meaningful extra semantics for the depth parameter: quick=3 facets single hop, standard=default gap recovery + contradictions, thorough=paid 6 facets with iterative lead-chasing. This goes beyond the schema's brief enum descriptions and helps the agent pick the right depth for the task.

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 action ('grounded multi-source research') on a concrete resource (Pipeworx structured data sources), and clearly distinguishes itself from open-web search and from ask_pipeworx. It also states the return artifact (findings packet with evidence, confidence, source, citation), so an agent knows exactly what the tool produces.

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

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

The description provides explicit when-to-use guidance ('Best for broad/multi-part questions over structured data'), explicit when-not-to-use guidance (breaking news / colloquial current events), and names alternatives (ask_pipeworx for single lookups and live news). It even handles the signed-out condition and paid-tier requirement, leaving no ambiguity about when this tool should be selected.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: returns top-N tools with names, descriptions, full schemas, and curated examples, and states each result is ready to call directly without extra schema lookup. 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 4-5 sentences, front-loaded with purpose, followed by domain examples and behavioral highlights. Every sentence adds value, no redundancy. Efficiently communicates core functionality and 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?

While there is no output schema, the description explains what is returned (top-N tools with names, descriptions, full schemas, examples) and how to use the results. It covers the key aspects an agent needs: when to call, what to expect, and how results enable direct invocation. Minor gap: no mention of output format (e.g., JSON).

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 6 parameters (query, q, task, limit, search, description) with descriptions. The description adds no extra meaning beyond mentioning 'curated examples' in output. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It provides specific domain examples and distinguishes itself from sibling tools by focusing on discovering tools themselves, not retrieving data. The description emphasizes returning ready-to-call results with schemas, differentiating it from search tools like search_within or deep_research.

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

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

The description explicitly states when to use: 'Use when you need to browse, search, look up, or discover what tools exist for: ...' and advises calling this FIRST when many tools are available. It does not explicitly mention when not to use or alternatives, but the context of being a discovery tool among many data-retrieval siblings implicitly guides the agent.

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, etc.), the description discloses specific behaviors: patents sunset May 2025 (soft-fails), multiple data sources (SEC, XBRL, USPTO, news, GLEIF), and that it returns specific fields. No contradictions with annotations.

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

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

The description is a single paragraph but well-structured with example queries upfront. Every sentence adds value, though it is somewhat dense. It could be slightly more scannable with bullet points, but remains effective.

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

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

Given 2 parameters, no output schema, and the tool's complexity (multiple data sources, limitations), the description is remarkably complete: it explains inputs, outputs, usage guidance, and known issues like patents sunset. No gaps remain.

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

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

Schema covers both parameters with descriptions (type enum, value string). The description adds context: ticker or zero-padded CIK, and crucially that names are not supported. Since schema coverage is 100%, the description enriches but doesn't carry the full burden.

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

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

The description clearly states it provides a holistic 'full cross-source profile of a US public company' with specific data sources and outputs. It distinguishes itself from chaining multiple single-pack lookups, making the purpose unambiguous.

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

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

Explicitly advises when to use ('ALWAYS PREFER over chaining...') and when not to ('names not supported — use resolve_entity first'). Also mentions the tool is for a holistic view in one call, providing clear context 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 destructiveHint=true and readOnlyHint=false, so the description aligns. It adds context that deletion applies to 'previously stored memories' and 'clear sensitive data', which is consistent but doesn't go far beyond annotations.

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

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

Two sentences front-loaded with purpose and usage. No redundant information; every word earns its place. Highly concise and well-structured.

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

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

For a simple tool with one parameter and no output schema, the description fully covers purpose, usage, and relation to siblings. It is complete and sufficient for correct invocation.

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

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

Schema coverage is 100% with the 'key' parameter described as 'Memory key to delete'. The tool description mentions 'by key' but adds no new semantic details beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the action 'Delete' and the resource 'memory' identified by 'key'. It also distinguishes from sibling tools 'remember' and 'recall' by mentioning pairing with them, providing clear differentiation.

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: 'when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' Also advises to pair with 'remember' and 'recall', offering clear context and complementary usage.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds significant context beyond annotations: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format', and specifies the output is a single text blob ready for deployment. 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 with a bulleted list of use cases. It is front-loaded with the main purpose, and every sentence adds value without redundancy. Highly efficient.

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

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

For a tool with 2 parameters, 100% schema coverage, and no output schema, the description fully covers functionality, behavior, output format, and use cases. The sibling tools are diverse but none require additional differentiation. The description is complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by specifying default (25) and maximum (50) for 'max_links', which is not in the schema. The 'url' parameter is adequately described in both schema and description.

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

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

The description clearly states the verb ('Generate'), resource ('production-ready llms.txt file'), and scope ('for any URL'). It also differentiates from sibling tools by focusing on a specific file format, making the tool's purpose unambiguous.

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

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

The description explicitly lists use cases ('getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor'), providing clear context for when to use the tool, though it does not explicitly state when not to use it 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?

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds the specific return fields. No contradiction, but adds minimal behavioral context beyond annotations.

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

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

Two sentences, no redundant words, highly efficient. All information 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 good annotations, single optional param, and no output schema needed. Description is complete enough for safe usage. Could mention pagination 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 has 100% coverage with description for 'include_inactive'. Description does not add additional meaning beyond the schema's parameter description.

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

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

Description clearly states 'List the caller's active subscriptions' and lists return fields. It distinguishes from siblings like subscribe and unsubscribe.

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

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

Explicitly states when to use: 'review what you're monitoring before adding more or to find an id to cancel'. No when-not, but sufficient for a simple read tool.

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

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

The annotations are all false, providing no behavioral hints, so the description carries the full burden. It discloses the claim_token flow (filing without an account returns a token; passing it back later reads resolution status), rate limits (5 per identifier per day), and the fact that feedback is read in daily digests and affects roadmap. These are concrete behavioral traits well beyond what annotations convey.

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

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

The description is longer than ideal but every sentence adds a distinct piece of information: purpose, usage triggers, exclusion scope, token mechanics, rate limits, and cost. It is front-loaded with the primary purpose and uses clear separators (em-dashes, semicolons) to structure the content. It earns its length given the number of operational 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?

With no output schema or required parameters, the description covers the full interaction lifecycle: what to submit, how to handle the response (claim_token), and what happens afterward (daily digest, roadmap impact). It also covers rate limiting and quota exemption. For a tool with 4 optional parameters and nested context, this is comprehensive.

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 a baseline of 3 applies. The description adds meaningful nuance beyond the schema: it explains how the claim_token parameter is used for follow-up ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed'), and advises describing issues in terms of Pipeworx tools/packs rather than pasting user prompts. This enriches parameter understanding beyond the schema's field descriptions.

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

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

The description opens with a clear verb and resource ('Tell the Pipeworx team something is broken, missing, or needs to exist'), establishing this as a feedback submission tool. It distinguishes itself from all sibling tools by naming specific feedback categories (bug, feature/data_gap, praise) and explicitly scoping to Pipeworx connection 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 states when to use the tool ('Use when a tool returns wrong/stale data...', 'when a tool you wish existed isn't in the catalog...') and when NOT to use it ('ONLY for tools served by this Pipeworx connection... file it with that server instead'). It also provides a disambiguation heuristic for uncertain agents ('Pipeworx tool names are the ones this connection lists').

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds valuable context: data source (CF analytics-engine), no PII, caching behavior (5min-1h), and self-aggregating nature. 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?

Front-loaded with output, followed by use cases, then implementation details. Efficient with no wasted words, though use cases could be slightly more concise. Good structure 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?

Given simple tool (1 param, no output schema, rich annotations), description covers purpose, usage, behavior, privacy, caching. Return values are implicitly described. Complete for correct agent invocation.

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

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

Schema accounts for 100% of parameters with enum and description. Description doesn't add new semantics beyond restating window purposes. Baseline 3 is appropriate per rubric.

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

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

Description clearly states it returns 'top tools, top packs, and total call volume' with specific verb 'returns' and resource 'trending on Pipeworx'. Distinguishes from sibling tools like ask_pipeworx and discover_tools by focusing on aggregation and usage frequency.

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?

Lists three explicit use cases (discovering hot data, confirming canonical tool, aligning use case) and explains window choice (shorter for hot, longer for steady-state). Lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds rich behavioral context: the logic of monotonicity and partition checks, Jaccard similarity threshold, placeholder filtering, and fill check with realizable_edge_pp. No contradiction with annotations.

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

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

The description is front-loaded with the purpose and then details modes, behavior, and response. It is dense but each sentence adds unique value. Could be slightly more concise, but it's well-structured for the complexity.

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

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

Given the absence of an output schema, the description thoroughly covers the return format including fields like gap_pp, suggested_trade, reasoning, and partition_check details. It also explains fill check logic and references sibling tool for further use. Complete for an agent to understand and invoke correctly.

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

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

Both parameters have 100% schema coverage. The description adds meaningful context: event parameter accepts full URLs, topic parameter triggers cross-event search. It provides examples (e.g., 'fed-decision-may-2026') and explains the behavior associated with each parameter, going 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 starts with a clear verb-resource-method statement: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It distinguishes itself from sibling tools (e.g., polymarket_fill_risk for custom sizing) and explains its specific domain within 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?

Explicitly states when to use each mode: no args for trending scan, event for specific market, topic for cross-event. It explains the advantage of cross-event mode and advises when not to trade based on fill check. Also references polymarket_fill_risk for custom sizing, providing clear alternatives.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, etc. The description goes well beyond these disclosures, detailing caching behavior ('Cached 1h at the KV level'), edge calculation methodology (e.g., partition_overround with per-sport α, concentrated_longshot gates), and structural details like the exclusion of Fed bets due to data reliability. This provides rich behavioral context without contradicting 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 verbose and dense, with multiple paragraphs of technical detail. While it front-loads the purpose, the length may overwhelm agents. Although the structure is logical (segments, response layout, knobs), the conciseness is sacrificed for completeness. A more concise version could improve usability.

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

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

Given the complexity (9 parameters, no output schema), the description is remarkably complete. It explains the response structure (by_segment, diagnostics, fed_note), edge case handling (why segments may be empty, filter_skips), and parameter interplay (e.g., tradeable-edge knobs). It leaves no obvious gaps for an AI agent to understand how to use the tool effectively.

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 each parameter already has a description. The tool description adds significant meaning: for example, it explains the default slippage (0.3pp) with context about Polymarket's fees and liquidity, and describes how min_kelly and min_partition_leg_kelly interact. This goes beyond what the schema alone provides, helping the agent select and set parameters appropriately.

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

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

The description clearly states the tool's purpose: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It specifies the verb ('scan'), resource ('top Polymarket markets'), and outcome ('return opportunities'), and is tailored to the use case 'what should I bet on today.' Although it does not explicitly contrast with sibling tools, the level of detail and distinctiveness make the purpose unmistakable.

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

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

The description provides guidance on when to use the tool ('what should I bet on today'), explains its advantage ('agents discover opportunities without paging hundreds of markets'), and includes parameter usage advice (e.g., slippage_pp: 'Bump for very thin partitions; drop to 0 if you have a smarter fill model'). It does not explicitly state when not to use or list alternatives, but the context is sufficient for an AI agent to understand appropriate usage.

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

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

Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds significant context: response structure (tracked, expired, snapshot_dates), what decay numbers represent (daily closes, not intraday), and limitations (history bound by 60-day TTL, from snapshot enablement). 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 information-dense but efficiently structured, starting with purpose and then providing details on parameters, response, and limitations. It could be slightly more concise, but every sentence adds value.

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

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

Given no output schema, the description fully explains the response structure and fields. It covers purpose, parameters, usage context, limitations, and behavioral details. Complete for a telemetry tool with simple parameters.

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 already covers both parameters with descriptions. The description adds context: 'days' is lookback with max 30 (schema says clamp 2-30), 'window' is snapshot family. It explains that snapshots are written on cache-miss, adding meaning beyond schema.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily snapshots. It answers a specific question about edge longevity and distinguishes from sibling tools like polymarket_edges which likely just lists 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 context that a fresh wide edge differs from an older one, implying when to use this tool to evaluate edge age. However, it does not explicitly state when to use this tool versus alternatives like polymarket_edges or polymarket_arbitrage, nor does it provide exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive. The description adds rich behavioral context: walking the ladder, returning verdicts, and listing outputs like slippage, fill details, and directional risk. 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 verbose but well-structured with clear section headers for SINGLE-MARKET and BASKET. Every sentence adds value, but length could be trimmed slightly for conciseness.

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

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

Fully addresses complexity with two modes, no output schema. Describes all returned fields for each mode, warns about risks, and explains when to use. Complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, baseline 3. The description adds significant meaning: explains mode-dependent defaults, interpretation of size_usd for buys vs sells, and how side auto-selects for basket mode. This elevates understanding beyond schema.

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

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

The description clearly states it performs a 'realizable-vs-theoretical edge check' against order-book depth, distinguishing between single-market and basket modes with specific outputs. It explicitly differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by stating when to use it.

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

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

Explicit guidance is provided: use before acting on polymarket_arbitrage signals or trades above ~$500. It explains modes (requires market or event) and warns about risks of partial fills converting arb to directional position. No confusion about when to use.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, and the description adds high-value behavioral detail: unclassified legs are never paired, cross-type/cross-subtype skips are counted, temporal_alignment indicates calendar-period matching, and per-entry flags qualify spread confidence. This goes well beyond the annotation set and clarifies output semantics.

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

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

The description is front-loaded with the core purpose and uses clear TWO MODES/RESPONSE markers, but it is long and contains the placeholder-like artifact '[then flags list]' and densely packed parenthetical flag details. Most sentences earn their place, but the structure is not as clean as it could be.

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

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

With no output schema, the description carries the full burden of explaining the response, and it does: leg-by-leg prices, top_spreads_pp, per-entry flags, temporal_alignment, skipped counters, and compatibility warnings. An agent has enough detail to call the tool and interpret the result without additional documentation.

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

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

Schema description coverage is 100% and each parameter already has a helpful description. The tool description adds important mode semantics: topic auto-fetches matching events on both venues, while explicit ticker/slug override the mapped side. This is meaningful added context, so it rises above baseline, though it is not exhaustive for every edge case.

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

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

The first sentence names a specific operation and resource: computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes from siblings by focusing on same-question cross-venue comparison and describing the two modes (topic shortcuts vs explicit ticker/slug).

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

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

The description gives clear context for when to use each mode and warns that most pre-mapped topics currently return compatibility_warning, so pre-mapped does not mean tradeable. It does not name alternative sibling tools explicitly, but the mode-level guidance is concrete 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=true, idempotentHint=true, destructiveHint=false. The description adds that the tool is scoped to an identifier and that omitting the key lists all keys, providing behavioral context beyond annotations.

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

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

The description is concise at two sentences, with no redundant information. It front-loads the purpose and uses efficient phrasing.

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

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

The description covers retrieval and listing behavior, and explains the scope. Without an output schema, it provides enough context for the agent to understand what the tool returns. Minor gaps like error handling are not critical for a simple read tool.

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

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

Schema coverage is 100% with one optional parameter. The description adds meaning by stating 'omit to list all keys' and includes examples, clarifying the parameter's behavior beyond the schema.

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

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

The description clearly states the tool retrieves a value saved via remember or lists all keys when omitted. It distinguishes from sibling tools remember and forget, and provides concrete examples of use cases.

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

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

The description explains when to use the tool (look up stored context) and mentions pairing with remember/forget. It does not explicitly state when not to use it or list alternatives, but provides sufficient 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?

Descriptions adds details beyond annotations: explains each returned field (source, citation_uri, payload), the effect of mark_read on read status, and that polls work fine. No contradiction with annotations (readOnlyHint=true, etc.).

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

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

The description is a single paragraph of four sentences, each earning its place: purpose, return structure, filtering, mark_read and polling alternative. 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?

Coverage is excellent: explains return fields, all filtering options, side effect of mark_read, and alternative access. Minor omission of unread_only parameter explanation, but schema covers it. For a tool with 5 parameters and no output schema, this is very complete.

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

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

Although schema has 100% description coverage, the description adds valuable context like example values (e.g., 'sec_8k' for type) and clarifies ISO timestamp format for since. It also explains mark_read effectively.

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 'Pull fired events from your subscription feed', clearly stating the verb (pull) and resource (fired events). This distinguishes it from sibling tools like list_subscriptions or subscribe.

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

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

The description provides clear context: filtering by type and since, and the mark_read behavior. It also mentions polling works fine and gives an alternative API endpoint for scripts/dashboards. However, it does not explicitly contrast with siblings 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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds richer behavioral context: fans out to multiple data sources (SEC, GDELT→GNews, USPTO), describes fallback logic (GNews when rate-limited), and notes soft-fail for USPTO. 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, well-organized paragraph. It front-loads purpose with examples, details sources and fallbacks, explains parameters and return structure, and ends with sibling 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?

Despite no output schema, the description clearly states the return format: 'structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs'. It covers inputs, sources, fallbacks, and output, leaving no critical gaps.

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

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

Schema coverage is 100%, but the description adds value by explaining the 'since' parameter formats (ISO date, relative shorthand like '7d', '30d'), providing usage recommendations ('Use "30d" or "1m" for typical monitoring'), and clarifying that 'value' can be ticker or CIK.

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 concrete query examples ('What's new with X'), then states 'change feed for a company in the last N days/weeks/months in ONE parallel call', clearly defining the tool's purpose and scope. It also distinguishes from sibling 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?

Provides explicit guidance on when to use this tool vs entity_profile: 'Use entity_profile instead when you want the static profile...'. It also gives example queries but does not exhaustively list 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 declare idempotentHint=true and destructiveHint=false, so safety profile is clear. Description adds valuable context: scoping by identifier, persistence duration (24h for anonymous), and that it's a key-value store. 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?

Four sentences, each providing distinct value. Front-loaded with the core action and purpose. No redundant information.

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

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

For a simple tool with 2 required params, no output schema, and annotations present, the description covers all necessary context: when to use, what is stored, scoping, persistence, and pairing with siblings.

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 good descriptions for both key and value. The description adds example key patterns and clarifies value can be any text, which is helpful but not essential.

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 'Save data' as the verb with 'memory' as the resource, clearly indicating write operation. It explicitly distinguishes from sibling tools 'recall' and 'forget' by mentioning them.

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

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

Provides explicit guidance: 'Use when you discover something worth carrying forward'. Also indicates when not needed and directs to alternatives: 'Pair with recall to retrieve later, forget to delete'. Notes scoping and persistence differences.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds substantial behavioral detail: identifiers are source-labeled, unresolved identifiers are explicitly stated, and GLEIF/OpenFIGI enrichment degrades gracefully. This is valuable context the annotations do not cover.

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

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

The description is dense and packed with useful information, with no filler. However, it is a single long paragraph that begins with query examples rather than a crisp definition, making it slightly less front-loaded and harder to scan than it could be.

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

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

Given the tool's complexity (two entity types, multiple data sources) and the lack of an output schema, the description carries the full burden of explaining return behavior, fallback mechanisms, and edge cases like ISIN resolution. It thoroughly covers all necessary context for an agent to invoke and interpret results.

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

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

Although the schema already covers 100% of parameters, the description enriches meaning significantly: it explains accepted input formats for 'value' (ticker, CIK, ISIN, brand name), defines the two 'type' enums, and details what each resolves to (e.g., ISIN-to-LEI mapping, RxNorm output). This goes well beyond the schema's basic field descriptions.

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

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

The description clearly defines the tool's purpose with a specific verb ('resolve') and resource ('user-spoken NAME to canonical/official identifiers'). It provides concrete example queries and positions itself as the go-to tool for name-to-ID lookup, distinguishing it from siblings like entity_profile or compare_entities.

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

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

It explicitly instructs to 'Use FIRST whenever you have a name but need an ID' and explains what the tool replaces. However, it does not name alternative tools or provide explicit 'when not to use' guidance, so it falls slightly short of a perfect score.

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 details behavior beyond annotations: it calls ai_visibility_check per entity, ranks by score, and returns metrics (score, confidence, signal density). Annotations already state readOnly, openWorld, idempotent, non-destructive; description adds value without contradiction.

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

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

Two sentences succinctly cover purpose, mechanics, and output. No wasted words; information is front-loaded and actionable.

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 clearly states return format (ranked list with score, confidence, signal density). Parameter descriptions in schema are complete. Overall, the description equips an agent to use the tool correctly.

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

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

Schema covers 100% of parameters, but description adds meaning: 'First entry treated as the subject for narrative; rest are competitors' and explains context as shared disambiguation. This adds usage nuance beyond schema definitions.

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

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

Description uses specific verbs ('Compare AI visibility', 'probes', 'ranks', 'surfaces') and specifies the resource ('multiple entities side-by-side'). It clearly distinguishes from sibling ai_visibility_check (single entity) and compare_entities (generic comparison).

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

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

Description provides clear usage context ('competitive AI-marketing audits') and an example question. However, it does not explicitly mention when not to use this tool or suggest alternatives like ai_visibility_check for single entities.

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

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

Beyond the annotations that already indicate safety and idempotency, the description adds critical behavioral details: composite fan-out, partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, and sources_failed will list timeouts. No contradiction with annotations.

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

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

The description is well-structured with key information front-loaded (composite nature, use cases). It is relatively long but every sentence adds necessary detail. Could be slightly more concise but still effective.

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

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

Despite the absence of an output schema, the description thoroughly details the return value (summary block, per-advisory detail, links, alternative versions) and handles edge cases like partial failures, timeouts, and ecosystem limitations. 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining that scoped packages are accepted and clarifying the default behavior for version, which raises the score slightly above baseline.

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

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

The description clearly states that the tool performs a composite check for npm packages, combining data from deps.dev and bundlephobia. It explicitly differentiates from sibling tools by specifying it's for npm only and mentions alternatives for other ecosystems.

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 and actionable usage guidance: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me".' It also clarifies when not to use (other ecosystems) and names the alternative tool.

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

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

Adds rich behavioral details beyond annotations: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char cap, truncation flagging, and offset per passage.

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?

5 sentences, front-loaded with core purpose, no wasted words, each sentence earns its place.

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

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

Completely covers semantic search behavior, model details, constraints, and output characteristics despite no output schema.

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

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

Adds meaning beyond schema: text max ~200K chars, query as natural-language, limit default 5. Schema coverage already high but description enhances.

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

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

Description clearly states 'Semantic search INSIDE a fetched record' with specific verb and resource. Distinguishes from siblings like ask_pipeworx_grounded.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and mentions pairing with ask_pipeworx_grounded, providing clear when-to-use and 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 indicate non-read-only, non-destructive, idempotent, open-world. Description adds delivery details, webhook signing, auto-disable after failures. Does not clarify idempotency behavior for duplicates, but provides substantial context beyond annotations.

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

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

Well-structured: purpose first, then requirements and types, then delivery. A bit long but every sentence adds value. Could be slightly tightened.

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?

Explains return value but not full response structure or error scenarios. No output schema, so description should compensate more. Lacks some details for a complex subscription 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 already covers 100% of parameters, but description adds practical examples and constraints per type (e.g., items for sec_8k, delivery restrictions). Adds value beyond schema.

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

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

The description clearly states the action ('create a proactive monitoring subscription'), resource ('live-data event stream'), and return value ('Returns the new subscription id'). It distinguishes from sibling tools like list_subscriptions and unsubscribe.

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

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

Provides clear context: requires Pipeworx OAuth account, lists supported subscription types with examples, explains delivery channels and prerequisites. Lacks explicit when-not-to-use or alternative tool references, but usage is well-defined.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) already cover safety and behavior. Description adds context about returning live catalog examples and categories, but doesn't mention side effects or rate limits.

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

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

Description is information-dense and front-loaded with question variations, but slightly lengthy. Still, each sentence adds value and the structure is clear.

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 explains output categories and usage context. Could mention limits or pagination but overall 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 already describes 'topic' with values; description adds a full list of focus areas and clarifies that omitting gives cross-category spread. This enriches meaning beyond the schema.

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

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

The description states the tool returns category-bucketed example questions with tool+argument shapes, and distinguishes it as an onboarding entry point from siblings like 'ask_pipeworx' and 'discover_tools'. It is specific and clear.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do' and explains when to pass topic vs no arguments. Provides clear guidance for appropriate usage.

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

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

The description explains that the row is deactivated, not deleted, preserving historical events via recent_alerts. This adds context beyond annotations (destructiveHint=false, idempotentHint=true) and discloses behavioral traits clearly.

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 key action, no wasted words. Each sentence contributes essential information.

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

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

Given a single parameter, no output schema, and good annotations, the description covers all necessary context: what it does, ownership, and side effects. Complete for this tool.

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

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

Schema coverage is 100% with a clear description of the 'id' parameter. The tool description does not add parameter-specific meaning beyond the schema, so baseline 3 is appropriate.

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

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

The title 'Unsubscribe from Alerts' and description 'Cancel a subscription by id' clearly state the verb and resource. It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

It specifies ownership enforcement: 'you can only cancel your own subscriptions.' This guides when to use the tool, though it does not explicitly mention alternatives or 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?

Beyond the annotations (read-only, idempotent, open-world), the description discloses critical behavioral details: the dual routing path (SEC EDGAR vs. grounded pipeline), the full list of possible verdicts, and explicit semantics for 'could_not_verify' (not evidence, carries verification_error). This is valuable transparency that prevents misuse.

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

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

The description is dense but well-structured, front-loading the purpose and usage triggers. While the list of six trigger phrases is slightly repetitive, every subsequent sentence earns its place by explaining routing, return values, and error semantics.

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

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

Given the tool's complexity and lack of an output schema, the description covers the key return elements (verdict, actual value, citation, reasoning) and error conditions. It could be more explicit about the 'pipeworx://' citation format and the exact structure of 'verification_error,' but overall it is sufficiently 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?

The schema already covers both parameters with detailed descriptions (100% coverage), so the description adds little direct parameter guidance. It provides example claims and mentions 'percent-delta math' but doesn't explain the tolerance_pct parameter specifically, which is already well-defined in the schema.

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

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

The description immediately identifies the tool as 'natural-language claim verification against authoritative sources' with explicit trigger phrases. It distinguishes from siblings by focusing on verifying the truth of a single claim, including a specialized financial fast path and a grounded pipeline for other claims.

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 'Use whenever the agent needs to check whether something a user said is factually correct,' providing a clear context. It also explains the routing for financial vs. non-financial claims, but it does not explicitly name alternatives or state when not to use this tool.

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