Eodhd

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the return format (per-model score, confidence, signals, raw_response, combined view) and cost implications (free default, BYO key for Anthropic). No contradictions.

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

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

Three sentences with crucial information front-loaded. First sentence states purpose and output. Second explains model options and cost. Third summarizes use cases. No redundant phrases.

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

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

For a tool with 4 parameters and no output schema, the description covers the main function, model options, cost, return structure, and use cases. It lacks details on error handling or rate limits, but is sufficient for typical use.

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

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

Schema coverage is 100%. The description adds meaning beyond schema by explaining the default model, the key requirement for Anthropic, and examples for entity. This helps the agent understand parameter relationships and cost.

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 specifies the verb 'probe', the resource 'LLMs', and the outcome 'score visibility (0-100) per model'. It distinguishes this tool from Q&A siblings like ask_pipeworx by focusing on visibility scoring rather than answering specific questions.

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

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

The description explains when to use the API key and mentions three specific use cases (AI-marketing audits, pre-launch checks, competitive monitoring). It does not explicitly state when not to use, but the context is clear enough for an agent.

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

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

Annotations already establish read-only, idempotent, open-world behavior. The description adds useful behavioral context beyond that: it auto-routes to the right sub-tool, fills arguments, and returns stable citation URIs. It does not discuss failure modes or quotas, but those are not critical given the strong annotation 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 the length is earned: it front-loads the override over web search, then provides categories, trigger phrases, examples, and routing alternatives. A few phrases are slightly dense, but the overall structure is scannable and each section serves a distinct purpose.

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

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

For a high-complexity router with no output schema, the description is exceptionally complete: it enumerates covered domains, gives example queries, states the return format (structured answer with citation URIs), and names the key alternative (deep_research). An agent has enough context to select this tool and construct a valid question.

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 documents the question parameter plus all aliases, so the description need not repeat parameter syntax. The examples and trigger phrases reinforce natural-language usage, but they do not add meaning beyond what the schema's property description already conveys. 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 opens with a clear directive ('PREFER OVER WEB SEARCH') and states a specific role: routing a factual question to one of thousands of verified-source tools and returning a structured answer with pipeworx:// citations. It also differentiates itself from the sibling deep_research for broad multi-part research and notes that it already covers live news, so its position in the toolset is explicit.

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

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

It gives explicit when-to-use guidance ('Use whenever the user asks...') with concrete trigger phrases and examples, and explicit when-not-to-use guidance via the deep_research alternative. This is more actionable than most tool descriptions and leaves little to inference.

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 annotations already indicating readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the description goes beyond them by disclosing that this is an experimental edge with candidate routing improvements that may be active, that it currently matches the stable router exactly, and that it falls back to nothing—it is a full working router. It does not reveal internal routing mechanics beyond the candidate comparison, but for a read-only query router this is strong 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 moderately sized but information-dense, covering beta status, equivalence, experimental behavior, current state, usage instruction, and fallback semantics in a few sentences. It is front-loaded with the core 'beta version of ask_pipeworx' identity. Minor redundancy exists ('identical universal router' and 'same 5,798 tools, same arguments, same response shape' restate the same point), but overall it earns its length.

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

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

For a read-only, idempotent, open-world query router with no output schema and a simple single-required-parameter schema, the description is complete. It explains the beta nature, current state (no active candidate), usage (use like ask_pipeworx when wanting newest routing), and fallback behavior. An agent has everything needed to decide whether and how to call this tool.

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

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

Schema description coverage is 100% and the schema documents the parameter and all aliases thoroughly. The description adds that it accepts the same arguments as ask_pipeworx, reinforcing the universal-router semantics, but doesn't add syntax or formatting details beyond the schema. The description's mention of 'same arguments' adds some cross-tool context, but the schema already covers parameter meaning fully.

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

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

The description clearly identifies this as a beta version of ask_pipeworx, a universal router with the same tool set and arguments as the stable version. It explicitly distinguishes itself from ask_pipeworx by mentioning candidate routing improvements and experimental status. The verb 'ask' plus the explicit comparison to the sibling makes purpose unambiguous.

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

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

The description explicitly says to use it exactly like ask_pipeworx when you want the newest routing, and explains that results are compared against the stable router. It also states that no candidate is active right now, so it currently matches ask_pipeworx exactly. This gives clear when-to-use guidance and implicitly differentiates it from the stable sibling.

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

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

Annotations already mark this read-only, open-world, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: result extraction from only the tool result, explicit refusal reasons, return shape, and the extra LLM call cost. 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: mechanism, return/refusal behavior, usage context, and cost tradeoff. It is well-structured and front-loads the most important distinguishing trait (hallucination resistance).

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

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

Given the rich annotations, complete schema coverage, and the description's explicit return/refusal shape, nothing critical is missing. The agent knows what the tool does, when to choose it, what it returns, and what cost tradeoff applies.

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

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

Schema description coverage is 100%, with the question parameter and all aliases fully documented in the schema. The description does not add parameter-specific semantics, but that is not necessary here because the schema already carries the full burden.

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

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

The description clearly identifies this as a hallucination-resistant answer mode that routes like ask_pipeworx, fetches data, and extracts answers strictly from tool results. It distinguishes itself from ask_pipeworx by emphasizing grounded extraction and explicit refusal behavior, 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?

It gives explicit when-to-use guidance: use whenever an answer will be quoted, cited, or acted on and the agent must not invent facts, with concrete examples. It also names the alternative ask_pipeworx and explains the cost tradeoff, advising ask_pipeworx for casual lookups.

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

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

The description goes far beyond annotations by detailing safety behaviors (low-confidence resolution short-circuits), edge cases (closed/dead markets), resolution-rule risk (cancellation rules, pure-rules loss), data fallbacks (GDELT 429s), and tradeability warnings (illiquid wide spreads), providing comprehensive 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 comprehensive but verbose, containing many detailed examples and edge-case discussions. While structured and front-loaded with purpose, some sentences could be condensed without losing clarity.

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

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

Despite lacking an output schema, the description thoroughly covers all relevant output fields (market, analysis, evidence, match confidence, parent event, news fields) and edge cases (low confidence, closed markets, wide spreads, cancellation rules), making it complete 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?

The description adds meaningful context beyond the schema: clarifies market accepts slug/URL/question, explains depth default (thorough), and details include_raw behavior (response size, use cases). This adds value given high schema coverage.

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

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

The description clearly states the tool's purpose with a specific verb+resource ('research a Polymarket bet by pulling Pipeworx data') and explicitly distinguishes it from sibling tools by characterizing it as an all-in-one research call for a single bet.

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 contexts ('Use for should I bet on X, what does the data say about Y, or is there edge in Z') and example use cases, but does not explicitly mention when not to use the tool or contrast it with sibling alternatives.

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

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

The description adds substantial detail beyond the annotations: it explains data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), fiscal year handling, metric sorts by primary metric, and return format (paired data + citation URIs). Annotations already indicate idempotency and read-only, which the description reinforces.

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

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

The description is a single paragraph that efficiently packs examples, behavior, and data sources. It could be slightly more structured (e.g., bullet points for entity types), but every sentence earns its place with no redundancy. The front-loading with user-facing phrases is helpful.

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

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

Given the tool's complexity (two entity types, multiple data sources, sorting, citations), the description covers all necessary aspects: when to use, what data is returned, how results are sorted, and efficiency claims. Without an output schema, the description adequately explains return values.

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

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

With 100% schema coverage, the description still enriches understanding: it clarifies how the 'type' parameter affects data retrieval (companies: financials; drugs: adverse events/trials) and what 'values' accept (tickers/CIKs or drug names), plus explains result sorting. This goes beyond the schema's basic enum and array 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 specifies the tool's purpose as side-by-side comparison of 2–5 entities (companies or drugs) in one parallel call, using clear example queries like 'X vs Y' and 'rank these companies'. It distinguishes from sequential lookups, which are siblings, so the tool's unique function is unambiguous.

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

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

The description explicitly advises to ALWAYS PREFER this tool over sequential single-pack lookups when comparing entities, providing strong usage guidance. However, it does not detail when not to use it or mention alternative tools beyond the sequential lookup 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?

Adds substantial behavioral detail beyond annotations: account requirements, grounded structured-source behavior, explicit gaps[] instead of inventing answers, resolvable citation URIs, contradiction[] scans, excerpting behavior, and expected latency. This is far more than the readOnly/openWorld annotations already convey.

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

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

The description is long but dense and front-loaded with the account requirement and fallback alternative before the core behavior. Every sentence adds useful context, though a few depth-tier details are repeated from the schema, making it slightly longer than strictly necessary.

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

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

For a complex tool with no output schema, the description thoroughly covers return values, confidence/source/fetched_at fields, citation URIs, gaps[], contradictions[], iteration behavior, and latency. It also covers account constraints and the alternative tool, leaving an agent well-equipped to invoke and interpret results.

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

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

Schema description coverage is 100%, so the baseline is 3. The tool description reinforces the depth semantics and question decomposition but mostly restates what the schema already provides, adding operational context rather than new parameter-level 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?

States a specific verb and resource: grounded multi-source research over Pipeworx's 1,517 structured data sources in one call, decomposing the question and routing facets in parallel. It explicitly distinguishes itself from open-web search and names ask_pipeworx for single lookups, so an agent can tell it apart from 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?

Gives explicit when-to-use guidance: best for broad/multi-part questions over structured data, with examples. It also states when NOT to use it, directing to ask_pipeworx if not signed in or if the task is a single lookup, plus the paid-tier constraint for depth:'thorough'.

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 and idempotentHint=true. Description adds that results include full input schemas with examples and are ready to call directly, which is valuable behavioral context beyond annotations. No contradictions.

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

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

The description is front-loaded with the core purpose and usage guidance. It's moderately concise but includes a long list of example domains, which could be trimmed. Still well-structured.

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

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

No output schema, but the description explains what is returned (names, descriptions, schemas, examples). Parameters are fully described with aliases and examples. Adequate for a discovery 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% and description mentions aliases and provides examples. However, the description doesn't add critical meaning beyond what the schema already provides; the examples are helpful but not essential.

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

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

The description states 'Find tools by describing the data or task' with a specific verb and resource, and lists many example domains. It clearly distinguishes itself from sibling tools as the discovery entry point.

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

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

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear when-to-use guidance and implies when not to use (when you already know the tool).

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds substantial operational context beyond annotations: fan-out across eight source families, per-section empty-is-real semantics ('an empty section is a real "no data", not a bug'), a soft-fail for the sunset USPTO PatentsView API, GDELT→GNews fallback, and resolved:false with an explicit notes line for private companies. 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?

Dense, but nearly every sentence carries operational value: trigger phrases, routing preference, source fan-out, return fields, failure semantics, and input forms. The seven near-duplicate trigger phrases ('tell me about X' / 'research Acme' / 'brief me on Tesla') are the only real redundancy, and the single-paragraph wall of text could benefit from light structuring.

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?

This is a high-complexity tool (two params, eight-plus data sources, three input forms, multiple edge cases) with no output schema, so the description carries the full disclosure burden. It covers every return section (cik/company_name, recent_filings with URIs, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI), sources_used/sources_failed for diagnosing empty results, and every failure mode. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value above the schema: it documents that type accepts 'company' or 'ticker' interchangeably, gives concrete value examples (AAPL, 0000320193, Moderna), and explains the SEC EDGAR name-resolution behavior with its resolved_from/resolved_to side effects. This meaningfully exceeds what the schema alone provides.

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

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

The description states a specific verb+resource: 'full cross-source profile of a US public company in ONE parallel call.' Seven trigger-phrase examples ('brief me on Tesla', 'company profile for Microsoft', 'everything you know about $TICKER') anchor the trigger surface, and 'US public company' scopes it precisely enough to distinguish it from generic research siblings like deep_research or bet_research.

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

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

Explicit routing guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' directly names the alternative pattern and the condition that selects this tool. It also covers input-conditional behavior (private companies return resolved:false, not failure). However, it does not explicitly differentiate from near-neighbor siblings such as resolve_entity, compare_entities, or deep_research, leaving some routing decisions to inference.

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, safe, idempotent. Description adds return data OHLCV+adjusted close, date range, and period options, which are beyond annotations.

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

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

Two sentences plus example; no superfluous content. Efficiently conveys core purpose and usage.

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, parameters, example, and return type. Lacks pagination or rate limit info, but schema provides API key limits. Sufficient for a simple data retrieval 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 describes all parameters (100% coverage). Description adds a concrete example and symbol format explanation, providing extra clarity beyond schema.

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

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

Clearly states it gets historical daily prices (OHLCV plus adjusted close) for a symbol in EXCHANGE.SUFFIX format. Distinguishes from sibling eodhd_fundamentals.

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 context for when to use (get historical prices) and symbol format, but lacks explicit when-not-to-use or alternative tool guidance.

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

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

Annotations already provide readOnlyHint and idempotentHint. Description adds list of returned data categories but does not mention rate limits or external API dependency beyond parameter description.

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

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

Two sentences plus example; efficient, front-loaded with main purpose, no fluff.

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

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

For a tool with two clear parameters and rich annotations, description adequately lists output categories and provides example. Without output schema, could be more explicit about 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 coverage is 100% with detailed parameter descriptions. Tool description repeats symbol format and example, adding minimal new semantic 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 it retrieves fundamentals, analyst estimates, and company data. It specifies symbol format with exchange suffix, differentiating from likely sibling eodhd_eod_prices which provides price data.

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

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

Provides an example and symbol format but no explicit guidance on when to use vs alternatives like eodhd_eod_prices. Usage context is implied but not contrasted.

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

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

Annotations already indicate destructiveHint=true, idempotentHint=true. Description adds no extra behavioral context like error handling or idempotency 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: first states purpose, second gives usage guidance. 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 1-param tool with no output schema, description covers purpose and usage. Could mention return value or error case, but not critical.

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%. Description only mentions 'by key', adding no extra meaning beyond the schema's description.

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

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

Description clearly states verb 'delete' and resource 'memory by key'. Explicitly distinguishes from siblings 'remember' and 'recall'.

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

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

Provides clear when-to-use scenarios: stale context, task done, clear sensitive data. References related tools. Lacks explicit when-not-to-use, but adequate.

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

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

Beyond the annotations (read-only, idempotent), the description adds that the tool fetches the page, extracts title/description/links, and outputs standard markdown. This provides sufficient behavioral context without contradicting any annotation.

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

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

Three well-structured sentences: purpose, process, use cases. No wasted words, front-loaded with the core action. Ideal conciseness for an AI agent.

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 explains the output format (single text blob) and internal steps, covering essential aspects for a simple tool. It could mention error handling for invalid URLs, but overall it's complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minor context for the 'url' parameter (e.g., accepting specific pages) but does not significantly extend the schema's own descriptions.

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

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

The description clearly states the tool generates an llms.txt file for any URL, with specific verb and resource. It also lists distinct use cases (client indexing, personal project, competitor audit), effectively differentiating it from 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 explicitly lists three common usage scenarios, providing clear context for when to use the tool. It does not, however, state when not to use it or mention alternatives, which would warrant a higher score.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so description's behavioral disclosure is supplementary. Adds context about default active-only listing and inactive inclusion via parameter. No contradictions.

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

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

Two sentences, no redundancy, front-loaded with purpose. Every sentence serves a distinct role: purpose + return fields, and usage guidance.

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

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

Given tool simplicity, one optional parameter, no output schema, and strong annotations, the description is adequate. It covers purpose, usage, and parameter implications.

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 parameter 'include_inactive' is well-described. Description goes beyond schema by listing return fields (id, type, params, created_at, last_fired_at, fire_count), adding value for agent understanding.

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

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

Description explicitly states 'List the caller's active subscriptions' (specific verb and resource) and lists returned fields. Distinguishes from sibling tools like 'subscribe' and 'unsubscribe'.

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

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

Provides clear usage guidance: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' Implicitly suggests when to use but does not explicitly state when not to use or provide alternatives.

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

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

Annotations are all false, providing no safety or side-effect hints, so the description carries the full burden. It discloses many behavioral traits: rate limiting (5/day), non-billing (free, no quota), the claim_token return for anonymous filing, later status checking, and the team's daily digest cadence. This exceeds typical transparency and gives the agent actionable 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 longer than average, but each sentence earns its place. It front-loads the core purpose, then covers usage, constraints, and the token workflow in a logical sequence. Despite its length, it is dense with no filler or redundancy, making it well-structured and appropriately concise for the complexity of the tool.

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

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

Given no output schema and a complex tool with 4 parameters and nested objects, the description is remarkably complete. It explains what the tool does, when to use it, how to submit different feedback types, the return token behavior, and operational constraints like rate limits and privacy. The agent is fully informed to invoke the tool correctly without ambiguity.

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 every parameter already has a detailed description. The description adds extra semantics beyond the schema by explaining the claim_token round-trip workflow (file then later pass token) and reinforcing that message should describe issues in terms of Pipeworx tools, not paste user prompts. This goes beyond the schema's basic parameter docs.

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

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

The description opens with a specific and clear statement: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It identifies the exact verb (tell/send feedback), the resource (Pipeworx team), and the categories of input (bug, feature, data gap, praise). This clearly distinguishes it from sibling tools like ask_pipeworx, which are for asking questions, not reporting issues.

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 extensive usage guidance: when to use each feedback type, an explicit exclusion for tools from other MCP servers, and a rule to identify Pipeworx tools by name. It also explains the claim_token workflow and the daily rate limit. This is textbook guidance on when and when not to use the tool, surpassing what any alternative tool description offers.

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

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

Beyond annotations (readOnly, openWorld, idempotent, non-destructive), the description adds: data source (CF analytics-engine), no PII, caching behavior (5min-1h). 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 concise (4 sentences), front-loaded with output, then use cases, then source details. Every sentence adds value; no redundancy.

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

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

For a simple tool with one optional parameter, rich annotations, and no output schema, the description fully covers purpose, usage, and behavior. No gaps.

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

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

The single parameter 'window' is fully covered in schema (enum with description). The description adds semantics about short vs long window behavior, providing extra value beyond the schema.

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

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

The description clearly states the tool returns 'top tools, top packs, and total call volume' over a window, with a specific verb and resource. It distinguishes from siblings by focusing on what other agents are calling, which is unique among the listed tools.

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

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

Three explicit use cases are provided (discovering hot data sources, confirming canonical tools, aligning use cases). No direct exclusion or alternative mention, but the use cases are 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, idempotentHint, destructiveHint false. The description goes beyond by detailing behavioral nuances: the fill check against live CLOB depth, Jaccard similarity threshold, partition filter, and the condition for skipping trades. No contradictions with annotations, and it adds substantial 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 long but well-structured with sections (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK) and front-loaded purpose. Every sentence provides necessary detail for a complex tool. A slight reduction in length could improve conciseness without losing clarity.

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

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

Despite no output schema, the description comprehensively documents the response fields (opportunities[] structure, partition_check fields) and edge cases (fill check, low similarity, partition filter). This fully informs an AI agent about what to expect and how to handle results.

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

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

Schema coverage is 100%, but the description enriches both parameters with concrete examples (e.g., 'fed-decision-may-2026' for event, 'Fed rate decision' for topic) and clarifies the precise format and use cases. This adds significant value 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 tool finds arbitrage opportunities via 'monotonicity violations + partition-sum checks'. It distinguishes itself from siblings like polymarket_edges by explicitly naming its unique methodology and modes (trending scan, event, topic). The verb 'Find' and specific resource 'Polymarket' make the purpose highly specific.

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 defines when to use each mode: no args for trending scan, `event` for a specific market, `topic` for cross-event scanning. It also warns against trading when realizable edge is ≤0 and directs custom sizing to polymarket_fill_risk. This provides clear usage context and alternatives, earning top marks.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds extensive behavioral details: caching at 1h KV level, response structure, edge computation after slippage, Kelly caps, 24h-move warning. 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 very long and dense, diving into technical details of model families, diagnostic counters, and knobs. While comprehensive, it lacks conciseness and front-loads less critical information.

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

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

Given the complexity (9 parameters, no output schema, multiple segments), the description is remarkably complete. It explains the algorithm, segments, diagnostics, caching, and all tradeable-edge knobs without needing a separate output schema.

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

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

Schema coverage is 100% with descriptions for all 9 parameters. The description does not add much on individual parameters beyond the schema but provides high-level context on segments and knobs. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: scanning Polymarket markets for opportunities where Pipeworx data disagrees with market price. It distinguishes from siblings like polymarket_arbitrage and polymarket_edge_tracker by focusing on Pipeworx data vs market price.

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

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

The description is built for 'what should I bet on today' and explains the three segments and their triggers. It mentions Fed bets surface but are excluded. However, it does not explicitly state when to use this tool versus alternatives like polymarket_arbitrage.

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

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

Annotations already declare read-only and idempotent properties. The description adds significant behavioral context: explains the three-part response (tracked, expired, snapshot_dates), meaning of negative edge_pp_net, and limitations like 60-day TTL and daily closes. 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 relatively long but well-structured into core question, response details, and limitations. Every sentence adds necessary context, though it could be slightly more concise. Front-loaded with the key question.

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

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

Despite no output schema, the description fully documents the response structure (tracked with time-series, expired with lifespan, snapshot_dates) and limitations (TTL, data gaps, decay method). Comprehensive for a complex tool generating telemetry.

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

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

Schema coverage is 100%, but description adds value by explaining days as lookback (default 14, max 30) and window as 'snapshot family' with examples. Provides context beyond schema, though schema already describes parameters adequately.

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 'edge persistence and decay telemetry' from daily snapshots, answering a specific question about edge longevity. It distinguishes itself from sibling tools like polymarket_edges by focusing on tracking edges over time rather than just listing them.

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

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

The description contrasts fresh vs. aged edges to imply use cases, and notes decay is daily not intraday. However, it does not explicitly state when to avoid this tool or mention alternative tools for edge analysis, leaving some guidance implicit.

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

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

Annotations already indicate read-only, idempotent, and open world. The description adds significant context: requires one of market or event, defaults, behavior (walk ladder, return top of book, VWAP, slippage, etc.), basket mode details, and warnings about thin legs and forced directional risk. No contradiction with annotations.

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

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

The description is relatively long but well-structured with clear sections (SINGLE-MARKET, BASKET) and bullet-like explanations. Every sentence adds value, though some minor redundancy could be trimmed. It is appropriately front-loaded with the core purpose.

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

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

Despite no output schema, the description lists return fields (top_of_book, vwap_fill_price, slippage_pp, etc.) and verdict. It covers both modes, defaults, edge cases, and why to use it. The explanation of risks (thin legs, directional risk) makes it complete for an agent to use correctly.

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

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

Schema coverage is 100% with all parameters described. The description adds meaning beyond schema: explains difference between single-market and basket modes for size_usd, default auto for side in basket mode, and clarifications on interpretation. This is valuable additional 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 it is a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. It provides specific verbs and resources, and the context signals show it is distinct from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

The description explicitly tells when to use this tool: before acting on polymarket_arbitrage signals or trades above ~$500. It also explains why (theoretical overround not capturable on thin books, partial basket fills create directional risk). This provides clear guidance on alternatives and exclusions.

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

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

The description is exceptionally transparent: it explains compatibility_warning and compatibility_codes, the meaning of null temporal alignment, the fee treatment, skipped comparison counters, per-entry flags, and the fact that unclassified legs are never paired. These details go far beyond the readOnlyHint, openWorldHint, and idempotentHint annotations and meaningfully shape how an agent should interpret results.

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 well-structured, with clear sections for modes, response fields, safety fields, and caveats. Every sentence contributes operational guidance, and the most important purpose statement is frontloaded. The density is justified by the tool's complexity and the absence of an output schema.

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

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

For a tool with no output schema and a rich response format, the description covers everything an agent needs: how to invoke both modes, what the response contains, how to interpret safety and compatibility codes, how fees are handled, and what the skipped counters mean. It is effectively a complete usage manual.

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 all three parameters are already documented. The description adds value by explaining how topic auto-fetches matching events, how the explicit parameters override the mapped side, and that both modes run the same token-overlap matcher — useful semantic context not present in the schema alone.

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

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

The opening sentence names the exact deliverable — a cross-venue spread between Kalshi and Polymarket for the same resolving question — which clearly identifies what the tool computes. It goes further to describe the two input modes and the real-world logic behind the spread, making it easy for an agent to distinguish this from other market tools.

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

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

The description provides strong usage context: it explains the two modes, when to use the pre-mapped topic shortcuts vs explicit ticker/slug pairings, and warns that pre-mapped topics are not automatically tradeable. It does not explicitly name alternative sibling tools or state when to prefer them, but the invocation guidance is otherwise clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds scoping (anonymous IP, key hash, account ID) and listing behavior. Good complement.

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 main action, efficient sentences. Slightly verbose with pairing mention, but overall concise.

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

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

For a simple read tool, description covers usage, scoping, and pairing. No output schema, but return behavior is implied. 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 100%, baseline 3. Description restates schema detail (omit key to list) but doesn't add new parameter-level meaning beyond that.

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

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

Clear verb 'retrieve' with specific resource 'a value previously saved via remember' or 'list all saved keys'. Distinguishes from siblings by naming 'remember' and 'forget' explicitly.

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?

Explains use case (look up stored context without re-deriving) and scope (by identifier). Could note when not to use, but it's straightforward.

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

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

Adds context beyond annotations by detailing return fields (source, citation_uri, raw payload) and the mark_read mechanism. However, the mark_read side effect contradicts the readOnlyHint annotation.

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

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

Four sentences, front-loaded purpose, and no wasted words. Slightly verbose with extra details about the HTTP endpoint, but still efficient.

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

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

No output schema, but description compensates by listing returned fields. Provides sufficient context for using all parameters and the polling behavior.

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

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

Schema coverage is 100%, and the description adds value with examples (e.g., 'sec_8k' for type) and explains the purpose of mark_read for pagination.

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 ('Pull fired events') and identifies the resource ('your subscription feed'), distinguishing it from sibling tools like 'list_subscriptions' and 'subscribe'.

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

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

Provides filtering guidance (type, since) and explains mark_read behavior. Mentions an alternative HTTP endpoint for scripts/dashboards, but does not explicitly state when not to use this tool.

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

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

Describes fan-out to SEC EDGAR, GDELT→GNews fallback, USPTO soft-fail, return structure with grouped changes and citations, adding substantial context beyond annotations.

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

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

Well-structured with examples and clear sections, but slightly verbose; every sentence earns its place, though a bit of trimming could improve conciseness.

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

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

Comprehensive for a multi-source tool: outlines sources, fallbacks, return hints, and directs to alternative tool for static data; lacks only minor error details which are not critical.

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?

All parameters are described in schema (100% coverage), and description adds useful details like accepted date formats, relative shorthand, ticker/CIK input, and enum restriction.

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 concrete example queries and clearly states the tool provides a change feed for a company from multiple sources (SEC, news, patents) in one parallel call, distinguishing it from sibling `entity_profile`.

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

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

Explicitly advises to use `entity_profile` for static profiles instead of change feed, and provides example query patterns and typical monitoring recommendations.

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 context beyond annotations: scoping by identifier, persistence differences for authenticated vs anonymous users, and 24-hour expiry. No contradiction with annotations (readOnlyHint=false, idempotentHint=true).

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

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

Single well-organized paragraph: purpose, usage, storage details, pairing with siblings. No redundant sentences; every sentence adds value.

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

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

For a simple tool with 2 required params and no output schema, the description is fully complete: covers when, what, how stored, and relationship to siblings.

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

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

Schema coverage is 100% with descriptive parameter descriptions. Description adds semantic guidance (key naming conventions like 'subject_property', 'target_ticker'), providing extra value.

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

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

Clearly states the tool saves data for reuse across conversations/sessions, with specific examples (ticker, address, preference, research subject). Distinguishes from sibling tools 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?

Explicitly tells when to use (discover something worth carrying forward) and when to use alternatives (pair with recall/forget). Includes scoping and persistence 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?

Beyond the readOnly/openWorld/idempotent annotations, the description discloses cascading internal lookups, graceful degradation when GLEIF/OpenFIGI are unavailable, and explicit `unresolved` output behavior. It also reveals that ISIN lookups resolve to the issuing legal entity, which is non-obvious 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 long but information-dense: every parenthetical covers a lookup case or edge behavior. The main purpose and 'Use FIRST' instruction appear early, but the initial string of user-query examples delays the core definition slightly.

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 two types and multiple upstream sources, the description covers input formats, outputs (CIK/ticker/company_name, LEI, FIGI, RxCUI+ingredient+brand), degradation behavior, and unresolved handling. No output schema exists, so this level of detail is sufficient for an agent calling 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?

Though the schema already covers both parameters at 100%, the description adds important invocation semantics: ISIN is accepted for company lookups, non-equity instruments resolve via name search, and the value description's 'ENTITY NAME ONLY' rule is expanded with a concrete bond-issuer example ('NEW YORK ST DORM AUTH' not '... revenue bonds').

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 'resolve[s] a user-spoken NAME to the canonical/official identifiers other tools require as input' and enumerates the supported types ('company', 'drug'). It also differentiates itself by positioning resolution as the first step before other tools, which distinguishes it from sibling profile/compare 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?

'Use FIRST whenever you have a name but need an ID' gives an explicit timing/selection rule. The description also advises on exact input phrasing (entity name only, never the full noun phrase), but it does not explicitly list when-not-to-use or name alternative tools beyond the implied 'other tools.'

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral details: probing each entity with ai_visibility_check, ranking by score, and returning a ranked list with score, confidence, and signal density. No contradictions.

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

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

The description is three sentences long, well-structured, and front-loaded. Every sentence provides unique 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 no output schema, the description explains the output format (ranked list with score, confidence, signal density per entity) and covers the tool's purpose and parameter usage. However, it does not define 'signal density' or score range, leaving minor gaps.

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

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

With 100% schema coverage, the description adds extra meaning beyond the schema, such as the first entity being treated as the 'subject' for narrative, and context being used to disambiguate common names.

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 compares AI visibility across multiple entities side-by-side, using ai_visibility_check and ranking results. It distinguishes itself from siblings by focusing on multi-entity comparison and competitive analysis.

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

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

The description explicitly mentions 'competitive AI-marketing audits' as the use case, and implies when to use it (comparing multiple entities). It does not explicitly state when not to use it, but provides clear context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral context: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30 seconds, and sources_failed will list timeouts. This provides depth 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 dense yet well-structured, front-loaded with the core composite purpose, then detailing fans-out, usage, return structure, and limitations. Every sentence adds value; no fluff.

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

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

Given the tool's complexity (composite of two services), the description fully explains what it does, what it returns (including summary block, advisories, links, alternative versions), when to use, limitations (NPM only, bundlephobia latency), and error handling (partial failures). No output schema is provided, but the description compensates with detailed 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 coverage is 100%, so baseline is 3. The description explains that version defaults to latest, but the schema already states this. No additional parameter semantics are provided beyond what the schema already captures.

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

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

The description clearly states the tool performs a composite check for npm packages covering license, advisories, version history, and bundle size. It distinguishes itself from sibling tools by specifying it's a one-call composite for npm packages, while other tools like 'deepl_research' are different. The verb 'scan dependency' is specific.

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

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

Explicitly states when to use: whenever an agent asks about safety, popularity, size of an npm package, or what adding lodash costs. Also notes that for non-NPM ecosystems, users should use deps.dev:version directly, providing clear alternatives and limitations.

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

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

Beyond annotations (readOnly, idempotent), the description discloses embedding model, similarity method, window size, character cap (200K), and truncation flag. This enriches the agent's understanding of behavior.

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

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

The description is somewhat dense but well-structured with key info front-loaded. Every sentence adds value, though a slight trim could improve conciseness without losing substance.

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

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

Despite no output schema, the description explains return format (passages with offsets and similarity scores) and mentions pairing with ask_pipeworx_grounded. Covers all critical aspects 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?

All three parameters are described in schema (100% coverage), but the description adds valuable context: max chars for 'text', example queries for 'query', and default for 'limit'. This helps the agent provide better inputs.

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

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

The description clearly states the tool performs semantic search inside a fetched record, specifying it takes text and a natural-language query and returns passages with offsets and scores. It distinguishes itself from siblings like ask_pipeworx_grounded by noting it operates on already-fetched content and pairs with that tool.

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

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

Explicitly says when to use (when record is too large for prompt) and contrasts with sibling ask_pipeworx_grounded. Provides examples of queries and mentions context savings.

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 auth requirement, persistence, delivery limits (10/day SMS), webhook auto-disable after 10 failures, one-time signing secret. 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?

Every sentence adds value; front-loaded with purpose, then types and delivery. No fluff, well-organized.

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

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

Covers all 5 types with detailed params, delivery options, auth requirements, and limits. Output schema not needed as tool returns id and webhook secret mentioned.

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

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

Adds extensive examples and constraints for each type and delivery channel beyond schema descriptions, e.g., ticker+items for sec_8k, topic for polymarket_edge, phone verification for SMS, webhook signing details.

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

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

Specific verb 'create' with clear resource 'subscription'. Distinguishes from siblings like list_subscriptions, unsubscribe, recent_alerts.

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?

States requirement for Pipeworx OAuth account, indicates when not to use (anonymous/BYO cannot persist), and suggests pull alternatives (recent_alerts, GET endpoint). Lacks explicit comparison to other tools but provides sufficient 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, idempotentHint, openWorldHint. The description adds that the tool returns example questions using the live catalog, and details the behavior with and without the topic parameter. 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 detailed but sufficiently front-loaded with trigger phrases. Each sentence adds value, though it could be slightly more concise without losing content.

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

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

Given the simple input schema (one optional param) and no output schema, the description fully explains the tool's purpose, return format, usage patterns, and positioning relative to siblings.

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

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

The description lists the possible focus areas ('finance', 'pharma', 'economics', etc.) and explains that omitting topic gives a cross-category spread. This adds meaning beyond the schema's generic description.

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

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

The description clearly states the tool returns 'category-bucketed example questions' with 'exact tool + argument shape', and explicitly distinguishes itself as the onboarding entry point. It contrasts with sibling meta-tools like ask_pipeworx, entity_profile, etc.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and provides guidance on when to omit vs pass the topic parameter. It also directs to meta-tools after using this tool.

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

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

Beyond annotations (which indicate non-destructive, idempotent behavior), the description adds that the row is deactivated, not deleted, and historical events remain available. This provides valuable behavioral context for an agent.

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 concise sentences, beginning with the core purpose, and every sentence adds essential information without redundancy.

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

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

For a simple tool with one parameter and no output schema, the description covers ownership constraints, the effect (deactivation vs deletion), and the impact on historical data, which is complete given the supporting annotations.

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

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

Schema coverage is 100% with a description for the 'id' parameter. The tool description does not add additional information about the parameter beyond what the schema provides, so it meets 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 starts with 'Cancel a subscription by id.' which is a specific verb and resource, clearly distinguishing it from siblings like 'subscribe' and 'list_subscriptions'.

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

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

The description states 'Ownership is enforced — you can only cancel your own subscriptions.' This clarifies when to use the tool (only for own subscriptions), but does not explicitly mention when not to use it or suggest alternatives, though the sibling list provides 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 readOnly, idempotent, and non-destructive. The description adds substantial behavioral context: the SEC EDGAR/XBRL fast path vs. grounded pipeline, the exact meaning of each verdict, and crucial caveats (could_not_verify is not evidence). This goes well beyond the annotations and prepares callers for edge cases.

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

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

The description is well-structured and front-loaded with trigger phrases, then purpose, routing, return values, and important caveats. It is longer than ideal but every sentence provides essential details, so it is appropriately sized for the tool's complexity.

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

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

Since there is no output schema, the description must explain return values, and it does so thoroughly: enumerates verdicts, clarifies special meanings, notes the pipeworx:// citation, and covers both claim categories. It is complete enough for an agent to invoke correctly and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3. The schema already fully describes claim and tolerance_pct. The description mentions tolerance/delta math and claim wording, but these are already in the schema descriptions, so it adds no meaningful extra parameter meaning beyond what is structured.

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: natural-language claim verification against authoritative sources. It uses specific verbs like 'verify' and 'fact check', and distinguishes itself by converting a multi-step process (NL parsing → entity resolution → data lookup → comparison) into a single call, which differentiates it from sibling tools like resolve_entity or 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: 'whenever the agent needs to check whether something a user said is factually correct.' It also provides guidance on routing company-financial claims vs. other factual claims. However, it does not explicitly name alternative tools or state when NOT to use it, so it falls short of a 5.

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