Polygon Io

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to state safety. It adds value by detailing the granularity range and return fields, which is behavioral context beyond the annotations. No contradictions found.

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

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

The description is two sentences, front-loaded with the primary purpose and followed by use cases. Every word contributes information, with no fluff or repetition of schema fields.

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

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

Given the tool's complexity (8 parameters, 5 required) and no schema descriptions, the description provides a solid overview but does not fully cover all parameter semantics. Since an output schema exists, return values are not needed, but the input handling is incomplete (e.g., 'adjusted' and 'sort' are undocumented). It is adequate but leaves some gaps.

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

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

Schema description coverage is 0%, so the description must explain parameters. It mentions timespan granularity and ticker, and examples in the schema clarify date format, but parameters like 'adjusted', 'sort', and 'limit' are not explained. The description partially compensates but leaves gaps for several of the 8 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 it provides OHLC price bars with granularity from 1 minute to quarterly, and lists return fields (open/high/low/close, volume, VWAP). It also gives specific use cases (charting, intraday analysis, backtesting), distinguishing it from siblings like daily_open_close or grouped_daily.

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 suggests when to use the tool (charting, intraday analysis, backtesting) but does not mention alternatives or when not to use it. It implies contexts but lacks explicit exclusions or comparisons to sibling tools, so it's clear but not fully comprehensive.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details: default model is free, Anthropic requires BYO API key, and output includes per-model {score, confidence, signals, raw_response} plus combined view. No contradiction.

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

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

Three sentences, front-loaded with core purpose and key details. Every sentence adds value: default model, optional Anthropic, use cases. No wasted words.

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

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

Given no output schema, the description specifies return format ('per-model {score, confidence, signals, raw_response} + combined view'). It covers free vs paid models, API key requirement, and use cases. For a 4-param tool with 100% schema coverage, this is fully complete.

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

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

Schema description coverage is 100%, but the description adds meaning beyond the schema: explains default model for 'models', BYO key for '_apiKey', and context helps disambiguate. This adds value for the agent.

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 'Probe one or more LLMs for what they know about a business/brand/product/topic and score visibility (0-100) per model.' It specifies the verb 'probe' and the resource 'LLMs for visibility scoring'. The purpose is distinct from sibling tools like 'scan_competitor_ai_presence' or 'resolve_entity'.

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

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

The description provides clear use cases: 'Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring.' It does not explicitly state when not to use or name alternatives, but the context is clear enough for an AI agent to decide.

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

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

Annotations already provide readOnly, openWorld, and idempotent hints, but the description adds meaningful context: it routes through a large tool network, returns structured answers with pipeworx:// citation URIs, works on every tier, and is a single fast call. It does not hide the operational nature of the tool. The only minor gap is no explicit mention of failure behavior or rate limits, but annotations carry much of the safety profile.

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 it is front-loaded with the most important instruction ('PREFER OVER WEB SEARCH') and every subsequent section earns its place: scope, trigger phrases, examples, escalation criteria, and news behavior. It is somewhat dense and could be tightened, but not at the cost of necessary routing 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?

For a general-purpose question-answering tool with a simple schema and no output schema, the description is complete: it explains inputs, outputs, alternatives, scope, and behavior. It also preempts common edge cases like breaking-news questions and broad multi-part questions, so an agent has what it needs to 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?

The schema already documents the `question` parameter and its aliases with 100% coverage, so the baseline is 3. The description goes beyond by explaining what kinds of questions are appropriate, providing concrete example phrasings, and clarifying that the argument is a natural-language request.

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

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

The description clearly identifies a routing/answering tool: it takes a natural-language question, routes it across 5,724 tools, and returns a structured answer with citation URIs. It also explicitly distinguishes itself from web search and names sibling tools like ask_pipeworx_grounded and deep_research, so an agent can tell them apart.

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?

This is exemplary: it says to prefer the tool over web search, gives concrete trigger phrases and examples, names exact escalation paths to ask_pipeworx_grounded and deep_research, and even explains when not to escalate because ask_pipeworx already handles news. The agent gets clear when-to-use and when-not-to-use guidance.

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

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

The description is highly transparent: it discloses that no candidate is currently active, that the tool currently matches ask_pipeworx exactly, that it is a full working router, and that it 'Falls back to nothing.' The annotations already declare the tool read-only, idempotent, and non-destructive, and the description adds useful live-state context without contradicting 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 concise and front-loaded with the beta identity and relationship to ask_pipeworx. It includes useful specifics like the tool count, current inactive status, and comparison role. The date of the last retirement is mildly extra but supports the transparency about the current state.

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

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

The description covers current behavior, usage, and the experimental nature of the tool. Because there is no output schema and the description only says 'same response shape' without describing that shape, an agent must infer output details from ask_pipeworx. Still, the explicit pointer to use it exactly like ask_pipeworx makes this adequate.

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

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

Schema description coverage is 100%, with all six parameters documented as aliases of 'question.' The description adds no parameter-specific detail beyond saying the tool takes the same arguments as ask_pipeworx, which is sufficient given the schema already defines all aliases clearly.

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 identifies the tool as a beta variant of ask_pipeworx and explicitly calls it a 'universal router' with the same tools, arguments, and response shape. It distinguishes it from the stable router by noting 'candidate routing improvements enabled live whenever one is under test.' However, it doesn't independently explain what the router does, relying on the agent's understanding of ask_pipeworx.

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

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

The description gives an explicit usage instruction: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also references the stable router as the comparison baseline, which implies the alternative. It stops short of stating when not to use this beta version, such as when stability is required.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. On top of that, the description adds rich behavioral detail: the grounding constraint (answer extracted only from tool result), the full refusal mechanism with five explicit refusal_reason values, the exact success return shape, and the cost of one extra LLM call. The refusal semantics in particular are behavior an agent could never infer from annotations alone. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place: purpose, mechanism, return format, refusal reasons, usage context, and cost tradeoff. The core differentiator is front-loaded. It is longer than ideal, and the exact refusal enum list could be seen as verbose, but since there is no output schema, documenting the refusal contract in-band 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?

For a tool with no output schema, the description fully covers the return contract, refusal behavior, success/error paths, and routing context. It also carries the alternative-selection guidance. Minor gaps: it doesn't specify how 'confidence' is derived or any evidence length cap, but these are secondary against the decision-relevant information that is present. This is complete enough for safe invocation.

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

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

Schema coverage is 100%, so the schema fully documents the single meaningful parameter (question) and its five aliases. The description adds behavioral context about how the question is processed (routed, arguments filled, data fetched, answer extracted) but no syntactic or format details beyond the schema. Per the baseline rule for high coverage, a 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 a specific, vivid purpose: 'Hallucination-resistant answer mode for high-stakes reads.' It names the resource (Pipeworx data routed across 5,724 tools / 1497 sources) and the distinguishing behavior (extracts answers ONLY from tool results, or refuses). It explicitly contrasts with the sibling ask_pipeworx, so an agent can discriminate without opening schemas.

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

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

Gives explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on... financial verdicts, legal claims, medical lookups, public statements.' It also gives a when-not-to-use with a named alternative and a concrete cost reason: 'Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups.' This is the gold standard for routing.

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

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

The description extensively discloses behavioral traits beyond annotations: resolution workflow, classifier and fan-out logic, error handling (low_confidence_match, market_closed_or_inactive), tradeability warnings, resolution-rule risk, and data provenance (e.g., GDELT 429 fallback). No contradiction with annotations (readOnly, idempotent, non-destructive) as it describes read-only data aggregation.

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

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

The description is front-loaded with a clear purpose statement, but it becomes verbose with many examples and internal details (classifier list, fan-out examples) that could be summarized. While comprehensive, it lacks conciseness; every sentence is informative but the volume may hinder quick comprehension.

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

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

Given no output schema, the description thoroughly explains the response structure (market, analysis, evidence, resolver contract), handles edge cases (low confidence, closed markets, wide spreads, cancellation rules), and covers safety mechanisms. It is fully complete for an agent to understand tool behavior and expected outputs.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context for the 'market' parameter (slug, URL, or question text) and provides examples, which is helpful but not extensive. For 'depth' and 'include_raw', the description does not add meaningful information beyond the schema descriptions, meeting rather than exceeding expectations.

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 a Polymarket bet by pulling Pipeworx data in one call. It specifies input types (slug, URL, question text) and explicitly lists use cases ('should I bet on X', 'what does the data say about Y', 'is there edge in Z'), making the purpose highly specific and distinguishable from sibling tools like polymarket_arbitrage.

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

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

The description provides clear usage scenarios ('Use for...') and covers when to trust the results (e.g., inspecting market_match_confidence). However, it lacks explicit 'when not to use' or direct comparison with alternatives, though the context implies it is for research rather than trading or arbitrage.

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

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

Annotations already indicate read-only, open-world, idempotent behavior. The description adds valuable context: it handles fiscal year variations, returns LATEST data, sorts by primary metric, and includes citation URIs. No contradictions with annotations.

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

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

The description is front-loaded with example phrases and a clear usage directive. It is slightly verbose but each sentence provides essential context. The structure is logical: examples, then straight-to-use advice, then type-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?

Given the tool has 2 parameters with 100% schema coverage and no output schema, the description fully explains what the tool returns (paired data + citation URIs), covers both entity types, and specifies sorting behavior. It is complete enough for correct invocation.

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

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

Schema coverage is 100%, but the description adds meaning by detailing what each type retrieves (e.g., 'pulls LATEST 10-K revenue + net income + cash + long-term debt' for company), explains values format (tickers/CIKs for company, names for drug), and confirms min/max items. This goes beyond the schema's minimal descriptions.

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

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

The description explicitly states the tool does side-by-side comparison of 2-5 companies or drugs, with concrete example phrases like 'Compare X and Y' and 'head to head'. It clearly distinguishes its purpose from sequential lookups by stating 'ALWAYS PREFER over sequential single-pack lookups'.

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

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

The description provides explicit when-to-use guidance with example queries and a strong preference directive. It explains when to use company vs drug type, and what data each retrieves. This helps the agent decide between this tool and sibling tools like entity_profile or ticker_details.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds context about the data source (Massive/Polygon.io) and the inclusion of after-hours/pre-market prices, which helps the agent understand the tool's scope without contradicting annotations.

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

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

The description is a single, well-structured sentence that is concise and front-loaded. It includes essential details without any fluff 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?

The tool is relatively simple, and the output schema covers return values. The description adequately covers the core purpose and data scope, but it omits the adjusted parameter and any guidance on alternatives, so it is not fully complete.

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

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

Schema coverage is 0%, so the description must compensate. It explains the date format (YYYY-MM-DD) and specifies that the ticker is for US stocks, but it does not explain the 'adjusted' parameter, leaving an important gap for agents deciding how to use optional parameters.

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

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

The description clearly states the tool fetches official open, high, low, close, volume, and after-hours/pre-market prices for a US stock ticker on a specific date. This distinguishes it from sibling tools like previous_close or aggregates, which serve different data needs.

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 when to use the tool: when daily official OHLCV data including after-hours/pre-market for a single ticker and date is needed. It does not explicitly name alternatives, but the specificity implies the appropriate use case.

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

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description reveals meaningful behaviors: account/tier requirements, parallel routing to 5,724 tools, gaps[] for unanswered facets, contradictions[], hop fields, citation fetchability, semantic excerpting, and expected latency. It also cautions about empty gaps[] on non-catalog topics. This is rich and non-redundant.

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 appropriately so for a complex tool with three depth modes, account requirements, and output expectations. Critical caveats are front-loaded (account requirement, not open-web search, alternative tool). Some redundancy with the schema's depth descriptions exists, but every paragraph adds distinct decision-relevant information.

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

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

Despite having no output schema, the description fully explains what will be returned: findings packet, verbatim evidence, confidence, source, fetched_at, citation_uri, gaps[], contradictions[], and hop fields. It also covers prerequisites, latency expectations, and limitations. An agent has enough to decide when to call it and what to expect.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value on top: question is explicitly natural language and broad/multi-part is fine, and depth values get contextual framing like 'single hop' and 'gap recovery.' It doesn't simply restate the schema.

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

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

The description states a specific verb and resource: it 'researches' across Pipeworx's 1497 structured data sources in one call, and explicitly contrasts itself with open-web search. It also distinguishes itself from sibling tools like ask_pipeworx by framing itself as multi-facet structured research versus a single lookup.

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

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

The description gives explicit when-to-use guidance: 'Best for broad/multi-part questions over structured data.' It also names alternatives and exclusions: use ask_pipeworx for a single lookup, for breaking/colloquial current news, or if not signed in. This is clear, actionable routing.

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

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

Annotations already convey readOnly, idempotent, non-destructive. The description adds value by detailing the return format (top-N tools with schemas and examples) and that results are ready to call directly. It does not contradict annotations.

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

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

Front-loaded with the core purpose. Structured logically: purpose, when to use, what it returns, explicit instruction. No superfluous sentences; each part earns its place despite the fairly long list of domains.

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 meta-tool with no output schema, the description fully explains the return value (tool names, descriptions, schemas with examples) and the 'ready to call' nature. Parameter count and aliases are handled well. Completely adequate.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds a list of domains for the query parameter but does not significantly improve parameter understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states 'Find tools by describing the data or task' with a specific verb and resource. It distinguishes itself from sibling tools (e.g., tickers, news) by being a meta-tool for discovery, listing many domains.

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

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

Explicitly says 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available'. Provides clear when-to-use context and a direct instruction, though no when-not-to-use is needed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description only needs to supplement. It adds context about the time scope ('historical and upcoming') and enumerates returned fields, providing useful behavioral detail 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, concise sentence that front-loads the core purpose and lists key output fields, with no filler or repetition. It earns its place efficiently and is easy to parse at a glance.

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

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

The tool has an output schema (present but not shown) and the description lists the return fields, so output context is adequate. However, the lack of parameter guidance and the absence of any mention of preconditions (e.g., valid ticker format) leaves the input side incomplete. The description is useful but not fully comprehensive for a tool with three undocumented parameters.

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

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

Schema description coverage is 0%, yet the description fails to explain any parameter semantics. While 'for a US-listed ticker' hints at the ticker parameter, it does not clarify 'limit' or 'ex_dividend_date', leaving the agent without guidance on how to use these inputs effectively. Given the low coverage, the description should compensate but does not.

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

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

The description clearly states the tool returns historical and upcoming cash and stock dividends for a US-listed ticker, with a specific list of data fields (ex-date, record date, pay date, declaration date, cash amount, dividend type, frequency). It distinguishes itself from sibling tools by being the only dividend-specific data source, and the mention of 'Massive (formerly Polygon.io)' adds source clarity.

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 recommends usage for 'income analysis and dividend-capture strategies,' providing a clear context. It does not explicitly mention when not to use or alternative tools, but given there are no dividend-specific siblings, this guidance is sufficient and not misleading.

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 specific behavioral details: fans out across multiple sources, returns up to 5 filings, soft-fail for patents (USPTO sunset May 2025), sorted fundamentals. 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?

Moderately long but well-structured: starts with illustrative examples, then core purpose, then detailed return structure. Every sentence adds value. Could be slightly more concise but remains 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 fully compensates by listing all return fields (cik, company_name, recent_filings with URIs, fundamentals, patents, news, LEI). Covers limitations (patents sunset), prerequisites (ticker or CIK), and fallback behavior (GDELT→GNews). Comprehensive for a complex tool.

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

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

Schema covers type and value with descriptions. Description adds critical nuance: type only 'company' currently, value must be ticker or zero-padded CIK, names not supported. Also clarifies zero-padding requirement and that CIK is accepted.

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 provides a full cross-source profile of a US public company in one parallel call, with specific examples and explicit preference over chaining individual lookups. Distinguishes from sibling tools like aggregates, ticker_details, and news.

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

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

Explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' Also mentions when not to use: names not supported, use resolve_entity first. Provides clear trigger examples.

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, and open-world hints. The description adds valuable context about the scope (Massive/Polygon.io coverage) and output fields without contradicting annotations. It does not mention limitations like pagination, but the output schema partly compensates.

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, information-dense sentence that front-loads the purpose, gives concrete examples, and lists return fields. No wasted words; every element 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?

The tool is simple (two optional params, output schema present). The description covers purpose, coverage, and returned fields. Missing explicit parameter explanations and pagination behavior are minor gaps given the reference-list nature and output schema availability.

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% for parameters (locale, asset_class), and the description only vaguely hints at them by listing them among return fields. It does not explain allowed values or how to use them for filtering, leaving the agent without essential parameter guidance.

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

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

The description clearly identifies the tool as a reference list of exchanges, specifies covered asset classes (US stocks, options, crypto, OTC), and lists return fields (MIC code, name, asset class, type, locale). This is specific and distinguishes it from sibling tools like tickers or market_holidays.

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

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

The description implies usage for looking up exchange information but lacks explicit when-to-use or when-not-to-use guidance. It provides clear context but no exclusions or alternative tool comparisons, which is sufficient for a non-ambiguous reference tool.

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

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

Annotations already provide destructiveHint=true and idempotentHint=true. The description adds context about clearing stale or sensitive data, but does not elaborate on behavior like what happens if the key doesn't exist or any side effects. The description adds moderate value beyond annotations.

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

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

The description is two sentences long, front-loaded with the core purpose, and provides usage guidance and sibling references without any 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?

Given the tool's simplicity (one parameter, no output schema) and the presence of annotations, the description covers the purpose, usage context, and parameter sufficiently. It is complete for the tool's complexity.

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

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

Schema coverage is 100% and the schema already describes the 'key' parameter as 'Memory key to delete'. The description does not add any additional semantic detail beyond that, so it 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 uses the verb 'Delete' and specifies the resource 'a previously stored memory by key'. It distinguishes from siblings by explicitly mentioning 'Pair with remember and recall', making it clear what this tool does relative to its companions.

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

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

The description provides clear guidance on when to use this tool: 'when context is stale, the task is done, or you want to clear sensitive data'. It also explicitly mentions sibling tools 'remember and recall' as alternatives to pair with.

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 destructiveHint as false. The description adds behavioral details: fetches the page, extracts title/description/key links, emits standard markdown format, and mentions network fetch. 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 paragraph, concise and front-loaded with key action. It could be slightly more structured (e.g., bullet points), but every sentence contributes meaning without redundancy.

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

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

Given only 2 parameters, full schema coverage, no output schema, and comprehensive annotations, the description covers purpose, behavioral traits, output format, and usage scenarios. It is complete for an agent to understand and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by specifying default max_links (25) and maximum (50), which the schema does not provide. This extra context aids the agent in parameter selection.

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 verb 'Generate' and resource 'llms.txt file'. It explicitly mentions AI crawler indexing and emits standard format. Sibling tools are unrelated, so differentiation is not needed.

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

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

The description provides concrete use cases: getting a client's site indexed, drafting for own project, auditing competitor. It does not explicitly state when not to use or give alternatives, but given no closely related sibling tools, the guidance 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 and destructiveHint=false, so the description adds useful operational context beyond those: it fetches all US stocks in one call, requires a date, and sources data from Massive/Polygon.io. It does not mention potential response size or rate limits, but the output schema and annotations cover the main safety and return expectations.

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

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

The description is a single, well-structured sentence that front-loads the action and resource, then adds the parameter format and a use case. Every clause contributes value with no redundancy.

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

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

Given the output schema, annotations, and modest two-parameter surface, the description adequately covers the tool's purpose, universe, and date format. The only notable omission is the adjusted parameter semantics, but the overall context is sufficient for an agent to select and invoke this read-only bulk data tool.

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

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

With 0% schema description coverage, the description must compensate for parameter explanations. It does document the date format (YYYY-MM-DD), but the 'adjusted' boolean parameter is never mentioned or explained, leaving a meaningful gap in 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 action (Fetch OHLCV bars), resource (all US stocks on a given date from Massive/Polygon.io), and format (YYYY-MM-DD). It distinguishes itself from sibling tools like aggregates or daily_open_close by emphasizing the market-wide, single-call nature.

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 phrase 'useful for market-wide snapshot or screening' provides clear context for when to choose this tool. It does not explicitly name alternatives or state when not to use it, but the market-wide scope strongly implies a contrast with single-ticker endpoints.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds context about scope (caller's subscriptions) and returned fields, but no additional behavioral traits beyond what annotations suggest.

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, with two sentences that cover purpose, output fields, and usage guidance. There is no wasted text, and the structure is clear.

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

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

For a simple list tool with one optional parameter and no output schema, the description is fairly complete. It lists returned fields and provides usage context. It could mention any limits or ordering, but overall it is adequate.

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

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

The single parameter 'include_inactive' is fully described in the schema with 100% coverage. The description does not add any additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists the caller's active subscriptions and specifies the returned fields. It distinguishes itself from sibling tools like 'subscribe' and 'unsubscribe', which perform different actions.

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

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

The description provides explicit guidance on when to use this tool: to review monitoring before adding more subscriptions or to find an ID to cancel. This gives clear context, though it does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered. The description adds that the data comes from Massive (Polygon.io) and includes a specific field list (date, holiday name, exchange status), which is useful but minimal. It doesn't mention data update frequency or whether early-close is always included, but given strong annotations, this is acceptable.

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

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

The description is a single, clear sentence that is front-loaded with the main purpose and includes all necessary specifics. No wasted words, perfectly 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?

The tool is simple with no parameters and an output schema exists, so the description doesn't need to explain return values in detail. It covers the key information an agent needs: source, scope (US stock market), and the data included (date, holiday, exchange status). The presence of an output schema also helps. A small gap is not mentioning that the list is 'upcoming' only, but this is stated.

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 tool has 0 parameters and schema description coverage is 100% (the schema is empty), so the description carries the full burden. It does a good job by specifying the output fields (date, holiday name, exchange status), which is helpful for the agent to understand what to expect. For a no-parameter tool, the baseline is 4, and the description meets this.

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 what the tool does: 'Return the list of upcoming US stock market holidays from Massive (formerly Polygon.io), including date, holiday name, and exchange status (open/closed/early-close).' This is a specific verb+resource+scope, and the inclusion of 'upcoming' plus the exchange status details distinguishes it from market_status (which is about live market status) and calendar-related 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 implies when to use this tool (when you need upcoming holidays and their exchange status), but it doesn't explicitly state when not to use it or name alternative tools for different holiday/calendar needs. The context signal of sibling tools includes market_status, which could be confused, but the description provides no direct contrast.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, but the description adds no extra behavioral context such as update frequency or data source scope.

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 short but under-specified; it fails to provide enough detail to justify its existence, being more of a label than a helpful explanation.

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 having an output schema, the description does not clarify what market status entails (e.g., indices, trading hours), leaving the tool's purpose incomplete.

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 tool has zero parameters and 100% schema coverage, so the baseline is 4. The description does not add parameter information, but none is needed.

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 'Current market status' is essentially a tautology of the tool name, providing only a vague sense of returning status data without specifying what aspects of market status are covered.

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 given on when to use this tool versus sibling tools such as market_holidays or daily_open_close, or what distinct data it provides.

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, and idempotentHint, covering the safety profile. The description adds context about sentiment insights and data fields without contradicting annotations. It lacks details on rate limits or pagination but does not need to repeat annotation-provided traits.

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

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

Two concise sentences: the first immediately explains what the tool returns, the second gives concrete usage and a preference note. No wasted words and important context is front-loaded.

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

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

The description covers main purpose and usage, and output schema presumably handles return values. However, the lack of parameter details weakens completeness for a tool with 5 parameters and no schema descriptions. It is adequate for basic ticker queries but not fully comprehensive.

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

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

Schema has 5 parameters with 0% description coverage. The description only implies 'ticker' usage via examples but does not explain sort, limit, order, or published_utc. With no param info in the description, the agent cannot confidently use all parameters, especially since the schema provides no descriptions for them.

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 fetches financial news with ticker tags, including publisher, URL, image, summary, and sentiment. It specifies the resource (news) and distinguishes itself by focusing on equity-specific headlines, with explicit use cases and a preference over web search.

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 scenarios ('what is the news on $TICKER' or 'market-moving headlines today') and advises preferring this over web search for equity news. However, it does not mention alternative tools or when not to use it, limiting exclusionary 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 are all false, so the description carries the full burden. It discloses the claim_token flow (filing returns it, passing it back reads status), rate limits (5/day), cost (free, no quota), and that the team reads digests daily. It could add a note about sending data externally, but the side effects are clearly implied by 'tell the team.' 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?

Despite being long, every sentence earns its place. It is front-loaded with the core purpose, then logically proceeds to use cases, exclusions, token mechanics, and operational details. No filler or repetition—just dense, necessary 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?

With no output schema, the description explains the return behavior (claim_token and later retrieval of fix status). It covers tool scope, feedback categories, rate limits, cost, and actionable guidance. This is enough for an agent to confidently invoke the tool correctly, especially given the schema descriptions for all parameters.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics: it explains the claim_token lifecycle in detail (returned on filing, used with no other args to read status), maps type categories to real-world scenarios, and adds message constraints ('don't paste the end-user's prompt') not in the schema.

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

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

The description opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes from data-retrieval siblings by enumerating feedback types (bug, feature, data_gap, praise) and explicitly scopes it to Pipeworx tools only.

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

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

The description gives explicit when-to-use criteria for each type, and critically includes a when-not-to-use: if the tool came from a different MCP server, file with that server instead. It also provides content guidance ('don't paste the end-user's prompt') and directs users to check this connection's tool list when unsure.

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 behavior. The description adds valuable context: no PII, cached (5min-1h), derived from analytics engine. This goes beyond the annotations.

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

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

The description is concise and well-structured: main result first, then use cases, then additional behavioral details. No fluff, every sentence adds value.

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

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

Given the low complexity (one optional parameter, no output schema), the description covers purpose, usage, parameter semantics, and behavioral traits completely. An agent has all needed info to invoke correctly.

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

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

Schema coverage is 100% and the description adds semantic guidance: shorter windows surface what's hot, longer windows show steady-state demand. This adds meaning beyond the schema's enum and basic 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 returns top tools, packs, and call volume, with specific verb and resource. The three use cases (discovering hot data, confirming canonical tool, checking alignment) further clarify its purpose and distinguish it from siblings like aggregates or ask_pipeworx.

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

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

The description provides three explicit use cases that guide when to use this tool. It does not explicitly state when not to use it or suggest alternatives, but the context is clear enough for an agent to decide.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral details: fill check (realizable_edge_pp ≤ 0 means do not trade), semantic anchor (Jaccard similarity threshold), partition filter (placeholder slugs). No contradictions with annotations.

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

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

The description is lengthy but well-structured: first sentence states purpose, then breaks down modes with examples and technical details. Every sentence adds value given the tool's complexity. Could be slightly more concise, but the front-loading is effective.

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

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

The description covers all aspects of the tool: three modes, fill check, semantic anchor, partition filter, response structure (opportunities[], partition_check with fields), and even references custom sizing via polymarket_fill_risk. Despite no output schema, the response is well detailed. The tool is fully explained with 2 optional parameters.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds extra value by explaining how to use slugs vs URLs, providing seed question examples, and describing the behavior of each mode. This goes beyond the schema's basic description, enhancing the agent's 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 finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes: no args (trending_scan), event, and topic. The verb 'find' and resource 'arbitrage opportunities' are specific. It differs from sibling tools like polymarket_edges and polymarket_fill_risk by focusing on comprehensive arbitrage detection.

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

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

The description explicitly tells when to use each mode: no args for trending scan, event for a specific market, topic for cross-event scanning. It includes recommendations (e.g., 'event recommended for a specific market') and explains the benefit of cross-event mode. However, it does not explicitly list alternatives or when not to use this tool, though the context is clear.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds significant context: explains caching (1h at KV level), model families, slippage handling, tradeable-edge filters, and diagnostics. 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?

While the description is front-loaded with purpose, it is very long and dense with technical details on model families (e.g., GDELT, lognormal barrier, Kelly fractions). An AI agent may find it overwhelming, though the detail is informative.

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

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

For a tool with 9 parameters and no output schema, the description thoroughly explains the output structure (by_segment, fed_candidates, _diagnostics), edge calculation, and tradeable-edge filters. It compensates for missing output schema completely.

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 practical usage advice for parameters like slippage_pp ('Bump for very thin partitions') and min_liquidity, providing value beyond schema descriptions.

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

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

The description clearly states 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price,' with a specific verb and resource. It distinguishes itself from siblings like polymarket_arbitrage by focusing on edge detection from data disagreement.

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 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets,' indicating when to use. It does not explicitly state when not to use or compare to alternatives, 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?

With readOnlyHint=true, idempotentHint=true, etc., the description adds behavioral details: reads from snapshots (not live), decay computed from daily closes, history bounded by TTL, gaps meaning no scan. 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 detailed and front-loaded with the core question. However, it is somewhat verbose with extensive explanation of response structure and limits. Could be slightly tightened.

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

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

Despite no output schema, the description fully explains the response fields (tracked, expired, snapshot_dates) and covers edge cases (gaps, TTL, decay computation). Completeness is excellent.

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 value: default values, clamp range for 'days', list of options for 'window', and explains effect on history depth and snapshot availability.

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

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

The description explicitly states the tool's purpose: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It clearly distinguishes from sibling tool 'polymarket_edges' by focusing on historical tracking and decay analysis.

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

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

The description implies usage context (when you need edge history and decay) but does not explicitly state when not to use this tool or name alternative tools. However, it provides practical constraints like snapshot TTL and gaps.

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, establishing safety. The description adds rich behavioral context: walking the ladder, returning top_of_book, vwap_fill_price, slippage_pp, verdict categories, thin legs, forced directional risk. Warns about partial fills and unhedged positions. 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 comprehensive yet efficiently structured with clear sections: REQUIRES, SINGLE-MARKET, BASKET, and a usage note. Every sentence adds value, no redundancy. Length is justified by the tool's dual-mode complexity.

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

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

No output schema exists, so description fully covers return fields for both modes: lists all return values (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict for single; theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg detail, thin_legs, max_clean_notional_usd, forced_directional_risk for basket). Also explains verdict categories and risk of partial fills. Completeness is high given tool 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%, but description adds meaning beyond schema: clarifies size_usd interpretation (max spend on buys, target proceeds on sells; for basket, settlement notional shares per leg). Explains side defaults per mode (single-market default buy_yes, basket default auto from partition sum). All parameters are elaborated with usage context.

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

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

The description clearly states the tool checks realizable-vs-theoretical edge using live CLOB order-book depth. It distinguishes between single-market and basket modes and specifies return fields. It also explicitly contrasts with sibling tools polymarket_arbitrage and polymarket_edges, advising use 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?

Explicitly states when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also explains consequences of not using it, e.g., 'partial basket fills convert an arb into an unhedged directional position (the dominant loss mode in real arb-bot P&L)'.

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 readOnlyHint and idempotentHint annotations, the description goes far beyond them: it discloses matching limitations, compatibility codes, unclassified-leg exclusions, fee treatment, gross vs net spreads, and the fact that pairs are matched by keyword overlap rather than a shared resolution source. No contradiction with annotations exists.

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

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

The description is long but densely packed with necessary safety caveats and mode distinctions. It is front-loaded with the core purpose and organized by behavioral areas. Some repetition of warning themes exists, but it is justified given how easily this tool's output could be misinterpreted.

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

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

With no output schema present, the description carries the full burden of explaining the response shape, and it does so thoroughly: leg prices, top_spreads_pp, compatibility fields, temporal alignment, fees_note, and skipped comparison counters are all described. The conditions under which warnings appear are also made explicit.

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

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

The schema already describes all three parameters, but the description adds significant meaning: topic is a pre-mapped shortcut list, explicit ticker/slug override the mapped side, and both modes run an identical token-overlap matcher. This is substantially more than the bare 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 names a precise verb and resource: it computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It clearly distinguishes the two operating modes (topic shortcut vs explicit ticker/slug) and differentiates this from simple single-venue pricing.

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 exactly when to use each mode and warns that pre-mapped topics often return compatibility warnings rather than tradeable spreads. It does not explicitly name alternative sibling tools or state when to choose one over them, but it provides strong contextual usage guidance within the tool itself.

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 the operation as read-only, idempotent, and open-world, so the description does not need to restate safety. The description adds the context that this is for US stocks and that it covers a 'previous trading session', which is useful but not very granular. No contradictions, but it does not disclose rate limits, data availability quirks, or what happens on non-trading days.

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

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

The description is a single, well-structured sentence that front-loads the action and essential information. Every word earns its place, and there is no fluff or redundancy. This is an example of concise, effective communication.

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 query tool with an existing output schema, the description is largely complete for the basic use case. However, it misses an opportunity to mention the relationship with sibling tools like 'daily_open_close', which could prevent misuse. Overall, it covers the core functionality adequately.

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

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

Schema description coverage is 0%, and the description does not compensate by explaining parameter purposes. The description mentions 'US stock ticker' which hints at the 'ticker' parameter, but 'adjusted' is entirely unexplained. With two parameters and zero guidance, an agent cannot confidently construct valid calls beyond the most obvious.

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 ('Fetch') and the resource ('previous trading session's open, high, low, close, and volume for a US stock ticker'), which is specific and unambiguous. However, it does not distinguish itself from sibling tools like 'daily_open_close' or 'aggregates', which likely serve similar purposes. The addition of 'from Massive (formerly Polygon.io)' adds data-source context but not differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. There is no mention of alternatives like 'daily_open_close' for other date ranges, leaving the agent to infer usage. This is a missed opportunity, especially given the sibling list includes very similar-sounding tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safety. The description adds scoping details (anonymous IP, BYO key hash, account ID) and explains the behavior of omitting the key (list all). 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 concise and front-loaded with the main action. Every sentence adds value: retrieval purpose, scoping, pairing advice. No fluff 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?

Given no output schema, the description partially explains return (value or list of keys) but does not specify format or confirm return structure. It covers key behavioral aspects but lacks explicit detail on what the response looks like.

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

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

Schema coverage is 100% for the single optional parameter 'key'. The description adds meaning by explaining that omitting key lists all saved keys, and that it functions as a memory key. This goes beyond the schema's basic 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 retrieves a value saved via remember or lists all keys if omitted. It distinguishes itself from sibling tools remember (save) and forget (delete) by specifying the retrieval action and pairing advice. Concrete examples (ticker, address, notes) clarify usage.

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

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

The description explicitly says when to use (look up context stored earlier, avoid re-deriving) and mentions pairing with remember/forget. It doesn't explicitly state when not to use, but the purpose is clear. No alternative tools are mentioned, but siblings 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?

Beyond annotations (readOnlyHint, idempotentHint), the description discloses that returned events carry source, citation_uri, and raw payload. It explains the mark_read parameter's effect on subsequent calls, adding useful behavioral context.

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

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

The description is concise at three sentences, front-loaded with the purpose. Each sentence adds value: purpose, return fields, usage of parameters, and alternative endpoint. No wasted words.

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

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

Given the lack of output schema, the description covers return fields and parameter semantics well. It also mentions polling suitability and an alternative endpoint. Minor omission: no mention of pagination or limit behavior, but overall sufficient.

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

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

With 100% schema coverage, the baseline is 3. The description adds value by explaining the effect of mark_read and providing an example for type filtering. However, it largely rephrases schema descriptions without introducing new meaning.

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 user's subscription feed and returns recent alerts. It specifies the verb 'pull' and the resource 'subscription feed', making the purpose distinct from sibling tools like list_subscriptions or aggregate tools.

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

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

The description does not explicitly state when to use this tool versus alternatives. It mentions that polling works fine and provides an alternative REST endpoint for scripts, but does not give exclusions or compare against sibling tools like list_subscriptions or news.

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 significant behavioral context: multi-API fan-out, fallback logic (GDELT→GNews), soft-fail for USPTO, date format support, and return structure with citation URIs. No contradiction.

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

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

The description is a single, dense paragraph with examples front-loaded for quick understanding. Every sentence provides essential information, avoiding any redundancy or fluff.

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

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

Despite the tool's complexity (multiple sources, fallback logic, date formats) and no output schema, the description thoroughly covers all behavioral aspects: source details, fallback, return structure, and alternative tool usage. It is complete for effective agent invocation.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds value by clarifying usage (e.g., relative shorthand examples like '7d', '30d') and typical values ('30d' for monitoring), beyond the schema's basic definitions.

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

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

The description clearly defines the tool as a change feed for a company aggregating from SEC EDGAR, GDELT/GNews, and USPTO. It distinguishes from sibling tool 'entity_profile' by specifying when to use each.

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 example queries and explicitly directs users to 'entity_profile' for static profiles. While it doesn't list all when-not scenarios, the context is clear enough 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?

Description adds behavioral context beyond annotations: key-value scoping by identifier, persistence differences between authenticated and 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?

Four well-structured sentences, front-loaded with purpose, 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 key-value tool with two parameters, the description covers usage, behavior, and pairing with sibling tools comprehensively.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning (e.g., example keys) but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the tool's function: 'Save data the agent will need to reuse later' as a key-value store. It distinguishes itself from siblings by mentioning pairing with 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?

The description provides clear guidance on when to use ('when you discover something worth carrying forward') and mentions scoping and persistence. It lacks explicit when-not-to-use but otherwise strong.

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

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

Goes far beyond the readOnly/idempotent annotations by disclosing internal cascade behavior, graceful degradation ('if GLEIF or OpenFIGI is unavailable, the EDGAR identifiers still return'), ambiguity handling ('asserts nothing and returns figi_candidates'), and explicit `unresolved` listing. It also clarifies source labeling and ISIN-to-LEI mapping. No contradiction with annotations.

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

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

The description is front-loaded with sample queries and has clear SUPPORTED TYPES sections, but the `company` entry contains a very long nested parenthetical that is dense and run-on, making it harder to parse. Most sentences earn their place, but the structure could be tightened with bullet lists to improve scannability.

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

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

With no output schema, the description carries the burden of explaining return artifacts: it covers `figi_candidates`, `unresolved`, source-labeled identifiers, RxCUI plus ingredient/brand/citation, and degradation behavior. For a multi-source resolver with two entity types, nothing critical is missing for an agent to invoke it 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%, yet the description adds significant value: it explains the `value` param with examples (AAPL, 0000320193, ozempic), a detailed caveat about bond issuer naming, and ISIN input behavior. The `type` enum is expanded into meaningful subtypes. This exceeds the baseline 3 for full schema coverage.

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

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

The description states a precise verb+resource: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It names concrete supported types (company, drug) and explicitly frames itself as the first step when a name is present but an ID is needed. This distinguishes it from ID-consuming sibling tools even though none are named directly.

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

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

Provides explicit when-to-use guidance: 'Use FIRST whenever you have a name but need an ID.' It also gives concrete value-passing instructions with pitfalls ('for a bond that is the ISSUER exactly as printed... never the question's full noun phrase'). It does not explicitly name alternative tools or state when NOT to use it, but the precedence rule and examples give strong contextual direction.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds the return format (ranked list with score, confidence, signal density) and notes that the first entity is treated as the subject, which is useful behavioral detail. This is adequate but not exceptional.

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

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

Two sentences with no wasted words. First sentence states the action and key output, second provides concrete use case and return details. Perfectly front-loaded and efficient.

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

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

Despite having no output schema, the description adequately explains return values (ranked list with score, confidence, signal density). It covers constraints (2-8 entities, first treated as subject) and optional parameters (models, apiKey, context). The annotations already cover safety, so the description is complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, such as noting that context disambiguates common names and that entities are brand/business/product names. This is sufficient but does not significantly enhance understanding.

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

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

The description clearly states it compares AI visibility across multiple entities, probes each with ai_visibility_check, ranks by score, and surfaces most/least recognized. It provides a concrete use case example and distinguishes from siblings like ai_visibility_check (single entity) and compare_entities (generic comparison).

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

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

The description explicitly mentions competitive AI-marketing audits and gives an example question, providing clear context for when to use. It does not explicitly state when not to use or list alternatives, but the context is sufficient for most agents.

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 true. Description adds significant behavioral context: fans out to two services, partial failure behavior (sources_failed list), and timing (5-30s for first measurement). No contradiction.

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

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

Description is front-loaded with the core purpose, then details, use cases, and limitations. Every sentence provides unique, actionable information without redundancy. Well-structured for quick comprehension.

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 output schema, the description fully explains return values including summary block, advisory details, links, and alternative versions. Also covers edge cases (partial failures, fallback) and ecosystem scope. Complete for a composite scanning 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 clear descriptions. Description adds value by explaining version defaults to latest, and that package is for npm ecosystem. It also ties parameters to the composite check behavior, slightly exceeding the 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 composite purpose: 'should I add this npm package to my project' check, listing specific data sources (deps.dev and bundlephobia) and output fields. It distinguishes the tool from alternatives by noting that other ecosystems fall under deps.dev:version directly.

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

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

Explicitly tells when to use: 'whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also provides when-not-to (other ecosystems) and behavioral caveats (bundlephobia first-time delay, graceful degradation).

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds valuable behavioral details: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K character cap with truncation flag, and character offsets on passages.

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

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

Four dense sentences with zero waste. Front-loads purpose and usage, then technical details. 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?

Covers purpose, when to use, technical behavior (embeddings, windows, cap), pairing with sibling, and return value format. No output schema but mentions passages with offsets and scores, which suffices.

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 enriches each parameter: explains text max length, query as natural-language with examples, and limit default and range. Adds context beyond schema.

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

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

Description starts with 'Semantic search INSIDE a fetched record', clearly stating the verb (semantic search) and resource (inside a fetched record). Provides examples like SEC 10-K body and distinguishes from sibling ask_pipeworx_grounded.

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

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

Explicitly states when to use: 'when the record is too big to cram into the prompt'. Also pairs with ask_pipeworx_grounded, giving clear alternative usage 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about the data source and the purpose (adjusting historical price comparisons), but does not disclose details like pagination, rate limits, or data coverage limitations beyond 'US-listed ticker'.

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

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

The description is two sentences, front-loaded with the core purpose and data source, and ends with a clear use case. Every word earns its place; no fluff.

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

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

Given the tool's simplicity (3 optional parameters, no required fields) and the presence of an output schema, the description is fairly complete. It explains the data source, the fields, and the use case. However, it could mention that all parameters are optional (since none are required) and clarify the 'limit' parameter's role, but the output schema likely covers return structure.

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 0%, so the description must compensate. It mentions 'split ratio, execution date, ticker' as fields, which maps to the 'ticker' and 'execution_date' parameters, but does not explain the 'limit' parameter or provide format details (e.g., date format). The description adds some meaning but leaves gaps for the 'limit' parameter and date format.

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

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

The description clearly states the tool provides historical stock splits for a US-listed ticker, specifying the data source (Massive, formerly Polygon.io) and the key fields (split ratio, execution date, ticker). It distinguishes itself from siblings like 'dividends' and 'aggregates' by focusing on split events.

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 the use case: 'Use to adjust historical price comparisons across split events.' It implies when to use this tool (when needing split data) but does not explicitly mention when not to use it or alternatives, though the sibling list includes related tools like 'dividends' and 'aggregates'.

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 idempotentHint=true, but the description indicates each call returns a new subscription id, implying non-idempotent behavior. This is a contradiction. The description does disclose auth requirements and constraints (SMS cap, phone verification), adding value beyond annotations, but the idempotency issue reduces transparency.

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

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

The description is front-loaded with purpose and return, then requirements, types, and delivery. It is fairly long but well-structured. Some detail could be removed or placed in schema, but it remains clear and organized.

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

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

Given the tool's complexity (multiple types, delivery options, constraints), the description covers auth, type-specific parameters, delivery details (including webhook signing and auto-disable), and return value. No output schema exists, but the return is adequately described. It enables an agent to use the tool correctly.

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

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

Schema covers all parameters (100% coverage), and the description adds significant detail with examples for each type (e.g., sec_8k items, polymarket_edge topic) and delivery channel constraints (webhook signing, SMS cap). This goes well beyond the schema descriptions.

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

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

The description clearly states the verb (create), resource (subscription), return value (new subscription id), and distinguishes from siblings like list_subscriptions and unsubscribe. It lists supported types and delivery channels, making the purpose unambiguous.

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

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

The description provides context for when to use the tool (proactive monitoring), specifies requirements (Pipeworx OAuth account), and details type-specific parameters. However, it does not explicitly exclude use cases or compare to alternatives like ask_pipeworx or polymarket_edges, leaving some 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?

Annotations already indicate readOnly, idempotent, and openWorld. The description adds substantial behavioral detail: it returns category-bucketed example questions with exact tool+argument shapes, drawn from a live catalog, and can be called with no arguments or a topic. 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 bit long but front-loaded with common user questions and well-structured. Every sentence adds value: scope, return format, parameter usage, and when to use. A slight trim could improve conciseness, but overall 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?

Given no output schema, the description adequately covers the return format (category-bucketed examples). It also addresses how to call meta-tools and provides sufficient context for an agent to understand the tool's role and behavior without additional information.

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 coverage is 100% with one parameter already described. The description goes further by listing example topic values and explaining the effect of omitting the parameter (full spread) versus passing a topic (focused). This adds significant value beyond the schema.

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

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

The description clearly states it is the onboarding entry point for a newly connected agent, using common trigger phrases and explicitly listing what it returns (category-bucketed example questions). It distinguishes itself from siblings like 'discover_tools' and 'ask_pipeworx' by focusing on demonstrating the agent's capabilities.

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

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

The description explicitly says when to use it ('FIRST when you do not yet know what Pipeworx can do') and explains how to pass an optional topic for focus. While it doesn't state explicit cases when NOT to use it, the usage context is clear and actionable.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds behavioral context by listing the exact fields returned, which goes beyond annotations, but it does not cover edge cases like missing tickers or data latency. This is a meaningful but not exhaustive addition.

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 concise sentence that front-loads the action and enumerates key fields without unnecessary words. Every phrase earns its place.

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

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

For a simple lookup tool with an output schema and comprehensive annotations, the description covers purpose, parameter semantics, and expected output fields. It lacks alternative usage guidance, but that is addressed in the usage guidelines dimension. Overall, it provides sufficient information for correct invocation.

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

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

The schema has one parameter ('ticker') with no description (0% coverage). The description compensates by stating 'single ticker', clarifying that exactly one symbol is expected, and the schema example 'AAPL' provides format context. However, it does not elaborate on valid formats or constraints, leaving some ambiguity.

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

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

The description uses a specific verb ('Fetch') and resource ('full Massive reference details for a single ticker'), and enumerates the fields returned (company name, description, SIC code, etc.). This clearly distinguishes it from sibling tools like 'tickers' (plural) and 'entity_profile' by emphasizing 'single ticker'.

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: use this for a single ticker's reference details. However, it does not explicitly name when to prefer this over alternatives like 'tickers' or 'entity_profile', nor does it state exclusions, so it lacks explicit alternative guidance.

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

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

Annotations already declare the tool as read-only, idempotent, non-destructive, and open-world. The description adds useful context about the scope (US stocks, options, indices, forex, crypto) and the exact fields returned. It does not disclose any potential quirks like pagination or rate limits, but given the strong annotations, the description provides additional value without contradicting the structured metadata. A score of 3 reflects that it adds some behavioral context beyond annotations but not deep detail.

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

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

The description is two sentences long, with no redundant information. It front-loads the primary purpose and includes a clear action-oriented verb. Every sentence adds value, and it avoids unnecessary fluff.

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

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

The tool has an output schema and strong annotations, but the description leaves parameter semantics entirely unaddressed. It covers the core function and return fields sufficiently for a basic use case, but for a tool with 8 parameters and zero schema descriptions, it lacks essential guidance on filtering, sorting, and limiting. The description is minimally adequate but not complete.

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

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

Schema description coverage is 0%, meaning no parameter descriptions are provided in the schema, and the description does not compensate. The description mentions markets and returns but does not explain parameters like search, limit, market, exchange, or sort. With 8 parameters, the agent would have to rely solely on the schema's bare property names and examples. This is a significant gap that the description should have addressed.

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 searches a reference universe for tickers across multiple asset classes, and specifies the returned fields (symbol, name, market, etc.). It also gives a concrete use case: resolving a company name to a tradable symbol. This distinguishes it from siblings like ticker_details (which likely provide details for a specific symbol) and exchanges (which likely list exchanges).

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 a clear when-to-use scenario: 'Use to resolve a company name to a tradable symbol.' It implies the tool is appropriate for symbol lookup. However, it does not explicitly mention when not to use it or offer alternatives like ticker_details for when a symbol is already known, so it lacks explicit exclusions. This is still adequate context but not exhaustive.

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 that the row is deactivated (not deleted) and that historical events remain available. This adds value beyond annotations, which already indicate non-destructive 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?

Two sentences with no wasted words. Front-loaded with the action, then additional context. Highly efficient.

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

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

For a simple tool with one parameter and no output schema, the description covers all necessary aspects: purpose, ownership constraint, and side effect (deactivation). 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%, and the description adds that the id is returned by subscribe, which is minor. No additional semantic value beyond the schema for the parameter.

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

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

The description clearly states the action 'Cancel a subscription by id', specifying the verb and resource. It distinguishes from sibling tools like 'subscribe' and 'list_subscriptions' by focusing on cancellation.

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

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

Provides clear context: ownership is enforced so only own subscriptions can be cancelled. It does not explicitly list alternatives but implies when to use by stating the limitation.

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 readOnly/idempotent annotations, the description discloses important behavioral traits: the SEC EDGAR + XBRL fast path for financial claims, the grounded pipeline fallback for other claims, and the return structure (verdict, actual value with pipeworx:// citation, reasoning). It also explains the critical distinction between could_not_verify (no evidence for/against) and unsupported (no source), which is essential for correct caller interpretation.

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

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

The description is dense but every sentence earns its place: trigger phrases, usage guidance, routing behavior, return values, error semantics, and efficiency benefits. It is front-loaded with concrete examples and organized logically, 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 lacking an output schema, the description fully covers return values (verdict types, actual value, citation, reasoning) and explains edge cases like could_not_verify and unsupported. It also sets expectations about replacing sequential calls, making it complete for an AI 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 coverage is 100% and both parameters (claim, tolerance_pct) already have detailed descriptions, including examples, default behavior, and suggested values. The tool description adds only minimal additional context (e.g., 'exact percent-delta math') and does not materially enhance parameter understanding beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as natural-language claim verification, with explicit trigger phrases ('fact check', 'verify the claim that...') and a specific resource: checking factual correctness against authoritative sources. It distinguishes itself from sibling tools by focusing on verifying claims rather than general Q&A or research, and it clearly states the scope of what the tool does.

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

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

The description provides explicit guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the internal routing for company-financial claims versus any other factual claim, and notes that it replaces 4–6 sequential calls, giving clear context for when to invoke. However, it does not explicitly name alternative tools or state when NOT to use it, so it stops short of full when-not guidance.

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