Cryptocompare

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds significant behavioral context: return structure (per-model score, confidence, signals, raw_response + combined view), default model details, and API key requirement. No contradictions.

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

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

The description is concise (4 sentences) and front-loaded with the core function. Every sentence adds value: core action, model options, return format, 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?

For a tool with 4 parameters, no output schema, and rich annotations, the description covers essential aspects: purpose, parameter usage, return structure, and use cases. It is complete enough for an agent to select 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 the baseline is 3. The description explains parameter interactions (e.g., _apiKey needed for anthropic, context for disambiguation) but does not add much beyond the schema's existing parameter 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 probes LLMs for knowledge about entities and scores visibility, with a specific verb ('Probe', 'score') and resource ('LLMs', 'business/brand/product/topic'). It distinguishes from siblings like 'scan_competitor_ai_presence' by its focus on AI visibility scoring.

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 use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and explains when to use different models (free default vs. Anthropic with API key). It lacks explicit when-not-to-use or alternatives, but context is clear.

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

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

The annotations clearly indicate readOnly, idempotent, and non-destructive behavior. The description's 'Return' aligns with these hints, and there is no contradiction. The tool appears to have no side effects.

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

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

The description is a single concise sentence that lists the output fields without unnecessary detail. It is well-structured and easy to parse.

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

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

The description is sufficient for a simple list retrieval, but it does not mention potential limitations such as pagination, response size, or sorting. These are not critical, but a bit more context would make it complete.

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

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

The tool has zero parameters, so there is nothing to explain. The schema coverage is complete (no parameters). The description does not need to add parameter 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 that the tool returns the full list of tracked cryptocurrencies from CoinDesk Data, specifying the exact fields included. This is unambiguous and distinguishes it from other tools like top_market_cap or price.

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

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

No explicit guidance is provided on when to use this tool versus alternatives such as top coins or price queries. The description is self-explanatory for a simple listing, but it does not mention use cases 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 declare read-only, open-world, and idempotent behavior; the description aligns by stating it returns metadata. No contradictions, and the description adds minor clarity about the data source.

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 one concise sentence that efficiently lists the returned fields (name, country, grade, trading pairs, fee, website URL) without unnecessary details.

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

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

For a simple listing tool with no parameters, the description provides sufficient context by specifying the source and the fields returned, making it 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?

There are no parameters, so schema coverage is complete. The description does not need to explain parameters.

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

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

The description clearly states the tool returns metadata for all crypto exchanges tracked by CoinDesk Data, which distinguishes it from coin-related tools and other listing endpoints.

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

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

The description does not provide explicit guidance on when to use this tool versus alternatives, though the name is self-explanatory. It lacks any mention of conditions or comparisons.

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, and non-destructive behavior, so the description only needs to add operational context. It does: it discloses that the tool routes across many sources, fills arguments, and returns structured answers with stable pipeworx:// citation URIs. No contradiction with annotations.

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

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

The opening is strong and front-loaded, but the description repeats the 'even if web search could also answer it' phrase and duplicates the entire example list after 'START HERE'. The closing section on deep_research and news feeds is useful but could be condensed, making the overall description longer and more repetitive than needed.

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 explains the return behavior (structured answer with citations), covers many domains, provides usage triggers, and names routing alternatives. This is complete enough for a read-only question-routing tool; the main weakness is redundant phrasing rather than missing information.

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

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

Schema description coverage is 100%: all six properties are documented, including aliases for the question parameter. The description adds example query forms but no substantive meaning beyond the schema, so it meets the baseline but does not elevate it.

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

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

The description states a specific routing role: it takes a natural-language question, routes it to one of 5,798 tools across 1,517 verified sources, fills arguments, and returns a cited answer. It clearly names the resource and verb, and contrasts itself with web search, helping an agent distinguish it from siblings like deep_research or news.

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

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

The description explicitly says to prefer this over web search, lists concrete trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), and gives example questions. It also names an alternative: use deep_research for broad/multi-part questions, while positioning ask_pipeworx as the default START HERE tool, including for breaking news.

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

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

The annotations already indicate read-only, idempotent, open-world behavior, so the description's added context is valuable: it discloses that candidate routing improvements may be live, that no candidate is currently active, that it currently matches ask_pipeworx exactly, and that it is a full working router with no degraded fallback.

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 appropriately detailed for the tool's complexity, front-loads the beta relationship to ask_pipeworx, and every sentence contributes useful information about routing behavior, current status, usage, and fallback semantics. No redundancy weakens it.

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?

It covers the current experimental state, the exact relationship to ask_pipeworx, the expected response shape, the purpose of comparison, and confirms this is a fully functional router. For an agent choosing between siblings and invoking the tool, this is complete.

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

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

Schema description coverage is 100%, and every parameter is an alias for 'question'. The description only says 'same arguments' and does not add meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the tool as the beta version of ask_pipeworx and explains it is a universal router with the same 5,798 tools, arguments, and response shape. It also distinguishes it from the stable ask_pipeworx by emphasizing the experimental edge and live candidate routing improvements.

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 says to use it exactly like ask_pipeworx when the newest routing is wanted, and notes that results are compared against the stable router. It does not explicitly state when not to use it or compare against the grounded variant, but the intended usage 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?

The annotations already indicate readOnly, idempotent, open-world, and non-destructive behavior. The description adds substantial context beyond that: it reveals the multi-step routing and fetching process, the verbatim evidence requirement, the exact success and refusal payload shapes, the refusal reason enum, and the cost trade-off. Nothing contradicts the annotations.

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

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

The description is dense but every sentence earns its place: purpose, mechanism, success contract, refusal contract, usage guidance, and cost trade-off. It is front-loaded with the core differentiation and contains no filler or repetition.

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

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

There is no output schema, but the description fully compensates by enumerating the success response fields and the refusal reasons. It covers return values, edge cases, routing behavior, and when to prefer the sibling tool, making the description complete enough for an agent to invoke this tool correctly without additional information.

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

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

Schema description coverage is 100%, and the input schema fully documents the single question parameter plus aliases. The description adds context about how the question is used (routed across many sources) but no additional parameter-level semantics are necessary, so the baseline of 3 is appropriate.

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

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

The description states a specific purpose: hallucination-resistant, grounded answers for high-stakes reads. It explicitly distinguishes itself from ask_pipeworx by describing the extraction-only-from-tool-result behavior and the refusal contract, so an agent can differentiate it from sibling tools without opening schemas.

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

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

It gives explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on' with concrete high-stakes examples, and explicit when-not-to-use guidance: 'prefer ask_pipeworx for casual lookups' due to the extra LLM call cost. The alternative tool is named directly.

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

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

The description goes far beyond annotations, detailing resolver contract, parent event extractor, news fields, safety checks, closed market handling, and resolution-rule risk. It discloses low-confidence match short-circuiting and wide-spread market warnings. No contradictions with annotations (readOnlyHint=true, idempotentHint=true).

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

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

The description is long but well-structured with labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.). Each part adds relevant detail. Slightly verbose but justified by tool complexity. Good front-loading with the core purpose.

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

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

No output schema provided, but the description thoroughly explains response shapes: market fields, analysis, evidence, resolver contract, parent event, news fields, and safety mechanisms. Covers all necessary aspects for an agent to use the tool effectively.

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

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

Schema coverage is 100%, and the description adds significant context: market accepts slug, URL, or question text; depth is explained with default 'thorough'; include_raw detailed with use cases. Examples in input schema further clarify. 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?

The description clearly states it researches a Polymarket bet by pulling Pipeworx data. It mentions resolving the market, classifying the bet, fanning out to data packs, and returning evidence and comparison. It distinguishes from sibling tools like polymarket_edges by focusing on a single bet research.

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

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

The description explicitly says 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"'. It provides examples and context, but does not explicitly mention when not to use or how it differs from alternatives like polymarket_edges. Still, clear usage 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?

Discloses data sources (SEC EDGAR/XBRL, FAERS, FDA), handling of off-calendar fiscal years, sorting by primary metric, and return format including citation URIs. Adds substantial value beyond annotations.

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

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

Description is appropriately sized with front-loaded examples. Every sentence adds value, though slightly verbose. Good structure and 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?

Covers purpose, usage, data sources, return values, and efficiency gains. No output schema but adequately describes results. Complete for a comparison tool.

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

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

Schema coverage is 100% with descriptions; description further explains what each type pulls, provides examples for values, and clarifies constraints. Goes 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 explicitly states it performs side-by-side comparisons of 2-5 companies or drugs, with example queries. Clearly distinguishes from siblings by advocating over 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?

Provides explicit when-to-use guidance ('ALWAYS PREFER over sequential single-pack lookups'), explains data sources for each type, and gives examples. No explicit when-not-to, but context is sufficient.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds substantial behavioral context beyond those: account tiers and paid-depth requirements, parallel decomposition across 5,798 tools, gap recovery, contradictions scanning, citation_uri fetchability guarantees, semantic excerpting of large records, and expected latency. No contradiction with annotations exists.

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

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

The description is long but information-dense, with no filler; every sentence contributes prerequisites, capability, alternatives, or behavior. It is front-loaded with the account gate and the alternative tool, but the wall-of-text format would be easier to scan with brief structural breaks.

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

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

Given there is no output schema, the description adequately covers what the agent should expect in the return packet (findings with verbatim evidence, confidence, source, fetched_at, citations, gaps[], contradictions[], hop field, citation_uri). It also covers prerequisites, latency, limitations, and depth semantics, making the tool's behavior and boundaries clear enough for reliable invocation.

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

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

Schema description coverage is 100% and the enum descriptions already explain the depth levels in detail. The description adds value beyond the schema by clarifying real-world tradeoffs such as 'thorough needs a paid plan', gap-recovery behavior, the contradictions[] scan, and explicitly confirming that broad/multi-part natural-language questions are appropriate for the question 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 states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources' in ONE call, and explicitly contrasts this with open-web search. It also names the sibling tool ask_pipeworx and explains the meaningful difference, so an agent can distinguish deep_research from related tools without opening their schemas.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: use ask_pipeworx if not signed in, for a single lookup, and for breaking or colloquial current-news topics; use deep_research for broad/multi-part structured-data questions. It also explains which depth value to choose based on needed iteration, leaving little to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds useful behavioral context: the tool returns top-N relevant tools with schemas and examples, ready to call directly. It also states 'no second schema lookup needed,' which is important for usage flow.

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

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

The description is concise at ~100 words, front-loaded with purpose, and structured into usage context and return value. Every sentence adds value: it states when to use, what it returns, and a key benefit (ready to call).

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 explains the return value clearly: 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly.' This is sufficient for an agent to understand what to expect.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions natural language query but does not add significant meaning beyond what the schema already provides (e.g., aliases, examples). The description's mention of 'natural language description' is already implied by the examples 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 clearly states the tool's purpose: 'Find tools by describing the data or task.' It uses specific verbs like 'browse, search, look up, discover' and lists concrete domains (SEC filings, FDA drugs, etc.), distinguishing it from sibling tools that perform specific tasks rather than discovery.

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 usage guidance is provided: 'Use when you need to browse, search, look up, or discover what tools exist for' and 'Call this FIRST when you have many tools available and want to see the option set.' This tells the agent exactly when to invoke this tool versus others.

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

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

The description adds substantial behavioral context beyond the readOnly/idempotent annotations: multi-source fan-out, source fallback (GDELT→GNews), soft-fail behavior for USPTO patents after sunset, the 'empty section is a real no-data, not a bug' semantics, and the resolved:false path for private companies. This is exactly the kind of behavior an agent needs to interpret results correctly.

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

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

The description is long, but the complexity of a multi-source entity profile tool justifies it. It is front-loaded with usage examples and the core value proposition, and uses semicolon-delimited source/field lists that are scannable. Some redundancy exists where it repeats type/value semantics already in the schema.

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

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

There is no output schema, so the description carries the full burden of documenting return content. It does so thoroughly: cik/company_name/resolution fields, recent_filings URI format, fundamentals fields, patents, contracts, FDA products, hiring, news, LEI, and sources_used/sources_failed semantics. An agent has enough information to invoke the tool and interpret its response.

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 covers both parameters at 100%, so the baseline is 3. The description adds meaning by clarifying accepted value shapes with examples, emphasizing zero-padded CIKs, noting that names resolve via SEC EDGAR company-name match, and stating that 'company' and 'ticker' are interchangeable. That pushes it 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 uses a specific verb and resource: 'full cross-source profile of a US public company in ONE parallel call.' It gives concrete invocation examples and explicitly distinguishes itself from chaining single-pack SEC/XBRL/news lookups, so an agent can tell it apart from related 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?

It explicitly instructs when to prefer this tool ('ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view') and gives trigger phrasings like 'Tell me about X' and 'brief me on Tesla.' It also clarifies scope (US public company) and behavior for private companies.

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

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

Description aligns with annotations (destructiveHint=true) and adds behavioral context about clearing stale/sensitive data. No contradictions.

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

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

Two sentences: first states purpose, second gives usage guidance. No wasted words. Perfectly 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?

With annotations covering destructive nature, description adds usage context. No output schema but adequate for simple delete. Could mention result behavior but not required.

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?

Single parameter 'key' is fully described in schema (100% coverage). Description does not add extra meaning beyond 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?

Description uses strong verb 'Delete' with resource 'previously stored memory by key', clearly distinguishing from siblings 'remember' and 'recall'.

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

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

Provides explicit when-to-use scenarios (stale context, task done, clear sensitive data) and references paired tools, but lacks explicit when-not-to-use or 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 declare readOnlyHint, idempotentHint, and destructiveHint as true/false appropriately. Description adds behavior: fetches page, extracts title/description/key links, emits markdown. No contradictions; provides 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?

Description is a single paragraph, front-loaded with the core action. Slightly verbose with examples of crawler names, but overall efficient and well-structured.

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

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

With only 2 parameters and no output schema, description covers what the tool does, how to use it, and the output format. Provides sufficient context for an AI agent to decide when to invoke it. Not missing critical information.

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

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

Schema coverage is 100% with clear descriptions for both parameters. Description mentions max of 50 for max_links, consistent with schema. Does not add new semantic information beyond what schema already provides, 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?

Description clearly states it generates an llms.txt file for any URL, specifying the verb 'generate', the resource 'llms.txt file', and the purpose for AI crawlers. It distinguishes itself from sibling tools, none of which perform this function.

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 three use cases (client indexing, drafting own project, auditing competitor), providing clear context. Lacks explicit when-not-to-use guidance, but the use cases effectively imply appropriate scenarios.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is well-covered. The description adds that the tool provides daily historical data, but does not disclose any additional behavioral traits like response size limits or data availability. The description does not contradict annotations.

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

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

The description is two sentences long, front-loaded with the main functionality, followed by use cases. Every sentence adds value without redundancy or fluff.

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

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

Despite having an output schema and annotations covering safety, the description lacks parameter documentation for six parameters, leaving users uncertain about how to use optional fields like limit, aggregate, and toTs. For a tool intended for backtesting and macro analysis, this is a significant gap.

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

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

Schema description coverage is 0%, meaning the description does not explain any of the six parameters. It only implies that fsym and tsym are the crypto pair. The examples in the input schema provide some context, but the description itself adds no parameter meaning. This is insufficient for a tool with multiple optional parameters.

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

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

The description clearly states 'Daily historical OHLC + volume for a crypto pair', which is a specific verb and resource. It distinguishes from siblings (histo_hour, histo_minute) by the word 'daily' and the use cases for long-horizon charting. However, it could more explicitly state that it returns daily data only.

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

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

The description says 'Use for long-horizon crypto charting, multi-year backtests, and macro analysis', which implies the tool is for daily frequency and long-term analysis. However, it does not explicitly state when not to use it or mention alternative tools (e.g., histo_hour for hourly data). The guidance is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds no new behavioral traits beyond return type. No mention of rate limits, auth, or other constraints.

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, front-loaded with core purpose. 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?

Adequately covers purpose and usage context, but with 6 parameters and 0% schema coverage, the lack of parameter descriptions makes it incomplete for agents to use correctly. Output schema exists but not referenced.

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

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

Schema coverage is 0% and description explains only fsym, tsym (via pair examples) and limit (via examples). Parameters like e, toTs, aggregate remain unexplained, leaving gaps for a tool with 6 params.

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 hourly historical OHLC+volume for crypto pairs, with examples (BTC/USD, ETH/USDT). It distinguishes from siblings by specifying hourly and medium-timeframe usage, differentiating from histo_day and histo_minute.

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 use cases: medium-timeframe charting, swing-trading, multi-day backtests. Does not explicitly list when not to use or alternatives, but the hourly specificity implies differentiation from minute/daily 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, idempotentHint, and destructiveHint, so safety profile is clear. Description adds that data comes from 'major exchanges' and is historical, which is consistent but not significantly augmentative.

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 efficient sentences. Front-loaded with key information (granularity, data type, 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?

Output schema exists, so return format is covered. Purpose and safety are clear. However, lack of parameter documentation leaves a gap for a 6-parameter tool, requiring agent to rely on examples or external knowledge.

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

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

Schema description coverage is 0%, yet description provides no explicit parameter explanations. Only hints from examples (fsym, tsym, limit, aggregate). Parameters like 'e' and 'toTs' remain unexplained, forcing inference.

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

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

Description clearly states it provides minute-granularity historical OHLC + volume for crypto pairs, with specific examples (BTC/USD, ETH/USDT). Differentiates from sibling tools histo_day and histo_hour by specifying minute granularity.

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

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

States to use for 'short-timeframe charting, intraday backtests, and tick-level analysis,' which provides clear context. Does not explicitly mention alternatives or when not to use, but sibling names (histo_day, histo_hour) imply longer timeframes.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, so the description doesn't need to reiterate safety. However, it adds value by detailing the return fields, which is behavioral information not 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?

Two sentences, no filler. The first sentence states the main action and return fields; the second gives usage guidance. Highly efficient.

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

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

For a simple listing tool with one optional parameter and no output schema, the description fully covers the tool's purpose, return shape, and usage context. No further details 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?

The input schema has 100% coverage: the only parameter 'include_inactive' has a description. The tool description does not add any additional meaning beyond what the schema already provides, 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 lists the caller's active subscriptions and specifies the returned fields (id, type, params, created_at, last_fired_at, fire_count). Distinguishes from sibling tools subscribe and unsubscribe by mentioning using the result to find an id to cancel.

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 the tool: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This implies when not to use it (for adding or canceling directly).

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 define readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it's aggregated from CoinDesk Data (formerly CryptoCompare) and mentions filtering by category/feed, but does not disclose additional behavior such as rate limits, pagination, or return format details. It adds some context but not deeper behavioral insights.

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 only two sentences, front-loaded with the core purpose and supported by usage guidance. Every sentence contributes value: the first defines the feed and its content, the second explains filtering and when to use it. No filler or redundant information.

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

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

Given the tool has an output schema and strong annotations, the description is reasonably complete. It provides purpose, usage guidance, and some parameter context. However, it omits details on all parameters and doesn't mention return format or any special behavior, though output schema likely covers that. Overall, it's adequate for an agent to understand the tool's role.

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 6 parameters with 0% description coverage, so the description must compensate. It explains the 'categories' and 'feeds' parameters by listing examples (BTC, ETH, Trading, Regulation) and mentioning filtering, but leaves other parameters (lTs, lang, sortOrder, excludeCategories) undocumented. The description partially covers the parameter semantics but is insufficient for the full set.

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

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

The description clearly states it's an 'aggregated crypto news feed' with specific content types (Bitcoin/Ethereum/altcoin headlines, exchange announcements, regulatory updates, market analysis). It mentions filtering by category or feed, and explicitly positions it for 'what is happening in crypto right now', distinguishing it from web search as a specialized source.

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 context: 'Use for "what is happening in crypto right now"' and 'Prefer over web search for crypto-specific news.' However, it doesn't explicitly exclude alternatives like news_categories or news_feeds, which are siblings and could be used for discovering filter options, nor does it mention when not to use this tool for non-news queries.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context by explaining it returns tags and lists examples, though it doesn't disclose how the list is ordered or if it's exhaustive. 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, each serving a distinct purpose: stating the action with examples, and providing usage guidance. No filler words.

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

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

For a simple listing tool with no parameters and an output schema, the description is complete. It tells what it returns, gives examples, and explains how to use it in a workflow.

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 no parameters, so the baseline is 4. The description provides no parameter information (unnecessary) but adds value with examples of category values.

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 includes a specific verb ('List'), a clear resource ('crypto news category tags'), and concrete examples (BTC, ETH, Trading, etc.). It distinguishes itself from sibling tools like 'news' by focusing on categories rather than the feed.

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 to 'Use as a directory before calling news() with a category filter', providing direct guidance on when and how to use this tool in conjunction with another.

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, covering safety and behavior. The description adds that the tool returns feed IDs and metadata, but does not disclose other behavioral aspects like pagination or rate limits. With annotations present, this is adequate.

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

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

Two clear, front-loaded sentences with no fluff. The purpose and usage are stated directly, making it highly concise and well-structured.

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

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

With an output schema providing return details, strong annotations, and no parameters, the description fully covers what an agent needs to know. It explains the tool's role and how to use it with the news tool, making it complete.

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

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

The tool has zero parameters, so the baseline is 4. The description implies no inputs are needed and reinforces the directory use case, which is sufficient. No additional parameter explanation is required.

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

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

The description clearly states the tool lists crypto news source publishers with feed IDs and metadata, and explicitly positions it as a directory for filtering news() by source. This distinguishes it from sibling tools like news and news_categories.

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

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

The description explicitly says 'Use as a directory before filtering news() by source,' giving a clear when-to-use directive and linking it to the news tool. This effectively guides the agent.

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

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

Despite annotations carrying no useful hints (all false), the description fully discloses behavior: rate limit (5 per day), free, no quota count, the claim_token flow for anonymous filing and later status retrieval, plus operational cadence (daily digests, roadmap influence). No contradiction with annotations.

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

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

The description is well-structured and front-loaded, leading with purpose before navigating through usage, exclusions, token mechanics, and constraints. Every sentence carries operational value; no fluff or redundancy.

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

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

With no output schema, the description fully explains return behavior: claim_token generation on anonymous filing, later resolution status retrieval. It also covers non-goals (third-party server tools), context requirements (Pipeworx tools/packs), and operational limits (rate limit, quota). Complete for a feedback tool.

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

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

Schema coverage is 100%, so all parameters are already documented. The description adds a few meaningful usage details (e.g., 'don't paste the end-user's prompt') and reinforces the claim_token workflow, but it mostly relies on the schema for parameter-specific 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 opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It enumerates the exact feedback types (bug, feature/data_gap, praise) and clearly distinguishes the tool from all siblings by being the sole feedback channel.

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 when-to-use criteria are provided: 'returns wrong/stale data (bug)', 'wish existed (feature/data_gap)', 'worked surprisingly well (praise)'. It also gives a clear exclusion for tools from other MCP servers and offers a disambiguation method (checking the connection's tool 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 already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context: data is self-aggregating, derived from CF analytics, no PII, and cached differently per window. 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 compact and front-loaded with the main result. It uses bullet points for clarity, but could be slightly more streamlined. Every sentence adds value, achieving good conciseness.

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

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

For a simple read-only tool with one parameter and no output schema, the description is complete. It explains the return values (top tools, packs, volume), caching behavior, and privacy, leaving no significant gaps given the 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?

The sole parameter 'window' is fully documented in the schema with enum values and descriptions. The description adds a brief note about shorter vs. longer windows but does not significantly extend the schema's explanation. Baseline of 3 is appropriate.

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

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

The description clearly states what the tool does: 'Returns the top tools, top packs, and total call volume over a recent window'. It identifies a specific resource (trending usage on Pipeworx) and distinguishes from sibling tools like discover_tools or ask_pipeworx by focusing on aggregate agent call data.

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

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

The description provides three concrete use cases: discovering hot data sources, confirming canonical tools, and checking alignment. While it does not explicitly exclude scenarios or name alternatives, the context is clear and helps an agent decide 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?

Description goes beyond annotations (readOnlyHint, idempotentHint) by detailing semantic anchor (≥0.30 Jaccard similarity), partition filter (drops placeholder slugs), and fill check (live CLOB depth). 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 densely informative but slightly verbose, with detailed subsections. It front-loads the main purpose, but could be more concise by moving some details to a separate section. Still well-structured.

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

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

Despite having no output schema and only two optional parameters, the description fully covers all aspects: modes, filtering logic, response structure ('opportunities[]', 'partition_check'), and edge cases. It is self-contained for agent understanding.

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

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

Schema coverage is 100%, but description adds significant value: explains 'event' accepts full URLs, 'topic' is a seed question that triggers cross-event search, and describes internal behaviors for 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 the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It specifies three modes: no args (trending scan), event (single event slug), and topic (cross-event scan). This distinguishes it from siblings like polymarket_edges and polymarket_fill_risk.

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

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

Explicit instructions for when to use each mode: 'Call with NO args for a trending_scan', 'event (recommended for a specific market)', 'topic (for cross-event scanning)'. Also provides exclusion criteria: 'realizable_edge_pp ≤ 0 means ... do not trade it' and an alternative: 'For custom sizing use polymarket_fill_risk'.

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 caching (1h at KV level), computation methods (lognormal barrier, GDELT), and limitations (Fed bets unreliable without paid data). Adds significant context beyond annotations (readOnly, idempotent). 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?

Dense but well-structured with sections like 'FIVE MODEL FAMILIES' and 'TRADEABLE-EDGE KNOBS'. Front-loads purpose. Every sentence adds value, though length could be slightly optimized for parsing.

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

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

With no output schema, description details response structure (by_segment, fed_candidates, _diagnostics) and explains why segments may be empty. Covers all necessary context for agent to evaluate tool output.

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%, description adds further meaning: 'min_kelly' skips too-small bets, 'min_edge_pp' is net of slippage, 'slippage_pp' explains typical bid/ask costs. Provides actionable context beyond schema.

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

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

Description clearly states 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' with specific verb and resource. It distinguishes from sibling tools like polymarket_arbitrage and polymarket_edge_tracker by detailing model families and 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 says 'Built for what should I bet on today' and explains tradeable-edge knobs. Provides when-to-use guidance for parameters like min_liquidity, max_spread_pp. Lacks explicit exclusions of alternatives but context is clear.

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

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

The description adds significant behavioral context beyond annotations, including history limits (60-day TTL), decay calculation from daily closes, snapshot gaps due to cache-miss, and a detailed breakdown of the response structure.

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 the core purpose, but it is somewhat dense. Each part adds value, though it could be slightly more concise without losing essential details.

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

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

Given no output schema, the description comprehensively explains the return values (tracked, expired, snapshot_dates) and covers edge cases like gaps and limitations, providing complete context for using the tool.

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

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

Schema coverage is 100% with parameter descriptions, but the description adds context such as default and max for `days`, and explains `window` as a snapshot family, enhancing understanding of how parameters affect data retrieval.

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

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

The description clearly states the tool provides edge persistence and decay telemetry, distinguishing it from the sibling `polymarket_edges` by focusing on historical behavior rather than 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?

The description implies usage for deciding whether to act on an edge based on its age, and contrasts fresh vs. old edges. While it does not explicitly state when not to use it, the context and sibling list indicate `polymarket_edges` is the alternative for current edges.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds rich context: it walks the order-book ladder, returns a verdict (clean|degraded|cannot_fill), and warns about forced directional risk and thin legs. No contradiction with annotations.

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

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

The description is well-structured with capitalized mode headers and a concluding warning. However, it is somewhat lengthy (around 250 words) and the final sentence is dense. The structure aids readability, but conciseness could be improved.

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, multiple return fields) and the lack of an output schema, the description thoroughly explains what is returned for each mode (e.g., top_of_book, vwap_fill_price, profit_usd). It could be more explicit about the return structure, but overall it provides a complete picture.

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 significant value beyond schema by explaining how parameters behave differently in each mode (e.g., size_usd interpretation, side defaults). It also clarifies the relationship between market and event parameters.

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

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

The description clearly states the tool's purpose: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It describes two modes (single-market and basket) and explicitly distinguishes from sibling tools like polymarket_arbitrage and polymarket_edges by stating when to use this 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?

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 also explains why this is necessary, citing risks like unhedged directional positions from partial fills.

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

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

With readOnlyHint, idempotentHint, and destructiveHint already set, the bar is lower, yet the description adds substantial behavioral context: compatibility_warning/codes can be non-empty even with matched_pairs>0, unclassified legs are never paired, temporal_alignment=null means 'not computed' rather than aligned, and the tool does not model Kalshi's fee schedule, making spreads gross rather than net. This goes well 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 long and dense, but it is organized with labeled sections (TWO MODES, RESPONSE, SAFETY FIELDS, codes) and every sentence carries functional information. It could be tightened, yet the length is largely earned given the tool's complexity and the absence of an output schema.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: leg-by-leg prices, top_spreads_pp, compatibility_codes, per-entry flags, temporal_alignment, skipped_cross_type/subtype counters, and fees_note. It also warns about the rarity of real cross-venue spreads and how to interpret warnings, making the tool's behavior fully actionable.

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

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

Input schema coverage is 100%, with individual parameter descriptions for all three fields, so the baseline is 3. The description adds extra meaning beyond the schema by explaining the semantics of each mode: topic triggers pre-mapped shortcuts, explicit tickers override the mapped side, and both run the same matcher. It enriches the parameters' meaning without being strictly necessary.

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 function: compute the cross-venue spread between Kalshi and Polymarket for the same resolving question. It clearly identifies the resource (two prediction-market venues) and the output (spread in percentage points), and it distinguishes this tool from simpler single-venue tools by emphasizing the cross-venue, matching-signal nature.

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

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

The description explicitly presents TWO MODES, tells the user which parameters to use for each, and warns that pre-mapped topics often return compatibility warnings ('pre-mapped ≠ tradeable'). It gives clear context for when to use the tool, but it does not explicitly compare it to sibling tools such as polymarket_arbitrage or polymarket_edges, so it lacks an explicit exclusionary routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds context about aggregation across major exchanges and the data source (CoinDesk Data), which is useful. It doesn't contradict annotations. It provides some additional behavioral insight beyond the annotations.

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

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

The description is a single, tightly worded sentence that conveys the tool's purpose and key parameters without fluff. It is front-loaded and to the point, earning a perfect score for conciseness.

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

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

For a read-only spot price tool with a rich output schemaasi, the description covers the essential use case (one coin, many quotes, aggregated source). It omits details on optional parameters (e, sign, extraParams), but those are likely less critical for basic usage. The presence of an output schema fills in return value details. Overall, it is adequate for a simple tool.

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

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

The description explains the primary parameters fsym (one coin) and tsyms (many symbols), but does not explain the optional parameters e, sign, or extraParams. Since schema description coverage is 0%, the description must compensate for all parameters, but it only covers two out of five. The meaning of the remaining parameters is left ambiguous.

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

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

The description clearly states the tool fetches current crypto spot price for one coin (fsym) quoted in multiple currencies (tsyms), with a specific data source (CoinDesk Data). It distinguishes from price_multi (likely for multiple coins) implicitly, but it doesn't explicitly name exact alternatives like price_full or price_multi.

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

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

The description implies it's for a single coin with multiple quote symbols, and that the price is aggregated. However, it does not explicitly state when to use this tool over siblings like price_multi or price_full, nor does it mention any exclusions or prerequisites. The guidance is implicit rather than explicit.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the description does not need to repeat these. The added source note (CoinDesk Data) provides minor context. No contradictions with annotations, but the description adds little extra behavioral transparency beyond 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 a single, compact sentence that efficiently lists the data fields and the direction of the mapping. It is well-structured and to the point, with no superfluous information.

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

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

Given that the tool has an output schema (though not shown in the provided snippet), the description does not need to detail the return structure. It provides sufficient context for the data source and the scope of the snapshot. However, it could be slightly more explicit about the multi-pair capability being a list of symbols and currencies.

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

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

The description states 'fsyms → tsyms' indicating a mapping from crypto symbols to currency codes, giving a hint. However, it does not explain the optional 'e' parameter at all, and the parameters have no schema descriptions. The description partially clarifies the direction but leaves key semantics ambiguous.

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

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

The description clearly states the tool fetches a full market snapshot for multiple crypto pairs, enumerating the specific data points (price, 24h change, volume, market cap, open/high/low). It distinguishes itself from simpler price tools by emphasizing 'full' and 'multiple' pairs.

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

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

The description implies usage when a comprehensive snapshot is needed (including volume, market cap, etc.) rather than just price, and it supports multiple cryptocurrency pairs. However, it does not explicitly contrast with sibling tools like 'price' or 'price_multi', so the guidance is implicit rather than explicit.

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

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

Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds a behavioral detail—'aggregated across major exchanges'—which clarifies that prices are aggregated rather than from a single source. 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 a single, concise sentence that front-loads the tool's purpose and uses parentheses to clarify parameter meanings. It is well-structured and free of unnecessary details.

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

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

The description provides sufficient context for the tool's functionality—what it does, the data source, and aggregation behavior. It does not explain return values, but since an output schema is present, this is acceptable. The description is complete for its simple purpose.

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

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

The description explains the required parameters 'fsyms' and 'tsyms' by mapping them to 'many coins' and 'many symbols'. It does not clarify optional parameters like 'e', 'sign', or 'extraParams', but these are not required and the main meaning is conveyed.

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

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

The description clearly states the tool's function: retrieving current crypto spot prices for multiple coins (fsyms) and multiple quote symbols (tsyms), aggregated from major exchanges. It is specific and distinguishes from a single-price tool by emphasizing 'many coins at once'.

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

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

The description implies usage for scenarios requiring multiple coin prices in multiple currencies, as indicated by 'many coins at once' and 'many symbols'. However, it does not explicitly compare with alternatives like a single-price tool, though the context makes the intended use clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds context about scoping (by identifier) and the dual behavior (retrieve vs list all keys). This value goes 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?

Three sentences, each serving a clear purpose: first sentence states main action, second gives usage rationale, third explains scope and pairing. No fluff, well-structured.

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

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

For a simple retrieval tool with one optional parameter, the description covers behavior, scope, and relationship to siblings. No gaps given the complexity and lack of output schema.

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

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

Schema coverage is 100% and the schema already describes the 'key' parameter well. The description provides examples and usage context, but does not add substantial new 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 the verb 'retrieve' or 'list', specifies the resource (saved values/keys), and distinguishes from sibling tools (remember, forget) by mentioning the pairing. Examples like 'user's target ticker' add concreteness.

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 ('look up context the agent stored earlier') and briefly indicates alternatives ('pair with remember... forget'). No explicit when-not-to-use, but the context is clear given the simplicity of the tool.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds transparency about the mark_read side effect and that polling is safe, enhancing understanding beyond annotations. 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 concise at 5 sentences, with the main purpose first, then parameter details, and finally an alternative endpoint. No redundant or irrelevant 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 explains what is returned (source, citation_uri, raw payload) and covers all parameter behaviors. Missing details like pagination are minor given the limit parameter. The alternative endpoint is a nice addition.

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 adds meaningful context for parameters, such as an example for type ('sec_8k'), the effect of mark_read on subsequent calls, and the limit range (1-200). This goes 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 pulls fired events from the subscription feed, specifies what each alert contains (source, citation_uri, raw payload), and mentions filtering options. This is specific and unambiguous, with no sibling tools to confuse it.

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 some context (polls work fine, alternative endpoint for scripts/dashboards) but does not explicitly state when to use this tool versus other tools or when not to use it. There are no direct sibling alert tools, so the lack of exclusions is acceptable but not 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 already declare readOnlyHint, idempotentHint, etc. The description adds valuable context: fans out to multiple sources (SEC, GDELT, USPTO), fallback logic, soft-fail behavior, and return structure. 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 well-structured, front-loaded with example queries, and every sentence adds value. No redundant or vague phrases.

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

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

With no output schema, the description clearly states return structure (changes[] grouped by source, total_changes count, citation URIs) and covers all parameter usage. It is complete for an AI 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%, baseline 3. The description adds meaning: explains 'since' format (ISO date or relative), suggests typical monitoring values, and clarifies 'value' can be ticker or CIK. Exceeds baseline with concrete examples.

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

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

The description clearly states the tool provides a change feed for a company over recent time windows, with example queries. It distinguishes itself from sibling tool entity_profile by contrasting the dynamic feed vs static profile.

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

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

It explicitly lists when to use (e.g., 'What's new with X') and when not to (use entity_profile for static profiles). It also provides parameter guidance like typical 'since' values and explains fallback behavior.

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 write, idempotent, not destructive. The description adds valuable context: key-value storage, scoping by identifier, persistence differences between authenticated and anonymous sessions (24 hours vs persistent). This goes 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 efficiently structured: purpose first, then usage, then behavioral detail, then pairing. Every sentence adds value; no fluff. Could be slightly more concise, but overall well-organized.

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

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

For a tool with no output schema, the description does not explain what the agent can expect as a result (e.g., confirmation, error messages). Overwriting behavior is implied by idempotentHint but not explicit. Missing these details reduces completeness.

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 gives examples for key/value but does not add new semantic meaning beyond what the schema's descriptions already provide.

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

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

The description uses a specific verb ('Save') and resource ('data... key-value pair') and clearly distinguishes from siblings by mentioning recall and forget. It explicitly states the tool's role in the memory system.

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 context for when to use the tool ('when you discover something worth carrying forward') and gives concrete examples. It also pairs with recall and forget, but does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds meaningful behavioral detail: cascades through multiple endpoints, graceful degradation when GLEIF/OpenFIGI are unavailable, explicit 'unresolved' field, and the figi_candidates fallback for ambiguous matches. 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 long but dense and well-organized; it front-loads the core use case and query patterns, then elaborates on details and edge cases. Every section adds value, though it could be tightened without losing crucial context.

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 lookup tool with no output schema, the description covers everything an agent needs: input forms, supported entity types, ambiguity resolution, unresolved handling, enrichment degradation, and the relationship to manual lookups. It removes the need for guessing or extra probing.

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 both parameters already described, but the description significantly enriches semantics: clarifies that 'value' must be the entity name only (not the full noun phrase), warns about trailing security-class words, and provides concrete examples for both company and drug types. It adds genuinely useful 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?

States a specific verb and resource: resolve a user-spoken name to canonical/official identifiers. Clearly distinguishes its purpose from siblings by enumerating query patterns ('What's the ticker for…', 'find the CIK for…') and explicitly frames itself as the tool for name-to-ID conversion. The 'Use FIRST' directive separates it from other lookup or research 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?

Provides explicit guidance: 'Use FIRST whenever you have a name but need an ID.' It details supported entity types, input formats, and edge cases (ambiguous matches, unresolved IDs, instrument types that never have a ticker). Does not explicitly list when NOT to use it or name a sibling alternative, so it stops short of a full when/when-not exclusion.

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 safe, read-only, idempotent behavior. Description adds operational detail: probes each entity, ranks results, returns scores/confidence/signal density.

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

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

Three sentences, front-loaded with core function. No wasted words. Each sentence adds unique insight.

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?

Explains input, behavior, and output structure. Minor gap: 'signal density' and score calculation not detailed, but acceptable given complexity and no output schema.

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

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

Schema coverage is 100% but description adds important context: first entity is subject, models default to workers-ai, context disambiguates. 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?

Clearly states it compares AI visibility across multiple entities, ranks them, and identifies best/worst. Distinct from sibling ai_visibility_check (single entity) and compare_entities (generic).

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 use for competitive AI-marketing audits with example. Does not explicitly state when not to use, but context implies single-entity use goes to ai_visibility_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 provide readOnly, idempotent, openWorld. Description adds valuable context: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, sources_failed list if timeout. 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?

Description is comprehensive but not overly verbose; it front-loads purpose, then return details, ecosystem scope, and edge-case behavior. Every sentence adds value, though slightly long.

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

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

Despite no output schema, description lists return fields (summary block, advisories, links, alternatives) and mentions partial failure sources. Complete enough for 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?

With 100% schema coverage, baseline is 3. Description adds that scoped packages are accepted and version defaults to latest, which enriches semantics beyond schema.

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

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

Description clearly states the tool as a composite check for npm package safety, popularity, and size, distinguishing it from sibling tools (no other dependency scan tool). Specific verb 'check' and resource 'npm package' with exact scope.

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

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

Explicitly states when to use: 'whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. Also specifies limitations (NPM only in v1, alternatives for other ecosystems) and behavior on partial failures.

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

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

Goes beyond annotations by detailing embedding model (BGE-base-en), windowing (500-char overlapping windows), character cap (200K chars with truncation flag), and output features (character offsets for verbatim quotes). Annotations already indicate read-only/idempotent; description adds rich 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?

Well-structured with clear topic sentences. Slightly verbose (120 words) but every sentence adds useful information. Could be trimmed slightly 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?

Despite lacking output schema, the description fully explains return content (passages with offsets and scores), covers truncation behavior, and includes technical details. Completely sufficient for agent understanding.

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

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

Schema covers all 3 parameters (100% coverage). Description adds value: explains query as natural-language with examples, mentions default and range for limit, and adds 200K char constraint for text 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 'Semantic search INSIDE a fetched record' and gives concrete examples (SEC 10-K, article, tool result). It distinguishes the tool from siblings by explaining its pairing with ask_pipeworx_grounded.

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

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

Explicitly tells when to use: 'when the record is too big to cram into the prompt'. Explains how it pairs with ask_pipeworx_grounded, providing clear guidance on alternatives.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds minimal behavioral details beyond purpose; it does not mention potential errors, rate limits, or return format. It partially compensates by listing the data fields, but overall transparency is limited.

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

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

The description is a single, clear sentence without redundant words. It effectively conveys the essential information and lists key metrics, maintaining high conciseness and structural 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?

There is no output schema provided, so the description must compensate. It lists the specific social media stats (Twitter followers, Reddit subscribers, Facebook likes, GitHub activity), giving an incomplete picture of the response. It does not mention other potential fields or the format of the output, leaving some context missing.

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

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

The schema only defines coinId as a required number with no description. The description clarifies that it is a CoinDesk/CryptoCompare coinId and indicates the type of data returned, but does not explain the numeric format or origin thoroughly. This adds partial meaning but leaves ambiguity.

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

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

The description clearly states the tool's purpose: 'Fetch social media stats for a coin' with a specific resource (social media stats) and target (a coin). It distinguishes from sibling tools by focusing exclusively on social metrics, unlike others like price or historical data.

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

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

No explicit guidance on when to use this tool compared to alternatives. While it mentions the coinId format, it does not provide context such as 'use when you need social engagement numbers' or differentiate from similar tools like all_coins or price. The description lacks practical usage scenarios.

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 behavioral details like OAuth requirement, delivery channels with caps, and webhook signing. However, annotation idempotentHint=true contradicts the description which implies each call creates a new subscription, not idempotent.

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

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

Front-loaded with main purpose, structured with examples and sub-bullets. Could be slightly shorter but each 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 all aspects: purpose, types, params, delivery options, requirements (OAuth, phone verification), constraints (daily cap). No output schema, but states returns subscription id and webhook secret. Complete for a complex tool.

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

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

Adds substantial meaning beyond input schema: explains type enum with examples, params object with type-specific filters, and delivery constraints (phone verification, cap). Schema coverage is 100% so baseline is 3, but description significantly enriches it.

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

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

Clearly states it creates a proactive monitoring subscription to a live-data event stream. Lists supported types and delivery channels. Distinct from siblings like list_subscriptions and unsubscribe.

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

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

Provides clear guidance on when to use (create subscription) and when not (anonymous accounts). Mentions alternatives like recent_alerts and GET endpoint. Does not explicitly differentiate from siblings but context is clear.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context that the tool returns 'category-bucketed example questions drawn from the live catalog of thousands of tools', which explains the dynamic nature beyond static annotations.

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

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

The description is a single paragraph that front-loads with natural language queries, making it easy to understand. While it includes some redundancy (listing multiple example phrases), it remains compact and well-structured for an agent.

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

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

For a simple one-parameter tool with no output schema, the description fully covers the return format (category-bucketed examples with tool shapes), usage context (first-time use, meta-tools), and how to focus with a topic. No gaps are evident.

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 the 'topic' parameter described. The description adds value by explaining that omitting the topic gives a full spread and passing a topic focuses the results, along with example values, which enriches the 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 the tool returns category-bucketed example questions with tool and argument shapes, distinguishing it from sibling tools as the onboarding entry point. Specific verbs like 'returns' and 'call with no arguments' make the purpose explicit.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and gives options for passing a topic or omitting it. It implies alternatives by mentioning meta-tools but does not explicitly list when not to use it.

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

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

Annotations already indicate readOnly, idempotent, openWorld, and non-destructive behavior. The description adds pagination behavior and the role of tsym, but does not disclose potential limitations like data freshness, rate limits, or behavior when parameters are omitted.

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, efficient sentence that front-loads the main purpose. Every word adds value with no redundancy or fluff.

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

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

Given three optional parameters and an output schema, the description covers the core functionality but misses key details like the meaning of 'limit' and the default behavior when tsym is omitted. An output schema exists, so return values are not needed in the description, but parameter completeness is lacking.

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

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

With 0% schema description coverage, the description must clarify parameters. It explains tsym (quote symbol) and page (pagination), but omits 'limit' entirely. The example in the schema shows limit:30, but the description leaves its purpose unclear.

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 returns top cryptocurrencies ranked by market cap using tsym for quote currency and page for pagination. It is reasonably specific but does not explicitly differentiate from siblings like top_pairs or top_volume_full, which are related but distinct rankings.

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

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

The description provides no guidance on when to use this tool versus alternatives. Siblings include many ranking and price tools, but no context is given about scenarios where top_market_cap is preferred.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, which already define the safety profile. The description adds specifics about sorting (24h volume) and pair-level data, but doesn't address side effects beyond what annotations cover.

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?

A single efficient sentence with a list of parameters and a parenthetical platform reference. No redundant repetition.

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?

Output schema is present, two params with one required, sibling context available. The description doesn't need to document return value since the output schema records.

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 no descriptions, with only fsym and limit as param names. The description mentions fsym but not the optional limit parameter, so the agent must infer the limit semantics from the schema type alone.

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

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

Description clearly identifies the tool's purpose: return top trading pairs for a base coin (fsym) sorted by 24h volume on CoinDesk, with exchange and volume data per pair. This differentiates from sibling tools like all_coins or price, though it doesn't explicitly name alternatives.

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

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

The description implies the usage context (by base coin and 24h volume) and distinguishes from coin listing tools, but it does not provide explicit when-to-use/when-not-to-use guidance or alternative tool names.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety traits. It adds value by specifying the 24-hour volume timeframe and pagination behavior, which are not 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 a single, concise sentence that front-loads the main action and key parameters. Every word earns its place with no redundancy.

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

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

Given the presence of an output schema, the description does not need to explain return values. It covers the purpose and two of three parameters, but lacks detail on pagination size or sorting order. Still, it is adequate for a read-only listing tool.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies 'tsym' as a quote symbol and 'page' for pagination, but the 'limit' parameter is left unexplained. This partial coverage leaves a gap.

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 'Return', the resource 'top cryptocurrencies', and the key parameter 'tsym' for quote denomination. It also mentions ranking by 24h total volume and pagination, which distinguishes it from sibling tools like 'top_market_cap' and 'top_pairs'.

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

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

The description implies usage for volume-ranked data but does not explicitly state when to use this tool versus alternatives such as 'top_market_cap' or 'top_pairs'. No exclusions or prerequisites are 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?

The description adds value beyond annotations: it clarifies that the row is deactivated (not deleted) and historical events remain available via recent_alerts. Annotations already indicate non-destructive write behavior (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description enriches this with soft-delete semantics.

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

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

Two sentences: first states the action, second explains ownership and deactivation behavior. Every sentence earns its place with no redundancy. Efficient and front-loaded.

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

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

For a single-parameter tool with no output schema, the description covers the input source (from subscribe), behavioral traits (ownership, deactivation), and points to related tool (recent_alerts). It is complete and leaves no gaps.

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

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

Schema description coverage is 100% for the single parameter 'id,' which is described as 'Subscription id (uuid) returned by subscribe.' The description adds no further meaning beyond confirming the id is used for cancellation, 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 starts with 'Cancel a subscription by id,' clearly stating the verb (cancel/unsubscribe) and resource (subscription). It distinguishes from siblings like 'subscribe' and 'list_subscriptions' by specifying ownership enforcement.

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

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

The description states 'Ownership is enforced — you can only cancel your own subscriptions,' providing clear context on when to use it. It does not explicitly mention alternatives or when not to use, but the condition is well-defined.

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

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

The description goes beyond the readOnly/openWorld annotations by explaining the two processing paths (SEC EDGAR fast path vs grounded pipeline), and it carefully defines edge-case verdicts: could_not_verify is not evidence, unsupported means no source found. It also discloses that the tool performs multiple internal sub-steps, adding behavioral context that annotations alone do not convey.

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

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

The description is fairly long but each sentence serves a purpose: trigger phrases, pipeline explanation, verdict semantics, and a note about replacing multiple calls. It could tighten some repetition (e.g., 'grounded pipeline' wording) but it is well-structured and front-loads the most important usage trigger.

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

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

Since there is no output schema, the description fully enumerates the return verdicts, the actual-value-with-citation, and the reasoning. It also covers error semantics and the source-routing logic, making the tool self-contained for an agent to use without additional documentation.

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 already contains rich, self-sufficient descriptions for both claim and tolerance_pct, including examples and defaults, and schema coverage is 100%. The tool description adds little beyond restating that company financial claims use 'exact percent-delta math', so it does not meaningfully improve parameter 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 identifies the tool as a natural-language claim verification service with specific trigger phrases and a well-defined scope (company-financial vs other factual claims). It distinguishes itself from sibling tools like ask_pipeworx by focusing on verdicts and citations rather than open-ended Q&A, and it states the composite nature (replaces 4–6 sequential calls).

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

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

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct' and gives concrete example phrasings. It also tells the caller about tolerance_pct override for hallucination detection. However, it does not mention when not to use it or point to alternative tools for overlapping tasks, so it's clear but not exhaustive.

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