Horizons Nasa

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

Beyond annotations (readOnly, idempotent), description adds return structure (per-model and combined view), pricing details (free vs paid), and that Anthropic requires own key. No contradictions.

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

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

Two sentences, front-loaded with action and purpose, every phrase earns its place. 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?

Despite no output schema, description explains return fields and structure clearly. Covers key aspects for agent decision-making.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds useful context (default model, API key necessity, context disambiguation) but does not dramatically surpass schema detail.

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 precise verb 'probe' and resource 'LLMs', specifies scoring visibility 0-100 per model, and clearly distinguishes from sibling tools like deep_research or scan_competitor_ai_presence by focusing on AI brand visibility.

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

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

Clearly states use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) and explains default vs BYO key model usage. Lacks explicit when-not-to-use, but context is sufficient.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond that: it explains the routing behavior, that it fills arguments, returns stable citation URIs, is fast, and works on every tier. This goes beyond the safety annotations without contradicting them, though it doesn't cover edge cases like failure modes 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?

The description is substantial but well-organized: it opens with a strong 'PREFER OVER WEB SEARCH' directive, lists supported domains, gives examples, and explains when to step up to alternatives. There is some repetition (e.g., 'PREFER...' and 'Use whenever...' and 'START HERE' all make the same point), but it remains purposeful and front-loaded.

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

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

Given the tool's complexity, the description is remarkably complete. It covers what the tool does, when to use it, what it returns (structured answer with citations), and how it differs from siblings. No output schema exists, but the description still gives a clear picture of the return format and typical use cases, making it sufficient for an agent to select and invoke 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 description coverage is 100% with the 'question' parameter and aliases all documented. The description does not add parameter-level detail beyond what the schema already provides, but the schema does the heavy lifting. 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: it routes questions to the appropriate tool among 5,529 across 1,455 verified sources and returns a structured answer with citations. It also distinguishes itself from siblings by pointing to ask_pipeworx_grounded and deep_research as alternatives for specific cases, so there is no ambiguity.

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

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

The description explicitly says to prefer this tool over web search for factual/current-data questions and lists concrete trigger phrases and examples. It also gives alternative tools for specific scenarios (grounded for hallucination resistance, deep_research for broad/multi-part queries), fulfilling both 'when to use' and 'when not to use' guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable nuance: it is an experimental edge, candidate routing improvements are only active when under test, currently none are active so it matches the stable router, and it is a full working router (falls back to nothing). This goes well 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 concise and well-structured, with the core purpose stated first. It efficiently conveys key details (experimental status, current equivalence, usage guidance) in four sentences without unnecessary 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 six parameters (all aliases), no output schema, and rich annotations, the description is complete. It explains the tool's relationship to ask_pipeworx, its experimental nature, current behavior, and usage context, making it fully actionable for an agent.

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

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

Schema coverage is 100% with all parameters documented as aliases for 'question'. The description does not add parameter-level detail, but it is not needed because the schema already fully explains the parameters. Baseline 3 is appropriate.

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

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

Description clearly states it is a beta version of ask_pipeworx, an identical universal router with the same 5,529 tools, arguments, and response shape. It distinguishes from siblings by emphasizing the experimental routing improvements and current equivalence to the stable router.

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 instructs to 'Use it exactly like ask_pipeworx when you want the newest routing' and notes current behavior matches ask_pipeworx exactly. It does not explicitly state when not to use it or name alternatives beyond ask_pipeworx, but the context is clear and practical.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, but the description adds substantial behavioral context: the return contract with evidence, confidence, source, fetched_at; the refusal_reason enum; the guarantee of using only tool result content; and the cost of an extra LLM call. This goes far beyond the annotations and does not contradict them.

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

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

The description is dense but every sentence earns its place: purpose, routing mechanism, return format, refusal behavior, usage guidance, and cost comparison. It is well-structured with a logical flow from definition to details to alternatives, with no filler or redundancy.

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

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

Despite the absence of an output schema, the description explicitly provides the full return shape and refusal reasons, making the tool's behavior predictable. It also covers when to use it, when not to, the relationship to ask_pipeworx, and the performance cost, making it complete for a complex routing 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?

The schema fully documents the single logical parameter 'question' and all its aliases (q, text, input, query, prompt), achieving 100% coverage. The description adds no additional parameter-level semantics beyond restating that it is a natural-language question, so the baseline of 3 is appropriate.

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

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

The description opens with 'Hallucination-resistant answer mode for high-stakes reads,' a specific verb+resource that immediately communicates the tool's core function. It then details the extraction mechanism ('EXTRACTS the answer using ONLY what the tool result contains') and explicitly distinguishes itself from the sibling ask_pipeworx by noting the extra LLM call and preference for casual 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?

Usage guidance is explicit: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' with concrete examples (financial verdicts, legal claims, medical lookups). It also provides a clear exclusion: 'prefer ask_pipeworx for casual lookups,' directly naming the alternative and when to choose 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?

The annotations already indicate it is read-only, idempotent, and non-destructive. The description adds extensive behavioral details: how it resolves markets, handles low-confidence matches (blocking analysis fields), closed markets, wide spreads, cancellation rules, and error states (GDELT 429 fallback). There is 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 extremely detailed with many sections (RESOLVER CONTRACT, PARENT_EVENT EXTRACTOR, etc.), making it a wall of text. While well-structured, it is not concise; some detail could be streamlined without losing essential information. An AI agent may find it overwhelming to parse quickly.

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

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

Given the tool's complexity (multiple evidence sources, edge cases, response shapes), the description is remarkably complete. It covers all scenarios: low-confidence matches, closed markets, wide spreads, cancellation rules, and fallback mechanisms. Without an output schema, the description fully explains return values and error states.

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

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

The input schema has 100% description coverage for all three parameters. The description adds significant meaning beyond the schema: it explains the 'market' parameter accepts slugs, URLs, or question text; describes 'depth' values (quick vs thorough) and their impact; and clarifies 'include_raw' with size implications and when to use true. Examples reinforce 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 researches Polymarket bets by pulling Pipeworx data. It uses specific verbs ('research', 'pull', 'resolve', 'classify', 'fan out') and identifies the resource ('Polymarket bet', 'Pipeworx data'). It distinguishes from sibling tools like polymarket_edges and polymarket_arbitrage by providing explicit use cases ('Use for "should I bet on X"...').

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

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

The description provides clear usage guidance with examples ('Use for "should I bet on X"...') and explains the tool's purpose. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, leaving some ambiguity for an AI agent selecting among multiple Polymarket-related tools.

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

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

Beyond annotations (readOnly, idempotent), description adds: data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and return of paired data with citation URIs.

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

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

Description is dense with useful information and front-loaded with examples. Slightly verbose but every sentence contributes value. Could be tightened slightly without losing clarity.

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

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

For a 2-param tool with no output schema, the description covers data sources, sorting behavior, citation URIs, and even fiscal year handling. No gaps in understanding what the tool does and returns.

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

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

Schema has 100% coverage, but description adds significant meaning: for type, explains what data each entity type pulls (revenue, net income, etc. for companies; adverse events, approvals, trials for drugs). For values, specifies format (tickers/CIKs for company, names for drug) and constraint (2-5 items).

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 does side-by-side comparison of 2-5 companies or drugs, with specific query examples like 'X vs Y' and 'rank these companies'. It distinguishes itself from siblings like entity_profile for single lookups.

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

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

Explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', providing clear when-to-use guidance. Also states it replaces 8-15 sequential lookups, reinforcing efficiency.

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

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

Discloses rich behavioral context beyond annotations: requires account (free, paid for thorough), never invents data, explicit gaps[] for unanswered facets, hop field, citation_uri resolvability, contradictions[] for standard/thorough, semantic excerpting rather than head-truncation, expected latency (15-60s, up to ~90s). This far exceeds what readOnlyHint/openWorldHint/idempotentHint already say, and the annotations are consistent (read-only, open-world, idempotent are all supported by the description).

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

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

The description is dense and front-loaded with the most important caveat (account required), but it is very long and mixes multiple concerns in one paragraph. Every sentence adds real information, but the wall-of-text structure could be better organized into usage, behavior, and limitations sections. Given the complexity of the tool (pricing, tiers, citations, gaps, hops, contradictions, performance), the length is largely justified, but it is a close call between 3 and 4; the lack of structural formatting (no bullets/paragraph breaks) makes it harder to parse programmatically.

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 not having an output schema, the description fully documents return format (findings packet with verbatim evidence + confidence + source + fetched_at + citation, gaps[], contradictions[], hop field, citation_uri). It also covers failure modes (empty gaps for off-catalog topics), auth/tier requirements, latency, and iteration semantics. For a 2-param tool with no output schema, this is complete enough for an agent to select and invoke the tool correctly 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?

Schema already covers both parameters 100% (question natural language, depth enum with per-value behavior). The description adds value by explaining what depth values do in terms of facets and hops, and clarifies that 'question' can be broad/multi-part. However, the description doesn't add syntax/format details beyond the schema's enum descriptions, and the schema already explains depth semantics well, so a 4 rather than 5.

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

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

The description clearly states this is grounded multi-source research across Pipeworx's 1455 structured data sources, distinguishing it from open-web search and single-lookup tools. It specifies the mechanism (decomposes question, routes to 5,529 tools in parallel) and the output (findings packet with verbatim evidence, confidence, source, citations, gaps[]). This strongly differentiates it from siblings like ask_pipeworx (single lookup) and bet_research (specific domain).

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

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

Explicit when-to-use: 'Best for broad/multi-part questions over structured data' with examples. Explicit when-not-to-use: for breaking/current-news topics, prefer ask_pipeworx, which routes to live news APIs. Also names alternatives (ask_pipeworx for single lookup) and explains why deep_research would fail (empty gaps[] for non-catalog topics). Also gives account tier guidance and depth-plan guidance for iteration.

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 important behavioral details: returns top-N most relevant tools with names, descriptions, and full input schemas (with curated examples), each ready to call directly. This enhances transparency 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 somewhat long but front-loaded with the core purpose. It efficiently packs many example domains and behavioral details. Every sentence adds value, though minor trimming could make it even more concise.

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

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

Given no output schema, the description fully explains what the tool returns (top-N tools with schemas, curated examples) and how to use it. It covers the tool's role in a workflow, making it complete for an AI agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that the 'query' parameter accepts aliases (task, q, description, search) and specifies the default and max for 'limit'. This improves usability.

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 uses specific verbs like browse, search, look up, discover, and lists many example domains (SEC filings, financials, etc.), distinguishing it from sibling tools which are more specific in function.

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

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

Explicitly advises: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This gives clear context for when to use it, though it omits explicit when-not scenarios, which are implied.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about parallel execution, fanning out across sources, and specific behaviors like patents API sunset soft-fail. 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 dense paragraph that front-loads with example queries. It is relatively long but every sentence adds useful information. Could benefit from more structure (e.g., bullet points) but is still 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?

No output schema exists, so the description fully explains return values: cik, filings (with URIs), fundamentals (sorted), patents, news, LEI. It covers all aspects of the tool's behavior, making it complete for an agent.

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

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

Schema coverage is 100% with descriptions for both parameters. The description reinforces acceptable values (ticker or CIK) and adds examples, plus notes that names are not supported. This adds extra value beyond the schema.

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

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

The description uses specific verbs ('full cross-source profile') and resource references (SEC EDGAR, XBRL, USPTO, news, GLEIF). It distinguishes from siblings by stating 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' and references resolve_entity for name resolution.

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

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

Explicitly tells when to use (holistic company view) and when not (names not supported, use resolve_entity first). It also implies the alternative of chaining individual lookups.

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

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

Annotations already cover readOnly, openWorld, idempotent, and non-destructive behavior. The description adds 'default observer table,' which is consistent with the schema but does not provide additional 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?

Single sentence, front-loaded, and efficient. No wasted words, but could be slightly more informative without losing 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?

Given the complete schema and annotations, the description is minimally adequate. However, it does not explain what the output contains or when to choose different table types.

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 applies. The description does not add meaning beyond the schema; 'default observer table' is already in the table_type description.

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

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

The description clearly states the tool's function: 'Generate an ephemeris (default observer table).' It specifies a verb and resource, but does not explicitly distinguish from sibling tools like 'observers' or 'vectors'.

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?

No guidance on when to use this tool versus alternatives. Lacks context, prerequisites, or 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 provide destructiveHint=true and idempotentHint=true. The description confirms deletion but does not add substantial behavioral context beyond what annotations convey. It is consistent but does not elaborate on side effects or safety.

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 two sentences plus a brief pairing suggestion, all front-loaded with no redundant information. Every sentence adds value: purpose, usage scenario, and related tools.

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 delete operation with one parameter and no output schema, the description covers purpose, usage guidelines, and tool relationships. It is mostly complete, though it could mention success/failure behavior or idempotency guarantee, but annotations cover safety.

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

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

Schema coverage is 100%, with parameter 'key' described as 'Memory key to delete'. The description adds little beyond 'by key', so baseline score of 3 is appropriate - it does not introduce new meaning or constraints.

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 'Delete' and resource 'previously stored memory by key', clearly stating the action and scope. It distinguishes from sibling tools by mentioning pairing with 'remember' and 'recall'.

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 when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. It also mentions pairing with 'remember' and 'recall' as related tools, providing clear context. No explicit 'when not to use' but sufficient for typical use.

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

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

Annotations already indicate read-only, idempotent, non-destructive, and open-world behavior. The description adds details: fetching the page, extracting title/description/key links, and emitting standard llms.txt markdown format. It also specifies the output is a single text blob ready to drop at site-root/llms.txt, providing clear 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: two sentences plus a bullet list of use cases. It is front-loaded with the core action and output format, with no redundant or unnecessary wording.

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

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

Given no output schema, the description adequately explains the output (single text blob in standard llms.txt format). The tool is simple with only two parameters, and the description covers purpose, behavior, and use cases comprehensively. There are no gaps for this complexity level.

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

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

Schema coverage is 100% with descriptions for both parameters (url, max_links). The description adds context by mentioning the extraction of links (implicitly tied to max_links) and the output format, but does not delve deeply into parameter semantics. Still, it provides useful usage context, so a 4 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 generates a production-ready llms.txt file for any URL, specifying the actions: fetches page, extracts title/description/key links, and emits standard markdown. It distinguishes itself from siblings by being the only tool for this specific task.

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 own project, or auditing competitor's AI crawler view. This provides clear context on when to use the tool, with no competing sibling tools for this purpose.

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, non-destructive. Description adds value by specifying default behavior (active only) and the optional include_inactive parameter, and lists return fields.

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

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

Two purposeful sentences: first states action and return format, second gives usage guidance. 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 list tool with one optional parameter and no output schema, the description adequately explains what is returned and when to use it.

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

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

Schema coverage is 100% and the parameter description is already clear. The description adds minimal extra meaning beyond restating the default behavior ('active' vs 'cancelled').

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

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

The description clearly states 'List the caller's active subscriptions' and lists the return fields, distinguishing it from sibling tools like subscribe and unsubscribe.

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

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

It provides explicit usage context: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' No exclusions or alternatives are mentioned, but the guidance is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the specific transformation (name to ID) but no additional behavioral traits 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 a single, succinct sentence that efficiently communicates the tool's core function with no unnecessary 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 lookup, the description is minimally adequate given the presence of annotations and an output schema. However, it lacks usage guidance and fails to mention what happens when the name is not found (e.g., returns null/empty).

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 0%, so the description must explain parameters. It implies that 'query' is an object name via the examples (Mars, ISS), but does not explicitly describe the parameter's purpose or constraints. This provides partial compensation.

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 (resolve) and the mapping from object name to SPK id. It is specific and distinguishes this tool from siblings that perform more complex operations like comparison or entity profiling.

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?

No guidance is provided on when to use this tool versus alternatives like resolve_entity, entity_profile, or compare_entities. The description does not mention trade-offs or prerequisites.

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 the tool is read-only and idempotent. The description adds that it is a convenience wrapper, but does not detail behavioral traits beyond what annotations imply.

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

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

Single sentence with no wasted words. Front-loaded with the core concept: 'Convenience: ephemeris with table_type=OBSERVER.'

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 convenience wrapper, the description is adequate but does not explain the term 'observers' or the output format, though output schema may cover that.

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

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

With 0% schema description coverage, the description adds no meaning to parameters; it only mentions the fixed table_type, not the five input parameters.

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

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

The description clearly states that the tool is a convenience wrapper for ephemeris with table_type=OBSERVER, which distinguishes it from the sibling tool 'ephemeris'.

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 implies usage for observer ephemeris queries without needing to set table_type manually, but does not explicitly exclude other use cases or provide when-not-to-use guidance.

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

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

Annotations provide no safety hints (all false), so the description carries the full burden. It discloses the claim_token flow ('Filing without an account returns a claim_token; pass it back later...'), rate limiting ('Rate-limited to 5 per identifier per day'), cost ('Free; doesn't count against your tool-call quota'), and human processing ('The team reads digests daily'). 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?

Although the description is relatively long (~200 words), every sentence contributes a distinct piece of information: purpose, usage cases, exclusions, claim_token mechanics, rate limit, and cost. It is densely packed with no filler, and the key purpose is front-loaded in the first sentence. The structure flows logically from what → when → how → caveats.

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 4 optional params, a nested object, and no output schema, the description explains the key workflow: returning a claim_token and later reading the fix status by passing it back. It also specifies the types of feedback and exclusions, making the tool fully usable. The description adequately covers the output behavior (claim_token) without needing a formal output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds semantics beyond the schema: it explains how to use claim_token (pass it back with no other arguments), clarifies that message should be specific and not paste the end-user's prompt, and guides context using 'Pipeworx tools/packs'. These are genuinely useful extras that help the agent choose correct parameter values.

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

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

The description starts with a clear, specific purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It then enumerates the exact types of feedback (bug, feature/data_gap, praise), and explicitly distinguishes this tool from siblings by limiting scope to 'tools served by this Pipeworx connection' and contrasting with other vendors' connectors. This leaves no ambiguity about what the tool does or how it differs.

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 precise 'when to use' conditions: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also provides an explicit exclusion: 'if the tool came from a different MCP server... file it with that server instead.' The 'Not sure?' test ('Pipeworx tool names are the ones this connection lists') is a concrete decision rule.

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 idempotent, read-only, non-destructive behavior. The description adds details about data derivation (CF analytics-engine), no PII, and caching duration (5min-1h), which enrich the agent's understanding 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?

Three sentences, no wasted words. The first sentence defines functionality, the second lists use cases, the third provides technical details. Structure is clear and front-loaded.

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

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

For a tool with no output schema, the description hints at the return structure ('just (pack, tool, count)') and covers data source, privacy, and caching. Slightly lacks explicit expected output format, but sufficient given the tool's simplicity and openWorldHint.

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 the 'window' parameter with enum values. The description adds interpretive context: 'Shorter windows surface what's hot right now; longer windows show steady-state demand,' which helps the agent choose 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 verb 'returns' and the resource: top tools, top packs, and total call volume over a specified window. It distinguishes itself from siblings by focusing on aggregated trending data, which is unique among the listed sibling tools.

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

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

Three concrete use cases are enumerated (hot sources, canonical tool confirmation, alignment check). While it does not explicitly state when not to use or name alternatives, the use cases provide clear guidance for appropriate invocation.

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

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

Annotations declare readOnlyHint, idempotentHint, and no destructiveness. The description adds behavioral details: partition filtering drops placeholder slugs, fill check uses CLOB depth, and cross-event mode uses Jaccard similarity. 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 well-structured with clear sections for modes, semantic anchor, partition filter, and fill check. It is detailed but each sentence adds value; could be slightly more concise but still efficient.

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

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

No output schema, so description compensates by fully explaining the response structure (opportunities[], partition_check, fill check details) and edge cases (placeholder filtering, similarity threshold, book depth analysis). Extremely thorough.

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; schema coverage is 100%. The description adds context beyond the schema by explaining accepted formats (event slug, full URL, seed question) and illustrating usage examples.

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

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

The description clearly states the tool finds arbitrage opportunities via monotonicity violations and partition-sum checks, and delineates three modes (trending_scan, event, topic), distinguishing it from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

Explicitly instructs when to use each mode: no args for trending scan, event for per-event partition check, topic for cross-event scan. Also clarifies when not to trade (realizable_edge_pp ≤ 0) and references polymarket_fill_risk for custom sizing.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. The description adds extensive behavioral details: 1-hour KV caching keyed on knobs, response structure by_segment with diagnostics, explanations of edge computation (e.g., per-sport α for favorite-longshot bias), and why each segment might be empty. 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 thorough but verbose, containing multiple paragraphs and detailed explanations. While well-structured with clear sections and bullet points, it could be more concise without losing essential information. The length exceeds what is needed for a typical tool description.

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

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

Despite lacking an output schema, the description thoroughly explains the return structure (by_segment, fed_candidates, _diagnostics), caching behavior, and reasoning behind empty segments. It covers all relevant behavioral and structural aspects for an agent to use the tool effectively, compensating fully for missing output schema.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value for certain parameters: explains that min_partition_leg_kelly is needed because min_kelly doesn't filter partitions, and that slippage_pp accounts for Polymarket's zero fees but bid/ask spread. This contextual information enhances schema descriptions, justifying a score above baseline.

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

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

The description clearly states the tool scans top Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edge_tracker by focusing on three specific opportunity segments (model-driven, structural arbitrage, concentrated longshot) and is explicitly built for 'what should I bet on today'.

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 is built for discovering opportunities without paging hundreds of markets and mentions tradeable-edge knobs for filtering. It explains when to use the tool (daily bet research) but does not explicitly state when not to use it or compare to siblings beyond the tool's unique focus. The context is clear, but explicit exclusions are missing.

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

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

Annotations indicate readOnlyHint, idempotentHint, and non-destructive. The description adds critical context: history bounded by 60-day TTL, decay based on daily closes (not intraday), and gaps when no data scanned. 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 well-organized with clear sections (purpose, args, response, limits), but somewhat verbose. Every sentence adds value; front-loads the core question.

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

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

No output schema, but the description fully defines response fields (tracked, expired, snapshot_dates) and edge cases (gaps, TTL, signed decay). Complete for a read-only telemetry 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 descriptions. The description reinforces defaults and limits (days default 14 max 30, window default '1wk') and clarifies that 'window' is a snapshot family. Adds value over 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: edge persistence and decay telemetry from daily snapshots, answering 'how long has this edge existed and is it shrinking?' It contrasts with sibling polymarket_edges by focusing on historical trends rather than current edges.

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

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

The description explains when to use the tool (to distinguish fresh edges from old ones) and implicitly contrasts with polymarket_edges. However, it does not explicitly list when not to use it or provide alternative tools for other scenarios.

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, destructiveHint=false, so the tool's safety profile is clear. The description adds rich behavioral context: walks the ladder, returns specific fields (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict), and explains forced directional risk. 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 long but every sentence adds value, and it front-loads the core purpose. Minor redundancy could be trimmed, but it remains structured with mode-specific 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?

Despite no output schema, the description enumerates all return fields for both modes and covers edge cases (thin legs, forced directional risk). For a complex tool, this is exceptionally 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 parameters are already documented. The description adds value by explaining the default auto-detection of side in basket mode and how size_usd is interpreted differently for buys vs sells and in basket mode.

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 checks 'realizable-vs-theoretical edge' against live order-book depth, and distinguishes between single-market and basket modes. It explicitly differentiates from siblings like polymarket_arbitrage and polymarket_edges by stating when to use this tool before acting on their signals.

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

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

The description gives explicit usage context: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also warns about consequences of misuse, such as partial basket fills converting an arb into an unhedged directional position.

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

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

Annotations already cover read-only, idempotent, non-destructive. Description adds rich behavioral details: explains compatibility conditions, temporal alignment, skipped cross types, and warns that most pre-mapped topics return warnings. No contradiction with annotations.

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

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

Description is long but well-structured with labeled sections (TWO MODES, RESPONSE, SAFETY FIELDS). Front-loaded with core concept. Every sentence serves a purpose, though some redundancy could be trimmed.

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

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

Thoroughly covers complexity: two modes, safety fields, edge cases, response format. Despite no output schema, description adequately explains return fields. No gaps given the tool's sophistication.

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

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

Schema covers all 3 parameters with descriptions (100% coverage). Description enhances by explaining mode semantics and override behavior, plus providing concrete examples. Adds value beyond schema alone.

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

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

Clearly states it computes cross-venue spread between Kalshi and Polymarket. Distinguishes two modes (topic shortcuts vs explicit tickers) and explains response contents. Sibling tools like polymarket_arbitrage are differentiated by venue scope.

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 describes when spreads are meaningful vs not via compatibility_warning, temporal_alignment, and skipped counters. Does not directly name alternative tools, but provides enough context for when/then-not 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations, such as scoping to an identifier and the behavior of listing all keys when omitted. No contradictions.

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

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

The description is three well-structured sentences, front-loaded with the core action. Every sentence adds value without redundancy.

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

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

For a simple tool with full schema coverage, the description is complete: it explains behavior, use case, scoping, and relationship to sibling tools. No output schema is needed given the clarity.

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 property description already explains the effect of omitting 'key'. The tool description adds context about scoping and pairing but does not add significant parameter semantics 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 the tool's purpose: 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' It identifies the specific resource (saved memory keys/values) and action (retrieve/list), distinguishing it from sibling tools like remember and forget.

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

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

The description provides explicit usage context: 'Use to look up context the agent stored earlier — the user's target ticker, an address, prior research notes — without re-deriving it from scratch.' It also mentions scoping and pairing with remember/forget, though it lacks explicit when-not 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 discloses that setting mark_read:true flags events as read, modifying state, which directly contradicts the readOnlyHint=true annotation. Despite adding other behavioral context (polling, alternative endpoint), this contradiction is a critical flaw per scoring rules.

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, and every sentence adds unique value (return fields, filtering, mark_read effect, alternative endpoint). No redundant or filler content.

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

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

Given 5 optional parameters and no output schema, the description covers key aspects: return fields, filtering, polling suitability. It lacks explicit mention of 'limit' and 'unread_only' behavior, but the schema provides that. Overall, it is mostly complete for effective tool usage.

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

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

While the input schema already describes all parameters (100% coverage), the description adds meaningful context: examples for type ('sec_8k'), format for since (ISO timestamp), and the effect of mark_read on subsequent calls, which enhances parameter understanding beyond the schema.

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

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

The description clearly states the tool pulls fired events from the subscription feed, specifies the return fields (source, citation_uri, payload), and lists filtering options, making the purpose highly specific and unambiguous.

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

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

The description provides clear context for usage, mentioning that polling works fine and pointing to an alternative endpoint for scripts/dashboards. However, it does not explicitly distinguish from sibling tools or provide when-not-to-use guidance.

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds details on GDELT→GNews fallback, USPTO soft-fail, and return structure (changes, total_changes, citation URIs).

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

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

Front-loaded with example queries, every sentence adds value. Slightly long but still efficient for the information density.

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

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

No output schema, but description explains return format and sources. Covers date formats, fallback behavior, and limitations (USPTO sunset). Fully sufficient for a read-only aggregation tool.

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

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

Schema coverage is 100%, but description adds practical guidance: since accepts ISO or relative, recommends '30d'/'1m', value explains ticker/CIK. Enriches 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?

Clearly states it returns a change feed for a company from multiple sources (SEC, GDELT/GNews, USPTO) and explicitly distinguishes from sibling tool 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 usage examples ('What's new with X') and directs when to use entity_profile instead. No ambiguity.

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

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

The description adds key context beyond annotations: scoped by identifier, persistent for authenticated users, 24-hour retention for anonymous sessions. 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 a single, well-structured paragraph with no wasted words. It front-loads the main purpose and quickly provides usage guidance.

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

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

Given the tool's simplicity (2 required params, no output schema), the description fully covers what, when, and how to use it, including behavioral nuances and tool pairings.

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 both parameters. Description adds meaningful examples of key-value pairs (e.g., 'subject_property', 'target_ticker'), which aids 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 the tool saves data for reuse across conversations/sessions with specific examples (resolved ticker, target address, user preference). It distinguishes from siblings like recall and forget.

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

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

It explicitly says when to use ('when you discover something worth carrying forward') and pairs with recall/forget. It also differentiates behavior based on authentication status.

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

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

Even with annotations already indicating read-only, open-world, and idempotent behavior, the description adds substantial context: unresolved identifiers are explicitly listed under `unresolved` rather than omitted, LEI/FIGI enrichment degrades gracefully when upstream sources fail, and each call cascades through multiple internal endpoints. These details go well beyond the annotations and help the agent anticipate edge cases. No contradiction with annotations.

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

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

The description is dense and front-loaded with user intents and the critical "Use FIRST" guidance. Every sentence conveys useful information, especially the fallback behavior and unresolved handling. It is somewhat lengthy, and the phrase "accepts ticker, CIK, or company name as input" partially duplicates schema text, but overall it is well-structured and earns its length.

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

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

There is no output schema, so the description must explain return values, and it does thoroughly: company returns CIK, ticker, LEI, FIGI, ownership, and unresolved identifiers; drug returns RxCUI, ingredient, brand, and citation. It also covers graceful degradation, supported input types, and the multi-endpoint nature. This is complete for a tool with moderate complexity.

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

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

Schema coverage is 100% — both `type` and `value` have descriptive text and examples. The description adds some clarity by expanding on accepted input forms (ticker, CIK, name for company; brand/generic for drug) and explaining what outputs are produced, but it does not significantly enrich the parameter semantics beyond the schema's own examples. This meets the baseline but does not exceed it.

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

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

The description starts with clear user intents ("What's the ticker for…") and states the core function: "resolve a user-spoken NAME to the canonical/official identifiers other tools require as input." It names the specific resource (entity names → identifiers) and distinguishes usage with "Use FIRST whenever you have a name but need an ID," setting it apart from sibling tools like lookup or entity_profile.

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

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

The description provides explicit when-to-use guidance: "Use FIRST whenever you have a name but need an ID." It also explains the efficiency benefit ("replaces 2-3 manual lookups") and enumerates supported types and input formats. However, it does not explicitly state when not to use the tool or name alternative tools for cases where you already have an ID, so it stops short of a complete when/when-not comparison.

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

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

Discloses the probing process (ai_visibility_check), ranking, and return fields (score, confidence, signal density). Adds context beyond annotations (e.g., first entity as subject). 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?

Two sentences plus a parenthetical example. Front-loaded with core purpose; every word earns its place. 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?

Covers return structure (ranked list with score, confidence, signal density) despite no output schema. Adequate for the tool's complexity and provided annotations.

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

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

Schema coverage is 100%, but description adds extra semantics: first entity treated as subject, shared context disambiguates, optional API key for Anthropic. Adds meaningful context beyond schema.

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

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

The description clearly states 'Compare AI visibility across multiple entities side-by-side' with specific actions (probe, rank, surface). It distinguishes from sibling ai_visibility_check (single entity) and compare_entities (general comparison) by focusing on AI visibility audits.

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

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

Provides concrete use case 'competitive AI-marketing audits' with an example question. Lacks explicit when-not or alternatives but sufficiently implies context.

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

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

Annotations already declare readOnlyHint, openWorldHint, etc. The description adds significant context: explains composite fan-out, response structure (summary block, per-advisory, links, alternatives), mentions possible delays (5-30s for bundlephobia first measurement), and partial failure handling (sources_failed list). 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?

Single dense paragraph with minimal redundancy. Front-loads core purpose and usage, then details. Could benefit from slight structuring (e.g., bullet points for return fields), but every sentence adds value. Not overly verbose.

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 fully explains return values (summary block fields, advisories, links, alternatives). Also covers error behavior (partial failures, timeouts). Complete for a composite analysis tool given annotations and schema.

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

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

Schema already covers both parameters with 100% description coverage. The description adds value by explicitly stating that scoped packages (e.g., '@types/node') are accepted and that version defaults to latest when omitted, which reinforces and slightly extends schema information.

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

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

The description clearly states it is a composite check for npm packages, combining multiple data sources. It specifies the verb (scan/check), resource (npm package), and scope (composite from deps.dev and bundlephobia), distinguishing it from other tools in the sibling list.

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

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

Explicitly states when to use: 'whenever an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me''. Also provides constraints: NPM ecosystem only; other ecosystems use deps.dev directly. Mentions potential delays and graceful degradation, guiding appropriate 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 (which already mark it as read-only, idempotent, etc.), the description discloses the embedding model (BGE-base-en), similarity metric (cosine), chunking strategy (500-char overlapping windows), character limit (200K with truncation flag), and return schema (passages with offsets and scores). This fully informs the agent of behavior.

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

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

The description is three sentences: purpose, usage guidance, and implementation details. It is front-loaded with the core action. While efficient, the third sentence is dense with technical detail; breaking it into two might improve readability. Still, no wasted words.

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

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

Given that there is no output schema, the description adequately explains what the agent will receive (passages with character offsets and similarity scores). It covers the use case, limitations (truncation), and pairing with other tools. The description is complete for a retrieval tool with clear annotations.

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

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

The schema already covers all three parameters with descriptions (100% coverage). The description adds value by providing example queries and clarifying the meaning of 'text' (the document) and 'query' (natural language). It also mentions the 200K char cap, which is not in the schema description. This is above the baseline of 3.

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

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

The description starts with a specific verb+resource: 'Semantic search INSIDE a fetched record.' It immediately clarifies the scope (inside a record) and contrasts with neighboring tools like ask_pipeworx_grounded, clearly stating when this tool is appropriate (record too big for prompt) and how it pairs with others.

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

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

The description explicitly states when to use this tool ('when the record is too big to cram into the prompt') and what it saves (context). It also mentions pairing with ask_pipeworx_grounded, giving an alternative workflow, which helps the agent decide between 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 include idempotentHint=true, readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds significant behavioral context: authentication requirements (OAuth, no anonymous/BYO), webhook signing secret returned once, auto-disable after 10 failures, and SMS rate limit (10/day). This goes 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 a single paragraph with front-loaded main action and result. It uses parentheses for examples effectively, but is somewhat lengthy (around 200 words). Could be slightly more concise, but the detail is justified.

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

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

Given the complexity (3 parameters, nested objects, multiple subscription types, delivery options), the description covers all essential aspects: authentication, type-specific params, delivery channels with examples, limitations, and post-subscription behavior (webhook secret). No output schema, but return value is mentioned.

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

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

Schema coverage is 100%, and the description adds detailed examples for each type (e.g., 'sec_8k' with items codes, 'polymarket_edge' with topic). It also elaborates on delivery channel properties, including webhook HMAC signing and auto-disable. The description enriches parameter 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 creates a proactive monitoring subscription to a live-data event stream, specifies the action (subscribe), the resource (alerts), and the result (returns subscription id). It distinguishes from siblings like 'unsubscribe' and 'list_subscriptions' by detailing the creation aspect.

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 when to use (proactive monitoring), prerequisites (Pipeworx OAuth account), and supported types with examples. It also mentions delivery channels and limitations (sms cap, webhook auto-disable). However, it does not explicitly contrast with sibling tools or state when not to use, but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds value by specifying the return format (category-bucketed example questions with tool+argument shapes) and that results are drawn from a live catalog of thousands of tools, providing context beyond the annotations.

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

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

The description is a single paragraph that efficiently introduces the purpose, lists categories, and gives usage guidance. It is front-loaded with the key question and use case, though slightly lengthy, 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 tool with one optional parameter and no output schema, the description comprehensively explains the output content (example questions with tool shapes) and the live nature of the data. It covers all necessary context for an agent to understand and 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 coverage is 100% with one optional parameter fully described. The description reinforces the topic list from the schema and adds the important detail that omitting the parameter returns a cross-category spread, adding meaning beyond the schema.

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

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

The description clearly states the tool's purpose as an onboarding entry point for an agent to discover what Pipeworx can do, with specific user intents listed. It distinguishes from siblings like ask_pipeworx by positioning itself as the first step to learn about capabilities and how to call meta-tools.

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

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

Explicitly says 'Use this FIRST' when the agent doesn't know what Pipeworx can do, and describes how to call with no arguments or with a topic to focus. While it doesn't list exclusions, the positive guidance is clear and actionable.

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

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

Adds important context beyond annotations: ownership is enforced (auth requirements) and rows are deactivated not deleted, preserving history. 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?

Two concise, front-loaded sentences effectively convey purpose, constraints, and behavior with no unnecessary words.

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

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

For a simple tool with one required parameter and no output schema, the description is complete, covering purpose, usage constraints, and underlying behavior.

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

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

Schema coverage is 100% and the description adds minimal value by repeating that id is returned by subscribe. Baseline of 3 is appropriate.

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

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

Description clearly states 'Cancel a subscription by id', specifying the verb (cancel) and resource (subscription). It distinguishes itself 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?

Describes ownership enforcement and the deactivation behavior, guiding appropriate use. However, it does not explicitly mention when not to use or alternatives, slightly reducing clarity.

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. The description adds essential behavioral nuance: the distinction between 'could_not_verify' (check did not happen, with verification_error) and 'unsupported' (covered no source), plus the warning not to treat 'could_not_verify' as evidence. This goes well beyond the annotations and gives callers critical operational guidance.

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

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

The description is lengthy but every section serves a purpose: trigger phrases, use-case scope, pipeline routing, output semantics, and special caveats. It is front-loaded with examples and then systematically explains behavior. While longer than average, it is structured and dense rather than redundant.

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

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

With no output schema, the description fully explains return values (verdict types, actual value, citation, reasoning) and handles edge cases (could_not_verify, unsupported, verification_error). It also covers both execution paths and the caveat about how to interpret ambiguous verdicts. This 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?

The input schema already provides 100% coverage of both parameters with clear descriptions and examples. The description does not add further parameter semantics beyond what the schema states; it mentions tolerance only indirectly through 'exact percent-delta math'. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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

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

The description clearly identifies the tool's purpose: natural-language claim verification with verdict outputs. It uses specific verbs ('verify', 'fact check', 'confirm or refute') and distinguishes itself from likely siblings by describing the structured SEC EDGAR fast path and the grounded fallback pipeline. The description also clarifies that it replaces multi-step sequential calls, making its role unique.

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 'Use whenever the agent needs to check whether something a user said is factually correct' and details when the structured path applies (company-financial claims) versus the grounded fallback (any other factual claim). It does not name specific sibling tools as alternatives, but it does mention replacing sequential calls, providing clear context for use cases.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it is a convenience wrapper, implying it sets a default parameter (table_type=VECTORS), which is useful but not extensive.

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

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

The description is extremely concise (one sentence) but insufficiently informative for a tool with 5 parameters. It sacrifices substance for brevity.

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

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

Given the tool has multiple parameters and an output schema, the description is incomplete. It only mentions it is a convenience for VECTORS but does not explain parameters, output, or usage context.

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

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

Schema coverage is 0% and the description provides no information about any of the 5 parameters. The examples in the schema exist but the description adds no value for parameter understanding.

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

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

The description states it's a 'convenience' version of ephemeris specifically for table_type=VECTORS. This clearly indicates the tool provides vector ephemeris data and distinguishes it from the general ephemeris tool among siblings.

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

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

The description does not provide guidance on when to use this tool versus the general ephemeris tool or other siblings. It lacks context on prerequisites or typical scenarios.

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