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 mark the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: it routes across 5,708 tools, fills arguments for the user, returns structured answers, provides citation URIs, and makes one fast call on every tier. No contradiction with 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 long but dense and front-loaded, leading with the most important routing guidance and then giving examples and exit conditions. A small amount of list-like domain enumeration could be tightened, but every section earns its place and supports correct tool selection.

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 broad default question-routing tool with no output schema, this is complete: it explains what the tool is, when to use it, what it returns, how it compares to relevant siblings, and even covers news/breaking-questions. An agent has enough context to invoke it correctly and know when to escalate.

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

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

Schema coverage is 100% and the schema already describes the question parameter and its aliases. The description adds meaningful context by showing the expected shape of the question: factual, about real-world entities/events/numbers, and with trigger phrases like 'what is' or 'get the latest.' The examples further reinforce what natural-language questions should look like.

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 the tool routes factual questions to the right source tool and returns structured answers with stable Pipeworx citation URIs. It is explicitly differentiated from sibling tools like ask_pipeworx_grounded and deep_research, so an agent can tell exactly what this default entry point does.

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

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

Usage guidance is unusually explicit: it says to use this tool for a broad list of data domains and trigger phrases, includes concrete example queries, and states 'START HERE for most questions.' It also names when to step up to ask_pipeworx_grounded or deep_research, giving clear alternatives and exclusion conditions.

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

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

Annotations declare readOnly, openWorld, and idempotent morals, but the description goes further by revealing the beta lifecycle: candidate routing improvements are enabled live when under test, the last candidate was retired on 2026-07-26, and it currently matches ask_pipeworx exactly. It also states 'Falls back to nothing — this IS a full working router,' preventing any mistrust about partial functionality. 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 three sentences and dense with information: purpose, current status, usage instruction, and safety reassurance. Minor redundancy exists (e.g., 'identical' and 'exactly' reiterate the match), and the retired-date detail may be beyond what most agents need, but every sentence contributes meaning.

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 an experimental router with no output schema, the description covers all essential context: what it is, what it does, when to use it, how it behaves currently, its relationship to the stable router, and its status as fully working. An agent can decide whether to invoke it and what to expect without opening additional references.

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

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

Schema coverage is 100%, so the schema already documents the `question` parameter and all five aliases with meanings. The description adds no parameter-specific detail beyond referencing 'same arguments' as ask_pipeworx, which is adequate but not enriching. 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 'Beta version of ask_pipeworx: identical universal router' and specifies the same 5,708 tools, arguments, and response shape, immediately conveying that this is an experimental but fully functional router. It clearly distinguishes itself from the stable router by naming the candidate routing improvements and its current match to ask_pipeworx.

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

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

Explicit guidance is given: 'Use it exactly like ask_pipeworx when you want the newest routing; results are compared against the stable router to decide what merges.' This tells the agent exactly when to choose this tool over the stable sibling and what the consequences are, satisfying the when/alternative requirement.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false, so the bar is lower. The description still adds substantial behavioral context: it reveals the return shape including refusal_reason enum values ('not_in_source'|'no_tool_match'|'tool_error'|'data_truncated'|'llm_error'), states that evidence is a 'verbatim quote', and discloses the extra LLM call cost. 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 dense but every sentence earns its place: purpose, mechanism, return shape, refusal behavior, use cases, cost tradeoff. The opening phrase 'Hallucination-resistant answer mode for high-stakes reads' immediately communicates the core value, and the rest is organized logically from mechanics to return format to 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?

There is no output schema, so the description correctly carries the responsibility of explaining return values — which it does in full detail, including both success and refusal shapes. The tool has only one meaningful input parameter, and the description covers prerequisites, when-to-use, cost implications, and failure modes. Nothing an agent needs to decide whether to call this tool 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 description coverage is 100% — every parameter (q, text, input, query, prompt, question) is documented as an alias for the natural-language question, and the question parameter explicitly lists all accepted aliases. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies. It does mention 'fills arguments' generically, but that is not parameter-specific.

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 purpose: 'Hallucination-resistant answer mode for high-stakes reads.' It explicitly ties itself to 'Same routing as ask_pipeworx' and explains the grounded extraction mechanic, which clearly differentiates it from the sibling ask_pipeworx (and by extension other answer tools). The resource and verb are concrete: it routes to a tool, fetches data, and extracts an answer only from the tool result.

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

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

The description gives explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' with concrete domains (financial verdicts, legal claims, medical lookups, public statements). It also provides a cost-based exclusion: 'Costs one extra LLM call vs ask_pipeworx — prefer ask_pipeworx for casual lookups.' This is a textbook when/when-not with alternative named.

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?

Annotations cover read-only/open-world/idempotent, but the description adds a wealth of non-annotation behavior: account requirement, paid tier for 'thorough', parallel decomposition across 5,708 tools, the findings packet structure (verbatim evidence, confidence, source, fetched_at, pipeworx:// citation), explicit gaps[] never-invented behavior, contradictions[] for standard/thorough, citation_uri resolvability, semantic excerpting, and 15-90s latency expectations. No contradiction with annotations.

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

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

The description is long but each sentence carries distinct operational value — auth, scope, decomposition, return packet, use-case routing, depth semantics, citation resolvability, excerpting, and latency. It is front-loaded with the critical account/alternative warning. Minor debit: it is a dense wall of text without paragraph or bullet separation, making scanning harder than necessary for such rich 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?

Despite having no output schema, the description fully compensates: it specifies the findings packet fields (evidence, confidence, source, fetched_at, citation_uri, hop, gaps[], contradictions[]), explains behavior on missing data, auth prerequisites, latency expectations, depth semantics, and alternative-tool routing. Nothing an agent needs to invoke it 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 description coverage is 100%, so baseline is 3. The description adds meaningful nuance beyond the schema: it explains the depth parameter's hop behavior (gap recovery vs. iterative lead chasing), contradictions[] availability, latency per tier, and paid restriction. It also reinforces that 'question' should be broad/multi-part. This clear added value lifts it above baseline, though not to a 5.

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

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

The description states a specific verb ('research') and a distinct resource ('Pipeworx's 1494 STRUCTURED data sources'), explicitly positioning this as multi-source structured-data research, NOT open-web search. It clearly separates this tool from siblings like ask_pipeworx by contrasting single lookups with broad/multi-part 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?

Gives explicit when-to-use and when-not-to-use guidance: 'Best for broad/multi-part questions over structured data', 'For a single lookup use ask_pipeworx', and for breaking current-news topics 'prefer ask_pipeworx'. Also handles the auth boundary by instructing unauthenticated users to use ask_pipeworx instead. Depth tier guidance ('quick', 'standard', 'thorough') is fully explained.

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?

Beyond annotations (readOnlyHint, openWorldHint, etc.), the description details the fan-out across multiple sources, specific return fields, patent sunset note, and fallback behavior. No contradiction with annotations.

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

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

The description is well-structured with examples and bullet points but is somewhat verbose. It earns its place except for minor redundancy.

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

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

Despite no output schema, the description thoroughly covers return fields (e.g., cik, recent_filings with URIs, fundamentals, patents, news, LEI), fallback behavior, and input constraints. 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?

Schema coverage is 100%, and the description adds context beyond schema: examples of ticker and CIK, explicit note that names are not supported, and that type is limited to 'company' with future plans. This fully clarifies parameter usage.

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

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

The description explicitly states the tool's purpose: 'full cross-source profile of a US public company in ONE parallel call.' It provides example queries and lists data sources, clearly distinguishing it from siblings like resolve_entity.

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

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

The description gives explicit usage guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and 'Names not supported (use resolve_entity first if you only have a name).' This clarifies when to use and when to use alternatives.

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

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

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses extensive behavior: response contents, compatibility_warning/compatibility_codes semantics, the rule that unknown legs are never paired, temporal_alignment, skipped counters, and the caveat that pre-mapped pairings are keyword-matched rather than resolution-source-verified. This is far more than annotations alone provide and gives the agent a realistic model of the tool's outputs and limitations.

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 earns most of its length because there is no output schema and the tool has complex safety fields and compatibility codes. It is front-loaded with the core purpose and modes, then dives into response details, safety fields, and caveats. Slight redundancy exists, but the density is largely justified by 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?

The description is unusually complete for a tool with no output schema: it explains the response shape, the safety indicators, the code meanings, pairing exclusions, temporal alignment, skipped comparisons, and the real-world reliability of the pre-mapped topics. There is no obvious missing behavioral or contextual information an agent would need to invoke and interpret this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining that topic is pre-mapped and auto-fetches the matching event, while kalshi_event_ticker and polymarket_event_slug override the topic-mapped side. This clarifies the relationship and precedence among parameters beyond the raw schema. It could be more concise, but it clearly adds 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?

The description opens with a specific verb and resource: "Cross-venue spread between Kalshi and Polymarket for the same resolving question." It clearly distinguishes the tool from siblings like polymarket_arbitrage by emphasizing Kalshi–Polymarket pairings and the same-question constraint. The two explicit modes (topic shortcuts vs. explicit ticker/slug) further clarify what the tool does.

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

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

The description gives clear usage context through TWO MODES and explains when to use the topic shortcuts versus explicit pairings. It also warns that "pre-mapped ≠ tradeable" and that most topics return compatibility warnings today, which is a useful when-not signal. It does not explicitly name alternative sibling tools for comparison, but the operational guidance is otherwise specific 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 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 read-only and idempotent annotations, the description adds key behavioral details: unresolved identifiers are explicitly listed under `unresolved`, GLEIF/OpenFIGI enrichment degrades gracefully if those sources are unavailable, and each identifier is source-labelled. This enriches the agent's understanding of failure modes and output format.

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

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

The description is front-loaded with example user queries, followed by a clear directive, supported types, fallback behavior, and a brief performance note. It is lengthy but every sentence serves a purpose—no fluff or repetition—and the structure aids quick scanning.

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

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

With no output schema, the description adequately covers return contents for both company (CIK, ticker, LEI with ownership, FIGI, and unresolved field) and drug (RxCUI, ingredient, brand, citation). It also covers input variants and failure modes, making the tool's behavior well-understood for an agent.

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

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

Although the schema describes both parameters, the description enriches them with concrete examples and edge cases (e.g., ISIN resolves to the legal entity via GLEIF). It clarifies the `type` options with detailed explanations of what each returns, and the `value` field with valid input formats, adding meaningful context beyond the schema.

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

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

The description clearly states the tool resolves user-spoken names to canonical/official identifiers, with specific use cases ('ticker', 'CIK', 'LEI', 'RxCUI'). It distinguishes from sibling tools by emphasizing that the output is the required input for other tools, like entity_profile or compare_entities.

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

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

Explicitly instructs 'Use FIRST whenever you have a name but need an ID.' It also notes that resolve_entity replaces 2-3 manual lookups, implying use over multi-step manual processes. Supported types and input formats further clarify when to apply 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. 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.