Launch Library

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

Annotations indicate read-only, open-world, idempotent, non-destructive. Description adds that Anthropic calls require own key and incur charges, and returns per-model details. 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 clear, front-loaded sentences covering purpose, default behavior, optional parameter, return structure, and use cases. No wasted words.

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

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

With 4 parameters and no output schema, description fully explains each parameter's role and return format (per-model score, confidence, signals, raw_response + combined view). Complete for the tool's complexity.

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

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

Schema coverage is 100%, but description adds value: explains default model, API key usage, and context parameter for disambiguation. Provides semantics beyond schema.

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

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

Description clearly states it probes LLMs for visibility on a business/product/topic and scores 0-100. It specifies default model and optional Anthropic, distinguishing from sibling tools like ask_pipeworx (general Q&A) and scan_competitor_ai_presence (likely 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?

Description lists use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It implies when to use but lacks explicit exclusions or comparisons to similar sibling tools like scan_competitor_ai_presence.

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

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

Annotations already establish read-only, open-world, idempotent, and non-destructive safety. The description adds valuable behavioral context such as auto-filling arguments, returning a structured answer with pipeworx:// citation URIs, and being a single fast call, which goes beyond the annotations and helps the agent anticipate the tool's 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 long but front-loaded with a clear directive and organized into examples, alternatives, and a 'START HERE' section. While every section adds value, some redundancy exists (e.g., 'START HERE' restates 'default entry point'), so it is not perfectly concise but still highly useful.

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

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

Given the lack of an output schema, the description discloses the return type (structured answer with citations) and covers usage scope, alternatives, and performance expectations. It also lists many example queries and domains, making it exceptionally complete for an agent to invoke the tool correctly.

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

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

The input schema fully documents the 'question' field and its five aliases with a clear natural-language description, so the schema covers 100% of parameters. The tool description provides example questions but does not add parameter-specific formatting or type details beyond what the schema already offers, earning the baseline score of 3.

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

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

The description explicitly states that the tool routes questions to 5,529 tools across 1,455 verified sources and returns structured answers with citations, which is a specific verb+resource. It also distinguishes itself from siblings like ask_pipeworx_grounded and deep_research, making the purpose unambiguous.

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

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

The description provides explicit guidance to prefer this tool over web search for a wide range of factual queries, lists trigger phrases, and names specific alternatives (ask_pipeworx_grounded, deep_research) with conditions for when to step up. It clearly frames the tool as the default entry point and explains when to escalate, leaving no ambiguity.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context beyond annotations: it's an experimental 'edge' that may have candidate routing improvements live, currently matches ask_pipeworx exactly, and is a full working router rather than a stub. This clarifies the evolving nature of the tool's 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?

Three sentences, no redundancy, front-loaded with the beta identity. Each sentence earns its place: what it is, current state/usage, and a caveat that it is fully functional. Very efficient and well-structured.

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

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

For a complex router with no output schema, the description explains purpose, current behavior, and usage. It even clarifies the response shape matches ask_pipeworx. A concrete example or more detail on how routing improvements are 'under test' could push it to 5, but it is largely 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?

Input schema coverage is 100% with descriptions for question and all aliases, so the baseline is 3. The description's phrase 'same arguments' reinforces that parameter behavior matches ask_pipeworx, but it adds no extra semantic detail beyond what the schema already provides.

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

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

The description identifies this as a beta version of ask_pipeworx, a universal router that routes questions to 5,529 tools. It distinguishes from the stable sibling ask_pipeworx by highlighting experimental candidate routing improvements, making the tool's purpose and scope unmistakable.

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

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

It explicitly instructs use when wanting the newest routing: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also names the alternative (ask_pipeworx) and explains the comparison/merge process. However, it does not provide an explicit 'when not to use' for production scenarios, 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.

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds valuable behavioral context: refusal reasons on failure, evidence field (verbatim quote), 'only what the tool result contains' constraint, and explicit refusal on non-answerable data. No contradiction with annotations.

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

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

Dense but efficient description. Front-loaded with core purpose, followed by mechanics, return types, use cases, and alternatives. Every sentence contributes meaningful information; no filler.

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

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

Fully explains both success and failure return shapes, including refusal reasons and evidence field, even without an output schema. Also covers routing behavior, source count, and cost trade-off, making the tool's behavior predictable in high-stakes contexts.

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

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

Schema description coverage is 100%, with all six parameters documented as aliases for question. The description adds no parameter-specific semantics beyond confirming the input is a natural language question, so baseline 3 applies.

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+resource: 'hallucination-resistant answer mode' for high-stakes reads, with clear mechanics (same routing as ask_pipeworx, extracts answer only from tool result). Distinguishes from sibling ask_pipeworx by emphasizing groundedness and explicit refusal behavior.

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 answer will be quoted, cited, or acted on, and the agent must not invent facts') and when not to ('prefer ask_pipeworx for casual lookups'). Also discloses the cost trade-off (extra LLM call), giving clear decision guidance.

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

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

The description goes far beyond the annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint) by detailing the fan-out process, response shapes, resolver contract, parent_event extractor, news fields, safety features (low-confidence short-circuit, closed markets), wide-spread markets, and cancellation rule parsing. This provides comprehensive understanding of the tool's 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 very verbose, covering many details in a single block of text. While it is well-organized thematically, the length might overwhelm an agent. The most critical info is front-loaded, but the high detail level could be improved with better structuring (e.g., sections). It earns a 3 for being adequate but not optimally concise.

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

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

Given the schema (3 parameters with 100% coverage) and annotations that already convey safety and idempotency, the description covers all necessary aspects: input formats, behavior, response structure, edge cases (closed markets, low confidence), and resolution rules. No gaps are evident for an AI agent to use the tool correctly.

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

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

The description adds substantial meaning to all three parameters beyond the input schema. For market, it explains acceptable formats (slug, URL, question text). For depth, it defines 'quick' vs 'thorough' with examples. For include_raw, it describes the size implications and when to set true. This fully compensates for the schema's limited 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's purpose: researching a Polymarket bet by pulling Pipeworx data. It specifies the input types (slug, URL, question text) and what it does (resolve market, classify, fan out, return evidence packet and comparison). It distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edges by focusing on single bet research.

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

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

The description provides explicit usage contexts: 'Use for should I bet on X, what does the data say about Y, or is there edge in Z.' It also covers edge cases like closed markets and low-confidence matches that block results. However, it does not explicitly contrast with sibling tools or state when not to use this tool, 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.

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

Annotations indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: single parallel call, handles off-calendar fiscal years, sorts results by primary metric, and returns citation URIs. No contradiction with annotations.

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

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

The description is a single paragraph front-loaded with common query patterns. It is dense but efficient, covering all key points without unnecessary words. Could be slightly more structured (e.g., bullet points) but is acceptable.

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, different data sources, sorting, citation URIs) and no output schema, the description covers essential behavioral details. It mentions data sources, sorting, and citation URIs. It could optionally describe the output format, but the context is sufficient for effective 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?

The input schema has 100% description coverage. The description adds meaning by detailing what each 'type' entity retrieves (company: latest 10-K data; drug: FAERS, FDA approvals, trials) and provides examples for 'values' (tickers for company, names for drug). This goes beyond the schema's simple descriptions.

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

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

The description opens with common user queries and clearly states 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call.' It specifies what each type retrieves (company: 10-K data; drug: FAERS, FDA approvals, trials). This distinguishes it from siblings like 'entity_profile' (single entity) and 'deep_research' (broader).

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

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

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and gives example queries ('which is bigger', 'rank these companies'). It does not explicitly state when NOT to use the tool, but the preference is clear. Missing a direct comparison to other comparison tools if they exist.

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

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

Even with annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds substantial behavioral context: it returns a findings packet with verbatim evidence, confidence, source, fetched_at, and pipeworx:// citations; includes gaps[] for unanswered facets; never fabricates answers; performs semantic excerpting rather than head-truncation; and details the hop behavior for standard vs. thorough depths. It also covers latency expectations (15-90s) and paid plan restrictions, which are not in 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 information-dense, with each sentence adding a distinct fact. It front-loads the account requirement and then progressively details behavior, alternatives, and depth mechanics. While it could be tightened, the complexity of the tool justifies the length and the structure is logical and scannable.

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 thoroughly explains what the tool returns: a findings packet with evidence, confidence, source, fetched_at, citation_uri, gaps[], contradictions[], and hop fields. It also covers prerequisites (account), timing, and limitations (breaking news returns gaps). For a complex 2-parameter tool, this is complete.

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

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

The description enriches both parameters beyond the schema. For 'depth' it explains the actual number of facets and hops for each enum value (quick=3, standard=5, thorough=8) and the follow-up behavior. For 'question' it notes that broad/multi-part questions are the intended use: 'decomposition is the point.' This adds meaning beyond the simple 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 precisely states the tool's function: 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources... in ONE call.' It clearly distinguishes itself from open-web search and from siblings like ask_pipeworx by naming alternatives and explaining the difference. The verb 'research' and resource (structured data sources) are explicit.

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

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

The description provides 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,' 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx,' and 'If you are not signed in, use ask_pipeworx instead.' It also mentions the account requirement and paid tier, which is critical for usage decisions.

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 idempotentHint=true, indicating safe, read-only behavior. The description adds value by detailing what the output includes (top-N tools with names, descriptions, and full schemas ready to call) and that no second schema lookup is needed. No contradictions; however, it does not mention any potential rate limits or auth requirements, which are not critical given the annotations.

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

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

The description is front-loaded with the core purpose and usage, followed by a list of domains and output details. While it is somewhat lengthy, every sentence serves a purpose. The structure is logical: purpose, usage, output, call-to-action. A minor improvement would be to condense the domain list, but it is still effective.

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

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

Given the tool's complexity (6 parameters, no enums, no output schema), the description is fully complete. It explains the tool's function, when to use it, what results to expect (tool names, descriptions, schemas), and that results are directly callable. No gaps exist for an agent to use the tool correctly.

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

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

The input schema has 100% description coverage for all 6 parameters, with aliases and examples provided. The description does not add additional meaning beyond what the schema already conveys; it merely reiterates the purpose of the 'query' parameter. Therefore, 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 uses a specific verb 'Find' with the resource 'tools'. It clearly states the tool's purpose: to discover tools based on a task description. The extensive list of examples (SEC filings, financials, FDA drugs, etc.) and the differentiation from sibling tools (none of which are about tool discovery) make the purpose unambiguous.

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

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

Explicitly advises 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' Also specifies when to use it: when you need to browse, search, look up, or discover what tools exist for the listed domains. This provides clear context and directive, distinguishing it from other tools that answer specific queries.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. Description adds rich behavioral context: parallel call, fans across multiple sources, soft-fails for patents, specific return fields. 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 thorough but somewhat verbose; however every sentence adds value. It is front-loaded with examples and clear structure, but could be slightly more concise.

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

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

Despite no output schema, description details all return components (CIK, filings, fundamentals, patents, news, LEI) and limitations (patents sunset, name restrictions). Complete for a complex holistic profile 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 adds meaning beyond schema: explains type enum (only company) and value format (ticker or zero-padded CIK), explicitly states names not supported and recommends resolve_entity.

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

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

The description clearly states the tool provides a full cross-source profile of US public companies with specific verb (profile, brief on) and resource (US public company). It distinguishes from siblings like resolve_entity by stating names are not supported.

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 provides when to use (holistic view queries like 'tell me about X') and when not to use (names only, use resolve_entity first). Advises preferring over chaining single-pack lookups.

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

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

The description's 'Delete' directly indicates destructive action, consistent with destructiveHint=true. It adds context about clearing sensitive data, which goes beyond annotations. No contradictions; idempotency is implied by the description's straightforward nature.

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 wasted words. The first sentence states the action, the second provides usage context and sibling pairing. Well-structured and front-loaded.

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

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

For a simple one-parameter destructive tool, the description is complete. It covers purpose, usage context, and relationship to siblings. No need for output schema documentation as deletion has trivial return.

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

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

Schema coverage is 100% and the schema already describes the 'key' parameter. The description mentions 'by key' but adds no additional semantic detail 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 clearly states 'Delete a previously stored memory by key,' specifying the action and resource. It also distinguishes itself from sibling tools 'remember' and 'recall' by mentioning pairing, making its role unambiguous.

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

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

Explicitly lists scenarios for use: when context is stale, task is done, or clearing sensitive data. Also advises pairing with remember and recall, providing clear guidance on when and how to use the tool relative to alternatives.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context by explaining the process (fetches page, extracts title/description/key links, emits markdown) and output format, which complements the annotations without contradiction.

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

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

The description is extremely concise: three sentences that front-load the core purpose and then provide process and use cases. No redundant or unnecessary words.

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

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

Given the tool's simplicity (2 params, no nested objects, no output schema) and rich annotations, the description covers all necessary aspects: input, process, output format, and usage scenarios. No gaps identified.

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% for both parameters, so the description adds no additional meaning beyond what the schema already provides. The default and max for max_links are already in the schema 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 generates a production-ready llms.txt file for any URL to help AI crawlers index a site. It specifies the verb (generate), the resource (llms.txt file), and the scope (any URL), making the purpose unambiguous and distinct from sibling tools.

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

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

The description lists explicit use cases: getting a client's site indexed, drafting for own project, auditing a competitor. It provides clear context but does not explicitly compare to siblings like ai_visibility_check, which would strengthen differentiation.

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 and idempotentHint. Description adds value by specifying return fields (id, type, params, etc.) and default behavior (active subscriptions). 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: first states purpose and return fields, second gives usage advice. No unnecessary words, front-loaded.

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

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

For a simple list tool with one optional parameter and no output schema, the description completely covers what the agent needs: purpose, return data, and usage context.

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

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

Schema coverage is 100% and describes include_inactive. Description does not add parameter-specific information beyond what the schema provides, so baseline applies.

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 lists active subscriptions and enumerates return fields. Differentiates from siblings implicitly by specifying 'active subscriptions' and usage context, but does not explicitly contrast with subscribe/unsubscribe.

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

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

Explicitly says to use it before adding more subscriptions or to find an id to cancel, which guides the agent on when to invoke. Lacks explicit mention of when not to use, but context with siblings implies 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 discloses several behavioral traits beyond annotations: rate limits ('Rate-limited to 5 per identifier per day'), cost ('Free; doesn't count against your tool-call quota'), read-later semantics via claim_token, and team read cadence ('The team reads digests daily'). No annotation contradictions; the false flags for readOnly/destructive are consistent with a feedback tool that writes a report but is not destructive.

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 earns its space with dense, non-redundant information. It is front-loaded with the primary purpose, and the rest is structured into use cases, exclusions, instructions, and operational details. A slight trim of some clauses could improve scannability, but no sentence is wasted.

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 there is no output schema, the description adequately covers return behavior (claim_token on first filing; status and changes on later use), operational constraints (rate limit, quota), and the exact audience (Pipeworx tools only). It covers all necessary context for an AI agent to decide whether and how to invoke 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. The description adds meaning beyond schema by explaining the claim_token lifecycle ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})') and by setting expectations for message content ('1-2 sentences typical' besides the 2000 chars max). It also clarifies that context is optional and the use case for each field.

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, actionable purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly marks this as the feedback channel for Pipeworx tools and distinguishes from other MCP servers by explicitly stating 'ONLY for tools served by this Pipeworx connection.' No direct sibling does this, so it stands apart.

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

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

Explicitly defines when to use with enumerated cases ('bug', 'feature/data_gap', 'praise') and provides a clear exclusion rule: 'if the tool came from a different MCP server... file it with that server instead.' Also gives guidance on how to describe issues ('Describe the issue in terms of Pipeworx tools/packs—don't paste the end-user's prompt') and how to follow up with a claim_token.

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

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

Goes beyond the annotations (readOnlyHint, idempotentHint) by revealing data source ('CF analytics-engine'), privacy (no PII), and caching behavior (5min-1h). 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?

Concise three-sentence description plus bullet list of use cases, front-loaded with the primary action. Every sentence is informative and no redundancy.

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

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

Despite no output schema, the description adequately explains return types (top tools, top packs, total call volume), data source, and caching. All necessary context for a simple query tool is present.

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

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

Schema has 100% coverage with one enum parameter. The description adds value by explaining trade-offs: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.'

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 verb 'returns' and the resource 'top tools, top packs, and total call volume', clearly distinguishing it from siblings like discover_tools or deep_research by focusing on trending 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?

Three explicit use cases are listed (e.g., discovering hot data sources, confirming canonical choice), but no direct comparison to alternatives or exclusion criteria are given.

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 as read-only, open-world, and idempotent. The description adds behavioral details like semantic anchor thresholds (0.30 Jaccard similarity), partition filtering of placeholder slugs, and the fill check logic, all beyond what annotations provide, with 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?

Despite length, the description is well-structured with clear sections for modes, semantic anchor, partition filter, and fill check. Front-loaded with main purpose, and every sentence adds value. Conciseness is appropriate for the complexity.

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

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

The description covers invocation, parameters, response structure (opportunities[], partition_check), and important caveats (fill risk, placeholder filtering). No output schema exists, but the description compensates by explaining key response fields, making it complete for agent 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%, but description adds rich context: examples of valid slugs, explanation of modes, behavior difference between event and topic, and acceptance of full URLs. This significantly enhances understanding beyond the schema property 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's purpose: finding arbitrage opportunities via monotonicity violations and partition-sum checks. It specifies three invocation modes (no args for trending scan, event for specific market, topic for cross-event scan), distinguishing it from sibling tools like polymarket_edges or polymarket_fill_risk.

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

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

Provides explicit when-to-use guidance for each mode: 'event (recommended for a specific market)' and 'topic (for cross-event scanning).' Also advises when not to trade (realizable_edge ≤ 0) and suggests alternative tools for custom sizing.

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

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

The description extensively details behavioral traits: model family details, edge calculations, hedging notes (slippage, 24h-move warning), and caching. It aligns with annotations (readOnlyHint, idempotentHint) and adds significant context not available in annotations alone.

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 contains many technical details. While well-structured with headings and front-loaded main purpose, it is not concise. Some details could be moved to external documentation, but overall it's adequate for an 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?

Given the tool's complexity (9 parameters, no output schema), the description covers the response structure (by_segment, diagnostics) and explains all output fields like edge_pp_net, kelly_fraction. It also explains why Fed bets are excluded, ensuring agents fully understand the 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 9 parameters have schema descriptions (100% coverage), so baseline is 3. The free-text description adds extra context, e.g., explaining slippage_pp with Polymarket's fee structure and providing usage notes for min_kelly and min_partition_leg_kelly, justifying a 4.

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

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

The description starts with a specific verb and resource: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It also provides the use case 'what should I bet on today' and differentiates from siblings by focusing on Pipeworx disagreement and model families.

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 instructions on when to use the tool and how to configure it with knobs like min_liquidity, max_spread_pp. It explains the model families and response segments, and describes caching behavior. It also notes edge cases (Fed bets excluded) and diagnostics, providing comprehensive 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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds details beyond annotations: data from daily snapshots, 60-day TTL, decaying computed from daily closes, and snapshot gaps. 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 comprehensive but verbose, covering full response structure. It front-loads the core question but could be more concise. Information-dense, but not a model of brevity.

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

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

Given no output schema, the description compensates by detailing the three response arrays (tracked, expired, snapshot_dates) and explaining each field. It also covers limitations (TTL, gaps). This provides sufficient context for an agent to understand outcomes.

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

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

Schema description coverage is 100% with clear descriptions for days (default, clamp) and window (options). The description repeats defaults and adds no new parameter semantics beyond the schema. Baseline 3 applies.

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

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

The description states a specific verb and resource: provides edge persistence and decay telemetry from daily snapshots. It answers a clear question about edge longevity, differentiating from raw edge tools like polymarket_edges. Sibling tools are distinct.

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

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

The description gives context on when to use ('a fresh wide edge...are different trades') and explains the value ('median lifespan is your competition clock'). However, it does not explicitly state when not to use or name alternatives among siblings.

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

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

Annotations indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description reinforces read-only behavior by calling it a 'check' and warns about risks (partial fills leaving unhedged positions). It adds behavioral context about the tool's analysis not being actionable without follow-up.

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 lengthy. It uses structured sections (SINGLE-MARKET, BASKET) and key requirements in ALL CAPS, which aids readability. However, some sentences are dense and could be streamlined without losing meaning. Still earns a 4 for effective organization despite verbosity.

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 details return fields for both modes (e.g., top_of_book, vwap_fill_price, theoretical_sum, realizable_sum). It covers safety warnings and prerequisites (e.g., forced_directional_risk). For a complex tool, this is complete and leaves no obvious gaps.

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

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

Schema coverage is 100% with descriptions for all 4 parameters. The description adds significant meaning beyond schema: explains size_usd interpretation for single-market vs basket, default and clamp, and side default for basket (auto from partition sum). This enriches parameter understanding.

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

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

The description clearly states the tool checks 'realizable-vs-theoretical edge against live CLOB order-book depth' and distinguishes between single-market and basket modes. It lists specific return fields like top_of_book, vwap_fill_price, slippage_pp, etc., making the purpose specific and differentiating it 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?

Explicit instructions: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It explains why (theoretical overround not capturable on thin books, partial basket fills convert arb into directional position), giving clear context for when to use this tool vs 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 (readOnlyHint, idempotentHint, etc.) already indicate safe read-only behavior. Description adds critical behavioral details: compatibility_warning cases, temporal_alignment, skipped cross type counters, and caveat that pre-mapped does not mean tradeable. 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 fairly long but each sentence adds value. Front-loads purpose and modes. Could be slightly tighter (e.g., combining some safety field descriptions), but no redundancy. Well-structured with clear sections for modes, response, and safety fields.

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

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

Despite lacking an output schema, the description thoroughly explains the response structure (venue prices, matched spreads, safety fields). Covers edge cases (compatibility_warning, temporal alignment, skipped types) and provides data quality caveats. Complete enough for an AI agent to understand behavior and limitations.

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

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

Schema coverage is 100% with good descriptions for each parameter. The description adds context by explaining the two modes and how topic/kalshi_event_ticker/polymarket_event_slug interact. Provides examples for topic values. Slightly more value than schema alone, but schema already does heavy lifting.

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 computes cross-venue spreads between Kalshi and Polymarket for the same resolving question. It differentiates from sibling tools like polymarket_arbitrage, polymarket_edges, etc. by focusing on cross-venue comparison. Includes specific verb-resource combination and details about modes.

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

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

Explicitly describes two usage modes (topic shortcuts or explicit tickers) and provides when-not-to-use guidance via compatibility_warning conditions. Warns that most pre-mapped topics return warnings and that aligned=false makes spreads meaningless. Clear alternatives are implied by naming sibling tools for single-venue analysis.

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

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

Annotations already provide read-only, idempotent, non-destructive hints. The description adds value by explaining scoping (anonymous IP, BYO key hash, account ID) and pairing with remember/forget, which enriches the behavioral context beyond structured fields.

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

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

The description is concise (three sentences), front-loaded with the main action, and every sentence provides essential information without redundancy or fluff.

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

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

For a simple tool with one optional parameter and no output schema, the description covers retrieval, listing, scoping, and sibling relationships comprehensively. No gaps identified.

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?

Input schema has 100% coverage with one optional parameter. The description adds the critical detail that omitting the key lists all saved keys, providing functional semantics beyond the schema's brief description.

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

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

The description clearly states the tool's purpose: retrieve a saved value or list all keys, with specific verb and resource. It differentiates from siblings by naming 'remember' and 'forget' and by explaining the omit-key behavior.

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 (look up stored context without re-deriving) and scoping (by identifier). While it doesn't explicitly state when not to use, the pairing with remember/forget provides implicit guidance adequate for an AI 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?

The description discloses the mark_read behavior and explains its effect on subsequent calls, but this directly contradicts the readOnlyHint=true annotation, which claims no mutation. This contradiction undermines transparency and could mislead the 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?

Description is four sentences covering purpose, fields, filters, and an alternative. It is front-loaded and efficient with 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 no output schema and 5 parameters, the description explains return fields, filter usage, mark_read effect, and an alternative endpoint. It does not cover error states or required parameters, but is largely complete for a read-only 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 coverage is 100%, so baseline is 3. The description adds clarification that 'since' uses ISO timestamps and explains the effect of mark_read, adding modest 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 pulls fired events from subscription feeds, specifies returned fields, and distinguishes from a script/dashboard alternative. However, it does not directly differentiate among sibling tools like 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 implicitly guides usage by mentioning filters and polling, and provides an alternative endpoint for scripts/dashboards. It lacks explicit when-not-to-use guidance or comparison to sibling tools.

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

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

Beyond annotations (readOnlyHint, openWorldHint, etc.), the description discloses fan-out to multiple sources, GDELT→GNews fallback, USPTO soft-fail, and response structure (changes grouped by source, citation URIs). This adds significant 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 well-structured, front-loaded with examples, and each sentence adds value. It is slightly long but efficiently conveys necessary information.

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

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

Despite no output schema, the description explains the return structure and key behaviors (fallbacks, soft-fails). It also points to the sibling tool for static profiles, making it complete for the complexity level.

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

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

Schema coverage is 100%, so baseline is 3. The description adds examples for 'since' (ISO date, relative shorthand) and clarifies 'value' (ticker or CIK), but does not provide meaning beyond what the schema already states.

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: 'change feed for a company in the last N days/weeks/months in ONE parallel call' and distinguishes it from the sibling tool 'entity_profile'. It includes example queries that illustrate typical use cases.

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

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

The description provides explicit guidance on when to use this tool versus 'entity_profile' and explains fallback behavior for news sources. However, it does not compare to other siblings like 'recent_alerts'.

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

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

Annotations indicate idempotent, non-destructive write. Description adds context about scoping and 24-hour retention for anonymous sessions, which goes beyond annotations. Could mention idempotency explicitly, but not required.

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

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

Three sentences, front-loaded with purpose, then usage, then technical scope. Clear and efficient.

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

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

For a simple 2-param tool with no output schema, the description covers purpose, usage, behavioral notes, and parameter semantics completely. References related tools.

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. Description adds context with examples and explains it's a key-value pair, reinforcing and extending schema information.

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

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

The description clearly states the verb ('save') and the resource ('data ... to reuse later'), and distinguishes itself from sibling tools by mentioning 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 states when to use ('when you discover something worth carrying forward'), provides examples, explains scoping and persistence duration, and references alternative tools (recall, forget).

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 rich behavioral context: it cascades through multiple lookup endpoints, labels identifiers with their source, explicitly shows unresolved identifiers, and degrades gracefully when external sources (GLEIF/OpenFIGI) are unavailable. This discloses internal behavior and edge-case handling that annotations alone do not convey.

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

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

The description is long but structured effectively: it opens with sample user queries, states the core purpose, then details supported types and behavioral nuances. Every sentence adds useful information, though the density could be slightly streamlined. It is front-loaded with the most critical 'Use FIRST' guidance early on.

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

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

With no output schema, the description fully covers return values: it names the identifiers returned (CIK, ticker, LEI, FIGI, RxCUI, ingredient, brand), mentions source attribution, and explains the 'unresolved' field. It also addresses failure modes (graceful degradation) and the benefit of replacing manual lookups, making the tool's behavior completely understandable.

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

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

Although the schema already describes both parameters (100% coverage), the description adds significant semantic value by specifying the accepted input formats for company (ticker, CIK, name) and drug (brand/generic), with concrete examples like 'AAPL' and 'ozempic'. It clarifies that the 'value' parameter is polymorphic, which the schema's generic description does not fully capture.

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 resolves user-spoken names to canonical/official identifiers, with specific verbs like 'resolve', 'find', and 'look up'. It lists supported entity types (company, drug) and the exact identifier source (SEC EDGAR, GLEIF, OpenFIGI, RxNorm), clearly distinguishing it from sibling tools like entity_profile or compare_entities which serve different purposes.

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 a clear usage directive: 'Use FIRST whenever you have a name but need an ID.' It also explains the coverage of entity types and the internal cascading of lookups, implying when it is appropriate. However, it does not explicitly state when not to use it or name alternatives, 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.

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

The description reveals it probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score/confidence/signal density. Annotations already cover readOnlyHint and idempotentHint, so the description adds behavioral detail beyond that, though it could mention rate limits or multiple API calls.

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 four sentences, all informative: purpose, mechanism, use case, output. No fluff, front-loaded with the main action.

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?

Without output schema, the description explains the return format (ranked list with score, confidence, signal density). It covers the mechanism and entity ordering. Lacks mention of error handling or edge cases like fewer than 2 entities, but schema constraints (2-8) are clear.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by clarifying the first entity is the 'subject' for narrative and that the tool uses ai_visibility_check, which is not in the schema. This extra context raises the score above baseline.

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

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

The description clearly states the tool compares AI visibility across multiple entities using ai_visibility_check and ranks them. It distinguishes itself from siblings like compare_entities and ai_visibility_check by specifying it performs side-by-side comparison and ranking.

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 a concrete use case ('competitive AI-marketing audits') and a sample question ('does Claude know about us as well as our competitors?'), making it clear when to use. However, it does not explicitly compare to similar siblings like compare_entities or state when not to use.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds essential behavioral details: partial failures degrade gracefully, bundlephobia first measurement can take 5-30s, and sources_failed will list timeouts. 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 slightly long but every sentence adds value. Front-loaded with the composite check purpose, then use case, ecosystem limitation, and failure behavior. Well-structured but could be tightened slightly.

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

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

Given the complexity of the tool, the description covers purpose, inputs, return value details, limitations, failure modes, and ecosystem scope. No output schema exists, but the description compensates fully. Very complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that scoped packages (e.g., '@types/node') are accepted and that version defaults to latest. This provides useful nuance beyond the schema.

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

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

The description clearly states it's a composite check for npm packages combining deps.dev and bundlephobia data. It specifies the exact use case ('is X safe / popular / small') and distinguishes from sibling tools by noting ecosystem scope (NPM only in v1).

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

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

Explicitly says 'Use whenever an agent asks ...' and provides exclusion criteria: other ecosystems fall under a different tool. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint; description adds implementation details: BGE-base-en embeddings, cosine over 500-char overlapping windows, 200K char cap with truncation flag.

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 about 5 sentences, front-loaded with main action, no wasted words, 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 description explains return format (top-N passages with offsets and similarity scores); also mentions pairing with grounded tool; complete for a search tool with good 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% (baseline 3); description adds context by specifying max chars for text, examples for query, and range for limit (1-20, default 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?

Description clearly states semantic search inside a fetched record, provides concrete examples (SEC 10-K body, article), and differentiates from sibling like ask_pipeworx_grounded.

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

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

Explicitly says to use when record is too big for prompt, mentions pairing with ask_pipeworx_grounded, and notes that passages carry offsets for verification.

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: requires OAuth, returns subscription id, delivery nuances like sms cap and verification, webhook signing secret one-time return and auto-disable. Annotations declare readOnlyHint=false, which aligns with create action.

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 separate bullet-like sections for types and delivery. Slightly verbose due to repeated delivery details in both description and param description, but front-loaded with main 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?

Covers all necessary aspects: prerequisites (OAuth), return value, type-specific configs, delivery options with constraints, and hints for verification. Complete for selecting and invoking the 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?

Adds significant meaning beyond schema: detailed examples for each type of 'type' parameter, specific shapes for 'params' per type, and rich behavior for 'delivery' including email/sms/webhook specifics. Schema coverage is 100%, but description provides indispensable usage guidance.

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

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

Clearly states the verb 'Create' and resource 'subscription to a live-data event stream'. Distinguishes from sibling tools like 'list_subscriptions' and 'unsubscribe' by focusing on creation.

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?

Specifies when to use: requires Pipeworx OAuth account, lists supported types and delivery channels. Implicitly excludes anonymous users. Does not explicitly mention alternatives, but siblings provide that 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?

The description adds significant detail beyond annotations (readOnlyHint, openWorldHint, etc.) by explaining that the tool returns category-bucketed example questions with exact tool and argument shapes. 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 moderately concise, packing purpose, usage, and output format into one paragraph. It is front-loaded with the key purpose and queries, though slightly lengthy.

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

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

Given no output schema, the description fully explains the return format (category-bucketed example questions with tool shapes). With one optional parameter, it is complete and serves its purpose well.

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

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

Schema covers 100% of parameters with a clear description. The description adds context that omitting topic gives a full spread and provides examples of valid topics. This goes beyond the schema's enum-like list.

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 an onboarding entry point for suggesting what to ask Pipeworx. It lists related queries ("what can I ask?") and distinguishes from other tools like ask_pipeworx by being about suggestions and examples.

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

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

The description explicitly says to use this tool FIRST when you do not yet know what Pipeworx can do, or to learn how to call meta-tools. It provides a clear usage context but does not explicitly state when not to use it, though the purpose implies 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?

Adds clarification beyond annotations by describing deactivation (not deletion) and ownership enforcement, aligning with non-destructive hint.

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

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

Two sentences, front-loaded with essential info, no wasted words.

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

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

Fully covers behavior, ownership, side effects, and return expectations for a simple one-param tool with 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 description of id param; tool description adds no additional semantic value for the parameter beyond what schema already provides.

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

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

Clear verb 'Cancel' and resource 'subscription', distinguishes 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?

Explicit ownership constraint and explanation of deactivation behavior, providing when-to-use context; lacks explicit when-not-to-use but sufficient.

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

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

The description goes beyond annotations by explaining two distinct processing paths (SEC EDGAR/XBRL vs. grounded pipeline), the exact verdicts returned, and the crucial distinction between 'could_not_verify' (check did not happen) and 'unsupported' (no source found). This adds essential behavioral context, especially the warning not to treat 'could_not_verify' as evidence.

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 highly information-dense. It is front-loaded with trigger phrases and purpose, then proceeds to behavior, return values, and special cases. Each sentence earns its place, though it could be tightened slightly without losing 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?

There is no output schema, so the description carries the burden of explaining return values. It lists the six possible verdicts, mentions the grounded/structured value with citation, and clarifies important edge cases (could_not_verify, unsupported). This is complete for a tool of this complexity, especially with the annotations already covering safety.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema for 'claim' and 'tolerance_pct'; the schema already explains overrides and hallucination detection. The description's mention of 'exact percent-delta math' is a minor addition, so the score remains at 3.

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

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

The description clearly states the tool's purpose: 'natural-language claim verification against authoritative sources.' It includes trigger phrases, specifies the resource ('authoritative sources'), and distinguishes itself from siblings by noting it 'replaces 4–6 sequential calls.' This is a specific verb+resource combination that sets it apart from other tools.

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

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

The description provides explicit guidance: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the routing for company-financial vs. other claims, giving clear context. However, it does not explicitly list alternatives or when not to use the tool, so it misses the 'exclusions' part for a 5.

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