Crypto Fng

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

Annotations already indicate read-only, idempotent, open-world, non-destructive. The description adds concrete behavioral context: cost implications (free vs. BYO key for Anthropic), default model, and return structure. 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 three sentences, each dense with information. It front-loads the core action and output, then adds parameter details 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?

Despite no output schema, the description adequately explains return values (per-model score, confidence, signals, raw_response + combined view). Parameter count is 4 with one required, and all are explained. The tool's purpose and output are clear enough for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the description is not strictly required for parameters. However, it adds meaningful context: default model is Workers AI Llama-3.3-70b (free), _apiKey is needed only for Anthropic, and context helps disambiguate. This adds 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 probes LLMs for entity knowledge and scores visibility (0-100). It uses specific verbs (probe, score) and resource (LLMs, visibility). It distinguishes itself from sibling tools like ask_pipeworx or scan_competitor_ai_presence by focusing on visibility scoring, not Q&A or scanning.

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 use cases (AI-marketing audits, pre-launch brand checks, competitive monitoring) but does not explicitly state when not to use it or name alternatives. Given the sibling list, some tools like scan_competitor_ai_presence may overlap, but no exclusion guidance is provided.

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

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

Annotations already indicate readOnly/openWorld/idempotent/non-destructive, and the description adds valuable behavioral context beyond this: it reveals internal routing ('Routes the question to the right one of 5,562 tools'), argument filling, and the return format ('structured answer with stable pipeworx:// citation URIs'). This is significant extra transparency without contradicting 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 lengthy but every sentence carries operational value. It front-loads the key directive ('PREFER OVER WEB SEARCH'), then logically flows through purpose, examples, default status, and escalation paths. No redundant or filler content.

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

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

For a complex routing tool with heavy annotation coverage, this description is remarkably complete: it covers scope (data domains), behavior (routing, citation URIs), usage patterns (question phrasing), and escape hatches (grounded, deep_research). No output schema exists, but the description explicitly promises a structured answer with citations, so return format is sufficiently explained.

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

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

Schema description coverage is 100% and the parameter description is already clear ('Your question or request in natural language. Accepts query, q, prompt, text, input as aliases.'). The tool description adds meaning with multiple example questions ('current US unemployment rate', 'Apple's latest 10-K') that illustrate the expected semantic range, which goes beyond the schema's generic phrasing.

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 a specific verb ('Routes the question') and resource ('one of 5,562 tools across 1462 verified sources'), with explicit output ('returns the structured answer with stable pipeworx:// citation URIs'). It also differentiates from siblings by saying 'START HERE' and comparing to ask_pipeworx_grounded and deep_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 when-to-use guidance: 'PREFER OVER WEB SEARCH' and 'Use whenever the user asks...' with concrete question types and examples. It also states exclusions and alternatives: 'Step up only when needed: for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research'. Even handles breaking-news guidance.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context: beta status, live candidate routing improvements, current state (no active candidate), and that it is a full working router with no fallback. This extra detail about experimental behavior and current parity with the stable version goes beyond annotations without contradicting them.

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

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

Four sentences of moderate length. It front-loads purpose, then explains the beta nature, current status, and usage. Specific details like '5,562 tools' and the date add context but might be slightly verbose. Overall, every sentence contributes meaning, though it could be tighter.

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 6-param router with no output schema, the description is complete. It explains the relationship to the stable sibling, the experimental nature, current status, and confirms it is fully functional. No output schema exists, so return-value details are not required. The description sufficiently covers the tool's role and edge behavior.

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

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

Schema description coverage is 100%, with all parameters documented as aliases for 'question'. The description only states 'same arguments' and does not add new meaning beyond the schema. Baseline 3 is appropriate since the schema handles parameter semantics fully.

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

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

The description clearly states this is a beta version of ask_pipeworx, a universal router that accepts a question and routes to 5,562 tools. It explicitly distinguishes itself from the stable ask_pipeworx by highlighting its experimental nature and candidate routing improvements, making its 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?

It provides clear guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also explains the comparison context with the stable router. It does not explicitly state when NOT to use it (e.g., for stable/production needs), but the beta designation implies this. The guidance is clear and practical but lacks explicit exclusions.

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

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

Annotations already cover readOnly/openWorld/idempotent, but the description adds critical behavioral context: returns verbatim evidence quote, explicit refusal reasons on failure, and discloses the extra LLM call cost. No contradictions with annotations.

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

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

The description is packed with essential information—purpose, routing, output format, refusal reasons, use cases, and cost—without any redundant sentences. Front-loads the core value proposition and progresses logically.

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

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

No output schema exists, but the description thoroughly explains both success and failure return structures. Covers multi-step behavior, error handling, and cost trade-offs, fully equipping an agent to decide and invoke correctly.

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

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

Schema coverage is 100% with all six parameters being aliases for the same question field. The description does not add parameter-level information, but the schema already fully documents each alias, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose as a 'Hallucination-resistant answer mode for high-stakes reads' and distinguishes it from ask_pipeworx by emphasizing extraction using only tool result content. It also specifies the exact routing behavior and output structure.

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 this tool: 'whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts.' Also gives an exclusion: 'prefer ask_pipeworx for casual lookups' due to extra cost.

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

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

The annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds extensive behavioral details: market resolution, classifier fan-out, resolver contract with confidence levels, parent event extraction, news fallback mechanisms, safety cutoffs for low-confidence/closed/illiquid markets, and resolution-rule risk. This far exceeds what annotations provide.

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 verbose, containing multiple paragraphs with classifiers, examples, response shapes, and resolver contract details. While comprehensive, it lacks conciseness and could be better structured with bullet points or sections to improve readability.

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, lack of output schema, and only 3 parameters, the description is highly complete. It covers response shapes, resolver confidence, parent events, news fields, safety behaviors, and resolution rules. It provides everything an agent needs to understand the tool's 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%, so the schema already documents all three parameters. The description provides examples and context for the 'market' parameter but does not explain 'depth' or 'include_raw' beyond what is in the schema. The additional examples are helpful but do not significantly enhance 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's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the action (research), resource (Polymarket bet), and input formats (slug, URL, question). It distinguishes from sibling tools like ask_pipeworx by focusing on Polymarket-specific betting analysis.

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

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

The description provides clear usage scenarios: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It also gives numerous examples of bets and fan-outs. However, it does not explicitly state when not to use or list alternative tools, which prevents a score of 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?

Describes data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), proper fiscal year handling, sorting by primary metric, and return format (paired data + citation URIs). This adds substantial context beyond the readOnlyHint and idempotentHint 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 user query examples and is informative. While it is slightly long, every sentence adds value, and the structure is clear.

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

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

Given no output schema, the description adequately explains return format and sorting. It covers both entity types and behavioral nuances. It is fairly complete for a tool of moderate complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by specifying that 'values' for companies are tickers/CIKs and for drugs are names, and explains what data each type pulls. This provides insight beyond the schema descriptions.

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

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

The description clearly states it performs side-by-side comparison of 2–5 entities (companies or drugs) in a single parallel call. It provides specific examples like 'compare X and Y' and distinguishes itself from sequential lookups.

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

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

Explicitly tells when to use: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It includes example queries and explains that it replaces 8–15 sequential lookups, giving clear guidance on when this tool is optimal.

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, openWorldHint, idempotentHint) already declare safe, idempotent reads. The description adds that it returns the current value, classification, date, and seconds until next update, providing behavioral context beyond annotations. No contradictions.

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

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

Two sentences deliver the core purpose and return details without extraneous text. Every sentence adds value, and information is front-loaded.

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

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

For a parameterless tool with no output schema, the description sufficiently explains what is returned and when to use it. It could mention the data source or update frequency, but it is adequate for an agent to invoke correctly.

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

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

The tool has zero parameters, so the description does not need to explain parameter semantics. Baseline score of 4 applies, as the description adds no extra parameter information beyond the schema (which is fully covered).

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

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

The description clearly states the tool retrieves the Crypto Fear & Greed Index, explains the 0-100 scale, and lists returned fields. It is distinct from sibling tools which focus on other topics (e.g., AI visibility, political predictions).

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 tool is for getting a daily market sentiment gauge without parameters, making usage straightforward. The description mentions 'Keyless' but does not explicitly state when to use it over alternatives or provide exclusion criteria. However, given its simplicity, this is acceptable.

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 readOnly/ idempotent/ non-destructive, and the description goes beyond them substantially: it explains the parallel decomposition across 5,562 tools, the gaps[] behavior ('never invented'), citation_uri fetchability guarantee, hop fields, contradiction[] scans, semantic excerpting (not head-truncation), expected latency (15-60s/up to 90s), and the free/paid account requirement. This is a rich behavioral contract with no contradiction to 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 every sentence earns its place—it covers auth requirements, usage boundaries, behavioral mechanics, depth semantics, return fields, citation guarantees, and latency. It is front-loaded with the account callout and critical differentiation from ask_pipeworx, and uses parentheticals and concise phrasing (e.g., 'never invented', 'not head-truncated'). It is somewhat dense for quick scanning, so not a 5, but it is efficiently packed for such a complex tool.

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

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

Given the tool's complexity (2 params, rich enum semantics, 5,562 underlying tools, multi-hop behavior, no output schema), the description is thoroughly complete: it explains the return packet, gaps/contradictions, citations, hop field, exception cases (structured catalog miss), latency, auth tiers, and when to prefer siblings. With no output schema, the description fully carries the burden of explaining outputs, and it does so comprehensively.

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

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

Schema coverage is 100% so the baseline is 3; the description adds meaning beyond the schema by explaining what 'quick', 'standard', and 'thorough' actually do (facet counts, gap-recovery hop, contradiction scan, paid requirement for thorough) and clarifying that the question parameter can be broad/multi-part because decomposition is intrinsic. Minor deduction for not restating edge cases like exact formatting of the question, but the added semantic depth is clearly 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 states a specific verb ('research') and resource ('Pipeworx's 1462 STRUCTURED data sources'), and clearly distinguishes itself from open-web search and the sibling ask_pipeworx tool ('this is NOT open-web search', 'For a single lookup use ask_pipeworx'). It explains the decomposition/parallel-routing capability and mentions what it returns, making the tool's unique role 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 gives explicit when-to-use guidance ('Best for broad/multi-part questions over structured data'), explicit exclusions ('For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'), and even names the alternative tool. It also describes when depth variants are appropriate, making selection criteria very clear.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral details beyond annotations: explains the return value includes full schemas and is ready to call directly. No contradiction.

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

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

Description is front-loaded with purpose, then lists domains, then explains return value and usage. Every sentence adds value, but it is slightly verbose. Could be more concise without losing clarity.

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

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

No output schema, so the description takes on burden of explaining return value. It does so by stating 'top-N most relevant tools with names, descriptions, and full input schemas' and 'ready to call directly'. Complete for a discovery 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 description coverage is 100%, so baseline is 3. The description mentions aliases but the schema already describes each alias. No significant new semantic meaning beyond the schema.

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

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

The description clearly states 'Find tools by describing the data or task' with specific verbs and resource. It lists many domains and distinguishes from sibling tools by being the discovery/gateway tool. No ambiguity.

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

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

Explicitly says 'Call this FIRST when you have many tools available and want to see the option set' and 'Use when you need to browse, search, look up, or discover what tools exist for: ...'. Provides clear context and when-not-to-use implied.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavioral context: parallel fan-out across sources, USPTO API sunset with soft-fail, GDELT→GNews fallback, and specific return fields. No contradiction with annotations.

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

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

The description is detailed and well-structured, but slightly verbose. It front-loads typical user queries and the action, then enumerates sources and outputs. Each sentence adds value, though some tightening is possible.

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 (multi-source, fallbacks, future changes) and absence of an output schema, the description comprehensively covers what the tool returns (cik, filings with URIs, fundamentals sorted, patents status, news fallback, LEI).

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 2 parameters with 100% description coverage. The description adds meaning beyond schema: clarifies 'value' accepts ticker or CIK (not names), mentions future 'type' values, and explains the format of CIK (zero-padded).

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: fetching a full cross-source profile of a US public company. It enumerates specific data sources (SEC EDGAR, XBRL, USPTO, news, GLEIF) and return fields, distinguishing it from siblings like 'resolve_entity' and 'compare_entities'.

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

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

Explicit guidance is provided: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also specifies when not to use (only names, not ticker/CIK) and directs to 'resolve_entity' first.

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

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

Annotations already cover destructiveHint and idempotentHint. Description adds context about clearing sensitive data, complementing annotations.

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

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

Two sentences, no waste. All information is relevant 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?

Simple tool with one parameter and no output schema. Purpose, usage, and complementary tools are fully covered.

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 provides full coverage (100%) for the single 'key' parameter. Description adds no extra details beyond 'by key'.

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 'Delete a previously stored memory by key', specifying action and resource. Differentiates from sibling tools 'remember' and 'recall'.

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

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

Explicitly lists when to use: stale context, task done, clear sensitive data. Plus recommends pairing with 'remember' and 'recall'.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by explaining the process: fetches the page, extracts title/description/links, and emits standard llms.txt markdown. This goes beyond annotations, though it omits potential error states or rate limits.

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

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

Three concise sentences: purpose, process, and use cases. No extraneous information, well front-loaded with the core action. Every sentence is informative and earns its place.

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

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

With 2 parameters fully described in schema, clear annotations, and a detailed description explaining the tool's function and output format, the description provides complete guidance for an agent to invoke this tool correctly. No output schema is needed because the description states the output is a single text blob.

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

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

The schema descriptions for both 'url' and 'max_links' are present (100% coverage). The description adds context by stating 'Full URL of the site to summarize' and providing default (25) and max (50) for max_links, which enhances the base 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 generates a production-ready llms.txt file for any URL for AI crawlers. It specifies the output format and lists explicit use cases, making the purpose highly specific and distinguishable from sibling tools like scan_competitor_ai_presence.

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 includes 'Useful for' with three concrete scenarios (client site indexing, own project, competitor auditing), providing clear context on when to use the tool. However, it does not mention when not to use it or directly contrast with 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 already declare readOnlyHint and idempotentHint, which cover safety. The description adds that results are sorted most recent first and includes summary stats, but this is minimal extra context beyond the annotations.

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

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

The description is extremely concise with three short sentences, no redundancy, and front-loads the core purpose.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description covers output structure and behavior. Missing default limit value (though schema mentions default 30) is minor.

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% coverage for the single 'limit' parameter, so the description adds no additional parameter meaning beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool retrieves historical Crypto Fear & Greed Index values with summary statistics. The purpose is specific and actionable, but it does not differentiate from the sibling 'current_index' tool.

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

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

No guidance is provided on when to use this tool versus alternatives like 'current_index'. The description lacks explicit context for usage scenarios or exclusions.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint false. Description adds return fields and usage context, enhancing transparency without contradicting annotations.

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

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

Two succinct sentences: first states action and return fields, second gives usage guidance. No unnecessary words, front-loaded with key information.

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

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

For a simple tool with one optional parameter and no output schema, description provides essential return fields and usage context. Annotations cover safety. 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 covers 100% of parameters with a clear description for 'include_inactive'. Description does not add further parameter info, which is acceptable given schema coverage.

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

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

Description clearly states the verb 'list' and resource 'subscriptions', specifying it returns caller's active subscriptions. It distinguishes from siblings like subscribe and unsubscribe by indicating it provides an overview for review.

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 suggests when to use: 'to review what you're monitoring before adding more or to find an id to cancel.' Provides clear context for usage, though it doesn't explicitly 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 are all false, providing little signal, so the description carries the burden. It adds rate limiting (5 per identifier/day), free/no quota, claim_token return behavior, and roadmap signal, going well beyond structured metadata.

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 and information-dense; each sentence adds scope, alternatives, or behavioral detail. It is appropriately structured, though it slightly repeats schema content for claim_token.

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 4 optional params and no output schema, the description sufficiently explains return-ish behavior via claim_token, rate limits, and scope. It fully equips an agent to decide whether and how to invoke.

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 covers all parameters at 100%, so baseline is 3. The description adds some guidance on framing feedback in terms of Pipeworx tools/packs, but most parameter details (message length, claim_token usage) already appear in the schema.

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

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

The description opens with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' This clearly distinguishes it from sibling tools like ask_pipeworx or discover_tools by framing it as feedback rather than query/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?

It explicitly enumerates when to use: for wrong/stale data (bug), missing tool (feature/data_gap), or praise. It also specifies exclusions—only tools served by this Pipeworx connection, not other MCP servers—and tells users to file elsewhere.

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 a safe read operation (readOnlyHint, idempotentHint). The description adds valuable context: derived from CF analytics-engine, no PII, cached 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?

The description is a single concise paragraph with no wasted words. It front-loads the core functionality, then lists use cases, then technical details. Every sentence earns its place.

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

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

Given the simple input schema (one optional parameter) and annotations covering safety, the description is complete. It explains the output (top tools, packs, volume), window options, use cases, caching, and privacy. No output schema needed.

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

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

Schema coverage is 100% with a description for the 'window' parameter. The description adds nuance about short vs long windows, but does not add significant new info beyond the schema enum values. Baseline 3 plus 1 for added context.

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

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

The description clearly states it returns 'top tools, top packs, and total call volume' over a specific window. It uses a specific verb ('returns') and resource ('trending data on Pipeworx'), and distinguishes itself from siblings by focusing on aggregated trending signal.

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 enumerated: discovering hot sources, confirming canonical tools, and aligning use case. It also explains the difference between short and long windows. No alternative siblings are listed, but the tool appears unique.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds extensive context: internal checks (Jaccard similarity, placeholder filtering, fill check), response structure, and trade/no-trade signals. 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?

Well-structured with front-loaded key info and mode breakdowns. Every sentence adds value, though slightly verbose. Could be marginally tightened without loss.

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 covers response fields (opportunities, partition_check, fill check) and trade decisions. For a complex tool, it's comprehensive but could include expected data volume or timeouts.

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 richer semantics: for event, specifies it accepts slugs or URLs and is single-event mode; for topic, explains cross-event scanning and search behavior.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket, specifies the methods (monotonicity violations + partition-sum checks), and distinguishes the three modes (no args, event, topic) with specific 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?

Explicit guidance on when to use each mode: 'Call with NO args for a trending_scan... pass event for the strongest per-event partition_check, or topic for a themed cross-event scan.' Recommends event mode for specific markets and advises against trading when realizable_edge_pp ≤ 0. References sibling tool polymarket_fill_risk for custom sizing.

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

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

The description extensively details the three model families, response segments, diagnostics for empty segments, caching behavior (1h at KV level), and how tradeable-edge knobs affect results. This adds significant value beyond the readOnlyHint annotation.

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

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

The description is long but well-structured with clear section headers for model families and knobs. It is slightly verbose but every part adds unique value, making it efficient for agent consumption.

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, multiple segments), the description fully covers response structure, edge cases, diagnostics, and caching. It is self-contained and leaves no critical 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?

Although schema coverage is 100%, the description enriches each parameter with practical context, usage suggestions, and edge cases (e.g., min_kelly skips too-small bets, min_partition_leg_kelly explains its role for partition arbs). This helps the agent understand when and how to set each parameter.

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

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

The description clearly states it scans Polymarket markets for opportunities where Pipeworx data disagrees with market price, targeted at 'what should I bet on today.' It distinguishes itself from siblings like polymarket_arbitrage and polymarket_edge_tracker by focusing on a broad scan returning multiple opportunity segments.

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 mentions it's for discovering opportunities without paging through hundreds of markets, and explicitly excludes Fed bets from ranking with a rationale. However, it does not provide explicit comparisons to sibling tools or state when not to use this tool.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description goes beyond by explaining snapshot TTL (60 days), daily close-based decay, and the meaning of trend and decay fields, giving full 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 informative and well-structured, starting with purpose, then parameters, response format, and limitations. It is fairly lengthy but every sentence adds value.

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

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

Despite lacking an output schema, the description fully explains the response structure (tracked, expired, snapshot_dates) with field meanings. Combined with rich annotations and clear parameters, it is complete.

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

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

Schema covers 100% with descriptions. The description adds default values and constraints (e.g., 'default 14, max 30' for days) and explains the meaning of 'window' as snapshot family, complementing the schema.

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

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

The description clearly states the tool's purpose: tracking edge persistence and decay over time. It distinguishes itself from the sibling 'polymarket_edges' by focusing on temporal analysis (history and decay) rather than just current edges.

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

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

Provides implied usage context by contrasting a 'fresh wide edge' against a '3-week-old wide edge' to indicate when historical context matters. However, it does not explicitly state when to use alternatives.

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

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

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description reinforces this by detailing the operation (walking the order book, returning fill quality metrics, verdict). It adds critical context about forced directional risk and the meaning of results like 'thin_legs' and 'max_clean_notional_usd', exceeding what annotations provide.

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 efficiently packed with necessary detail for a complex tool with two modes. It uses capitalization for emphasis and clear sectioning (SINGLE-MARKET vs BASKET). While every sentence earns its place, the length could be slightly trimmed without losing critical information, but it remains 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 (two modes, no output schema), the description is thorough: it explains all input parameters, default values, return fields (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict, etc.), and edge cases (thin books, partial fills, forced directional risk). No output schema exists, so the description fully compensates.

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

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

Schema description coverage is 100%, but the description adds substantial meaning: it explains the 'side' parameter's default auto behavior for baskets, 'size_usd' as settlement notional per leg, and the exact meaning of each parameter in both modes. This goes well beyond the schema descriptions.

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

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

The description clearly states the tool performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes two modes (single-market and basket) with explicit outputs and purpose. It also differentiates from siblings like polymarket_arbitrage and polymarket_edges by instructing when to use this tool before acting on those signals.

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

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

The description provides explicit guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It explains the risk of partial basket fills converting arb to directional positions and delineates between single-market and basket modes with required parameters.

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

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

Annotations already declare the tool as read-only, open-world, and idempotent. The description adds extensive behavioral details: compatibility warnings for non-equivalent bet shapes, temporal alignment checks, skipped cross types, and realistic expectations about spread availability. This far exceeds the information in 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 comprehensive but somewhat verbose, with multiple sentences and technical details. It is well-structured with sections for modes, response format, and safety fields, but could be more concise by reducing redundancy (e.g., topic list in both schema and description).

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

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

Given the absence of an output schema, the description fully explains the response structure including leg-by-leg prices, top_spreads_pp, compatibility_warning, temporal_alignment, and skipped categories. It covers edge cases and provides sufficient context for an agent to understand the tool's 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 descriptions for all three parameters. The description adds behavior context: the topic parameter auto-fetches events, while explicit parameters override the mapped ones. This clarifies parameter interaction beyond the schema's individual 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: computing cross-venue spreads between Kalshi and Polymarket for the same resolving question. It distinguishes two modes (topic shortcuts and explicit pairings) and explains the output, differentiating itself from sibling tools like polymarket_arbitrage that focus on single-venue spreads.

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 each mode (pre-mapped shortcuts vs custom pairings) and warns that most pre-mapped topics may not be tradeable, managing expectations. However, it does not explicitly contrast with sibling tools, leaving some ambiguity about when to use this tool over others like polymarket_arbitrage.

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

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

Adds value beyond annotations (readOnlyHint, etc.) by explaining scoping to identifier and pairing with other tools. 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?

Two tightly written sentences with no wasted words. Front-loaded with core action. Every sentence adds value.

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

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

For a simple tool with one optional parameter and no output schema, the description fully explains behavior, scoping, and relationship to siblings. Complete and self-contained.

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 for the single parameter. Description adds a brief context but no additional semantics beyond the schema's description.

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

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

The description clearly states the two actions: retrieve a value saved via remember, or list all keys when key is omitted. Uses specific verbs (retrieve, list) and distinguishes from sibling tools (remember, 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?

Describes use case (look up stored context) and pairing with remember/forget, but does not explicitly state when not to use or mention specific alternatives beyond sibling list.

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 readOnly, idempotent, non-destructive. Description adds mark_read behavior and polling note, no contradictions. Could mention rate limits or auth but schema coverage is high.

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

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

Two sentences, no redundancy, purpose front-loaded, every sentence adds value.

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

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

Covers purpose, return fields, filtering options, behavior of mark_read, and alternative access method. No gaps given read-only nature and high schema coverage.

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 5 parameters described in schema. Description adds example filter 'sec_8k', explains mark_read effect, and shows use of since field. Adds value 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 pulls fired events from subscription feed, specifying returned fields (source, citation_uri, raw payload). Distinguishes from siblings like list_subscriptions by focusing on reading recent alerts.

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

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

Provides context on polling suitability and notes alternative GET endpoint. Lacks explicit comparison to siblings but gives sufficient guidance on when to use (retrieve 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 already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context on multi-source fan-out, fallback behavior (GDELT→GNews), soft-fail for USPTO, and return format. However, the core safety traits are covered by 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 efficient given the tool's complexity, beginning with example queries. Every sentence adds value (sources, fallback, return format, sibling differentiation). Could be slightly trimmed but is 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?

Covers return structure (changes grouped by source, total count, citation URIs), failure behaviors (patents soft-fail), and data sources. Since there is no output schema, the description fully compensates, making it complete for a complex multi-source tool.

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

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

Schema coverage is 100% but the description adds crucial meaning: explains relative date shorthand with examples, recommends window sizes, and clarifies that 'value' can be ticker or CIK. This significantly aids agent usage.

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

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

The description clearly states it provides a change feed for a company from multiple sources (SEC, GDELT/GNews, USPTO) and explicitly distinguishes from sibling tool 'entity_profile' which is for static profiles.

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 examples ('what's new', 'latest on Y', 'updates on Acme') and directly contrasts with entity_profile for static profiles. Also gives guidance on using '30d' or '1m' for typical monitoring.

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

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

Discloses behavioral traits beyond annotations: persistence duration ('24 hours for anonymous'), session scoping ('by your identifier'), and that it's a write operation (matching destructiveHint=false). Annotations already provide idempotentHint=true and destructiveHint=false, so description adds useful context 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?

Concise and well-structured: front-loaded with purpose, followed by usage guidelines, behavioral details, and pairing instructions. Every sentence earns its place without superfluous text.

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-parameter tool with no output schema, the description fully covers purpose, when to use, behavioral traits, parameter semantics, and integration with sibling tools. No gaps remain for the agent to infer.

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 key and value. The description adds examples and clarifies the purpose of each parameter (e.g., 'Memory key (e.g., ...)' and 'Value to store (any text...)'), enhancing the schema's semantics.

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: 'Save data the agent will need to reuse later'. It specifies the resource (key-value pairs) and distinguishes from sibling tools like recall and forget by explaining the storage mechanism and pairing instructions.

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

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

Provides explicit when-to-use guidance: 'Use when you discover something worth carrying forward' with concrete examples. Implicitly says when not to use by pairing with recall/forget for retrieval/deletion, but no explicit exclusions. Lacks direct alternative tool references beyond sibling mentions.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description reveals key behaviors: it aggregates identifiers from multiple sources (SEC, GLEIF, OpenFIGI, RxNorm), gracefully degrades if an external source is unavailable, explicitly lists unresolved identifiers under `unresolved` rather than omitting them, and emits a citation URL for drugs. It also explains the internal cascade of lookups, providing deep insight into execution.

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

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

The description is lengthy but every sentence adds value: examples, supported types, source details, and fallback behavior. It is well organized with a clear opening, labeled 'SUPPORTED TYPES', and a closing note about efficiency. Slightly verbose for a tool description, but no fluff; earns a 4 rather than a 5.

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 covers return values and behavior: it lists the exact identifiers returned for each type, explains the source of each (SEC, GLEIF, OpenFIGI, RxNorm), describes error/unresolved handling, and notes graceful degradation. This is a complete picture for an AI agent to invoke the tool and interpret results.

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

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

The schema already defines both parameters with enums and examples, but the description adds substantial meaning: for `type='company'` it details that ticker, CIK, ISIN, or name are accepted and that ISIN resolves via GLEIF to the legal entity; for `type='drug'` it clarifies brand or generic names map to RxCUI and RxNorm concepts. It also explains what each type returns (CIK, LEI, FIGI, RxCUI), far exceeding the schema's minimal 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 opens with concrete natural-language examples ("What's the ticker for…", "find the CIK for…") and immediately states the core function: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' This clearly distinguishes it from siblings like entity_profile or compare_entities by emphasizing identifier resolution as a prerequisite step.

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

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

Explicit guidance is given: 'Use FIRST whenever you have a name but need an ID.' The description also explains what input types each supported type accepts (ticker, CIK, ISIN, name for company; brand or generic for drug), and notes that it replaces 2-3 manual lookups, setting expectations for when to invoke this tool.

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

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

Annotations declare read-only, open-world, idempotent, non-destructive. Description adds valuable behavioral details: probes each entity with ai_visibility_check, returns ranked list with score, confidence, signal density. No contradictions.

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

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

Two sentences: first defines the core action, second provides use case and output format. No wasted words, front-loaded with key information.

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

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

For a tool with no output schema, the description adequately explains return values (ranked list with score, confidence, signal density). All 4 parameters are covered by schema descriptions. Sufficient for agent to decide and invoke correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description mentions entities and context but does not add significant meaning beyond the schema's parameter descriptions. Models and _apiKey are not elaborated further.

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 (compare/probe/rank/surface) and resource (AI visibility across multiple entities). It distinguishes from sibling ai_visibility_check by emphasizing 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?

Provides a concrete use case ('competitive AI-marketing audits') and example question. Does not explicitly state when not to use or list alternatives, but the context implies it is for multi-entity comparison versus single-entity check.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds significant behavioral context: partial failure handling, bundlephobia measurement delay (5-30s), and sources_failed reporting. 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 thorough and front-loaded with purpose and usage. It is slightly dense but each sentence adds value. Minor trimming could improve readability, but overall efficient.

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

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

Despite lacking an output schema, the description fully explains the return structure (summary block fields, advisory details, links, alternative versions) and handles complexities like partial failures and timeouts, making it complete 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?

Schema coverage is 100% with descriptions for both parameters. The description adds practical usage details: acceptance of scoped packages and defaulting version to latest, enhancing understanding beyond the schema.

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

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

The description clearly defines the tool as a composite check for npm packages, covering license, advisories, version history, bundle size, dependency count, and ESM/tree-shake support. It distinguishes itself from siblings by explicitly noting npm-only scope and directing other ecosystems to alternative tools.

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

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

Explicitly states when to use: 'Use whenever an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me''. Also provides guidance on partial failures, timeouts, and fallback for other ecosystems.

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 it as read-only and idempotent. The description adds technical specifics: embedding model, window size, scoring, and character cap with truncation flag, providing useful context beyond annotations.

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

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

The description is a single dense paragraph that efficiently conveys purpose, usage, technical details, and limitations without redundancy. Every sentence adds value.

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

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

The description covers input constraints, output format (passages with offsets and scores), usage guidance, and technical implementation. Even without an output schema, it gives sufficient information for correct tool usage.

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

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

All three parameters are described in the schema, and the description adds context like the 200K char cap for 'text' and example queries for 'query'. It also mentions the default limit of 5, adding value beyond schema descriptions.

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

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

The description clearly states the tool does semantic search inside an already-fetched record, specifying inputs and outputs. It distinguishes from sibling tools like ask_pipeworx_grounded by focusing on internal search rather than general querying.

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 tells when to use it (when the record is too large for the prompt) and how it pairs with ask_pipeworx_grounded. It implicitly suggests not to use if the record fits in the prompt.

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 important behavioral traits: OAuth requirement, supported subscription types with detailed parameters, delivery channels with limitations (SMS 10/day cap, webhook auto-disabled after 10 failures), and phone verification requirement. Annotations indicate idempotentHint=true, but the description's 'Returns the new subscription id' might imply non-idempotency; however, there is no direct contradiction, and the description adds significant context beyond annotations.

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

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

The description is concise given the complexity, with each sentence providing necessary information. It front-loads the core purpose and then details types and delivery. While slightly verbose, it avoids unnecessary fluff and maintains a logical flow.

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 the return value (subscription id), required account, supported types, delivery options, and limitations. It lacks explicit mention of error handling or idempotency behavior, but given the presence of an idempotentHint and no output schema, it is largely complete for a creation 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?

Although schema description coverage is 100%, the description adds significant value by providing concrete examples for each subscription type (e.g., sec_8k items, FRED series_id) and explaining delivery channel behaviors (feed always on, email/SMS/webhook specifics with HMAC signing). This goes well beyond the schema's parameter names and base descriptions.

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

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

The description clearly states the verb 'Create' and the resource 'subscription' in the first sentence. It distinguishes from sibling tools like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation. The title 'Subscribe to Alerts' reinforces the purpose.

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

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

The description explicitly states the requirement for a Pipeworx OAuth account and that anonymous users cannot persist subscriptions. It provides clear context for when to use the tool (creating a proactive monitoring subscription) and lists supported types and delivery channels. However, it does not directly exclude alternatives like list_subscriptions for viewing existing ones.

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

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

Annotations already indicate readOnly and idempotent behavior. The description adds context about returning category-bucketed example questions from a live catalog and that it serves as an onboarding entry point, providing behavioral insights beyond 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 somewhat long due to listing many example intents, but it is front-loaded with the core purpose and each sentence adds value. Could be slightly more concise, but 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?

Without an output schema, the description adequately explains the return format: category-bucketed example questions with exact tool+argument shapes. It also clarifies the source (live catalog). This fully prepares the agent for what to expect.

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

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

Schema has 100% coverage for the single optional parameter. The description expands on the parameter by listing example values (e.g., 'finance', 'pharma') and explaining that omission gives a cross-category spread, adding meaning beyond 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 is the onboarding entry point, listing specific user intents (e.g., 'what can I ask?', 'give me ideas') and explaining the output (category-bucketed example questions with tool+argument shapes). It distinguishes itself from siblings by being the first tool to use when unsure what Pipeworx can do.

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

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

Explicitly states when to use: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' Also provides guidance on arguments: call with no arguments for full spread or pass `topic` to focus.

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 value beyond annotations by explaining ownership enforcement, deactivation soft-delete, and historical event preservation. 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?

Two concise sentences with front-loaded purpose, ownership rule, and side effect. Every sentence is meaningful.

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?

Adequate for a single-parameter tool with no output schema. Covers behavior and ownership, but could mention return value or error cases.

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

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

Schema coverage is 100% and the description does not add significant meaning beyond what the schema already provides for the 'id' parameter.

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

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

Description clearly states 'Cancel a subscription by id' with specific verb and resource. Distinguishes from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Explicitly mentions ownership enforcement and deactivation behavior, providing context for use. Could be improved by explicitly stating when not to use, but current guidance is clear.

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

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

Beyond read-only/idempotent annotations, the description discloses critical failure semantics: 'could_not_verify means the check did not happen... it is NOT evidence for or against the claim', and distinguishes 'unsupported' as a coverage gap. It also reveals the two data paths (SEC EDGAR/XBRL and grounded pipeline).

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

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

The description is dense but well-structured: it front-loads trigger phrases, then explains usage, return values, and caller warnings. While long, every section serves a purpose; the trigger phrase list is arguably redundant but aids detection.

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 specifies the verdict enumeration, the special semantics of could_not_verify and unsupported, the inclusion of evidence citations and reasoning, and the automatic fallback behavior, making it complete for an agent to 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?

Input schema already covers both parameters at 100% with detailed descriptions. The description adds routing context for the claim parameter but does not add meaningful beyond-schema detail for parameter semantics, so 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?

Clearly states it performs natural-language claim verification against authoritative sources, cites specific verdict types and a fast path vs grounded pipeline, and distinguishes itself from sibling research tools by focusing on fact-checking.

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 the agent needs to check whether something a user said is factually correct' and explains automatic routing between company-financial and other claims, plus notes it replaces 4–6 sequential calls, giving clear when-to-use and efficiency context.

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