Greynoise

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

The description adds significant behavioral context beyond the annotations: it explains the default model (free), the need for an API key to access Anthropic (with cost implication), and the return structure (per-model score, confidence, signals, raw_response, plus combined view). This fully aligns with the annotations (readOnly, idempotent, openWorld, not destructive) and provides extra transparency.

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

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

The description is a single paragraph that efficiently conveys purpose, usage, parameters, and returns. It is front-loaded with the main action. While it could be slightly more structured (e.g., bullet points), it is concise and 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?

The description covers the purpose, parameters, return format, and use cases. Since there is no output schema, the description appropriately includes the return structure. It is complete for the tool's complexity, though it could mention error handling or rate limits if applicable.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds extra value by clarifying the default model, explaining when `_apiKey` is needed, and providing examples for the `entity` parameter. 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 probes LLMs for knowledge about an entity and scores visibility 0-100. It specifies the action (probe, score) and resource (LLMs), and differentiates by mentioning specific use cases like AI-marketing audits, brand checks, and competitive monitoring, which are distinct from sibling tools.

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

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

The description provides clear contexts for use: AI-marketing audits, pre-launch brand checks, competitive monitoring. It also explains when to provide the Anthropic API key. However, it does not explicitly state when not to use the tool or mention alternatives among the sibling tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description's job is lighter. It adds valuable behavioral context beyond the annotations: routing across 5,439 tools, argument filling, returning 'structured answer with stable pipeworx:// citation URIs', and performance characteristics like 'one fast call'. No contradiction with annotations found.

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

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

The description is longer than minimal but front-loads the key directive ('PREFER OVER WEB SEARCH') and packs in routing behavior, trigger examples, and alternatives. Some redundancy exists in repeating the web-search preference and default status, but the length is justified for a default entry point that needs to set expectations.

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 compensates by disclosing the return format ('structured answer with stable pipeworx:// citation URIs'). It also covers scope, examples, escalation paths, and tier behavior, making the tool safely invocable without additional lookups.

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 documents all six parameters with 100% description coverage, including the `question` field and its aliases. The description adds no parameter-level details beyond what the schema 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 ask_pipeworx as the default factual-question router: it 'routes the question to the right one of 5,439 tools across 1412 verified sources' and returns structured answers with citations. It also explicitly distinguishes itself from siblings by stating 'START HERE for most questions' and naming ask_pipeworx_grounded and deep_research as escalation paths.

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

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

The description gives explicit when-to-use guidance: 'PREFER OVER WEB SEARCH for questions about current or historical data', lists specific domains, and provides trigger phrases like 'what is', 'look up', and 'get the latest'. It also states 'Step up only when needed' and names exact alternatives for grounded answers and broad research, making the choice 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 goes beyond annotations by disclosing that candidate routing improvements are enabled live only when under test, that no candidate is currently active (last retired on 2026-07-26), and that it currently matches ask_pipeworx exactly. It also addresses the misconception of a fallback by stating 'this IS a full working router.' No contradiction with the readOnly, idempotent, and non-destructive hints.

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

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

The description is four sentences long, each adding valuable information: identity and scope, current beta status, usage instruction, and reassurance about functionality. It is slightly longer than the ideal two-sentence example but remains well-structured and free of filler.

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

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

For a router tool with no output schema, the description covers the response shape by referencing ask_pipeworx's shape. It thoroughly explains the beta state, current inactivity, and usage expectations, and explicitly addresses the fallback concern. This is complete for an agent to invoke correctly.

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

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

The input schema fully documents all six parameters, including 'question' and its aliases with descriptions, so schema coverage is 100%. The description only adds that it uses 'same arguments' as ask_pipeworx, which doesn't provide additional semantic meaning beyond what the schema already offers. Baseline 3 is appropriate.

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

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

The description clearly identifies this as a beta version of ask_pipeworx, acting as an identical universal router with the same 5,439 tools, arguments, and response shape. It explicitly distinguishes it from the stable counterpart by mentioning 'candidate routing improvements' and being the 'experimental edge.' This makes the tool's purpose and scope unmistakable relative to siblings.

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

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

It provides explicit when-to-use guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also explains that results are compared against the stable router, implying the experimental nature. However, it does not explicitly say when not to use it (e.g., for production stability), though this is strongly implied by 'beta' and 'experimental edge.'

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

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

Beyond the readOnly/idempotent annotations, the description discloses refusal reasons, the one-extra-LLM-call cost, and the strict grounding to tool results. It details the exact return shape, including refusal_reason enums, which is valuable context for the agent's decision-making.

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

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

The description is dense yet concise, with three sentences covering purpose, return format, and usage guidance. Every sentence adds critical information without fluff, and the structure front-loads the primary 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?

With no output schema, the description fully explains the return format and refusal behavior. It also covers the routing process, use cases, and cost trade-off, making it complete for an AI agent to invoke correctly in high-stakes scenarios.

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 all parameters (aliases for question) with 100% coverage, so the baseline is 3. The description does not add parameter-specific semantics beyond indicating the tool accepts a natural language question, which is implicit in the tool name.

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: a 'hallucination-resistant answer mode for high-stakes reads' that routes to tools and extracts answers only from tool results. It distinguishes itself from sibling ask_pipeworx by emphasizing grounded extraction and explicit refusal behavior, making it a distinct verb+resource+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?

Explicit guidance is provided: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' and 'prefer ask_pipeworx for casual lookups.' This clearly states when to use this tool versus alternatives, including a cost-based trade-off.

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

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

The description extensively details behavioral traits: low-confidence resolution short-circuits, closed/dead market handling, wide-spread market flags, resolution-rule risk parsing, and fan-out behavior. These go well beyond annotations (readOnlyHint, idempotentHint) and provide critical transparency for safe invocation.

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

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

The description is a single dense paragraph without structural elements like bullet points or sections. While it contains valuable information, it is not concise or easily scannable. Front-loading the main purpose helps, but overall it is verbose.

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

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

Despite no output schema, the description thoroughly explains response shapes, resolver contract, parent_event extractor, news fields, and safety features. It covers edge cases and provides all necessary context for an agent to use the tool correctly. No gaps remain.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by elaborating on the 'market' parameter with examples and clarifying the 'depth' and 'include_raw' parameters with usage guidance. This extra context justifies a 4.

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

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

The description clearly states the tool's purpose: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It lists specific use cases ('should I bet on X', 'what does the data say about Y', 'is there edge in Z') and distinguishes from sibling tools by focusing on comprehensive single-bet research with fan-out to multiple data sources.

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 and examples of when to use the tool. It implies when not to use (e.g., for quick edge checks, other tools might be more appropriate) but does not explicitly name alternatives. The guidance is clear and specific, earning a 4.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds specific behavioral details: pulls from SEC EDGAR/XBRL for companies, FAERS/FDA for drugs, handles fiscal year differences, sorts results, and returns citation URIs. No contradictions.

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

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

The description is a single dense paragraph that front-loads example queries and then provides structural details. While dense, it is efficient and every sentence adds value. Slight lack of formatting 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?

Given the tool's complexity (two entity types, multiple data sources, no output schema), the description adequately explains input parameters, data pulled, sorting, and output includes URIs. It does not detail exact output structure but covers what is needed for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, but the description adds meaningful context: explains how 'type' determines data sources and provides examples for 'values' (tickers for companies, drug names). This helps the agent understand parameter semantics 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 uses specific trigger phrases like 'compare X and Y', 'which is bigger', and explicitly states it provides side-by-side comparison of 2-5 companies or drugs in one call. It clearly distinguishes from sequential lookups and from sibling tools like entity_profile.

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

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

The description explicitly advises to 'ALWAYS PREFER over sequential single-pack lookups' when comparing entities, and provides a list of query types that trigger this tool. It implicitly indicates when not to use (if not comparing multiple entities).

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

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

The description discloses behaviors beyond annotations: account requirement (free tier and paid plan for 'thorough'), expected latency (15-90s), the return format (findings packet with verbatim evidence, citations, gaps[], contradictions[]), and the semantic excerpting of large records. It also states that it 'never invented' answers. Annotations (readOnlyHint, openWorldHint, idempotentHint) are consistent, not contradicted.

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 and front-loaded with the most critical info (account requirement and 'NOT open-web search'). Every sentence adds value, though some technical detail (e.g., 'fetched_at' and 'citation_uri') could potentially be omitted for brevity. Overall, it balances detail with organization.

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 fully covers the tool's complexity: it explains the return format (findings packet with citations, gaps[], contradictions[]), when gaps are expected (breaking news topics not in structured catalog), how depth affects behavior, latency expectations, and prerequisites (account tiers). Since there is no output schema, this narrative is essential and 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?

While the schema already covers both parameters, the description adds substantial meaning: it explains each depth level in detail ('quick=3 (single hop)', 'standard=5 (default; adds a gap-recovery hop... plus contradictions[] scan)', 'thorough=8 (paid; adds a full iterative hop...)'), and clarifies that the question parameter accepts broad/multi-part questions. This enriches the agent's understanding 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's function: 'Grounded multi-source research across Pipeworx's 1412 STRUCTURED data sources' with decomposition into facets and parallel routing to 5,439 tools. It distinguishes itself from open-web search and sibling ask_pipeworx, making its purpose unambiguous.

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

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

Explicit usage guidance is provided: 'If you are not signed in, use ask_pipeworx instead', 'For a single lookup use ask_pipeworx', and 'For BREAKING or colloquial CURRENT-NEWS ... prefer ask_pipeworx'. It also gives example use cases and explains depth options, making it clear when to choose this tool over 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 readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by explaining that results are 'ready to call directly' and include full schemas with examples, which is useful behavioral context beyond the annotations.

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

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

The description is front-loaded with the core purpose and packed with specific domain examples, but is slightly verbose. Every sentence adds value, however it could be tightened slightly without losing information.

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

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

Despite having no output schema, the description fully explains what the tool returns (top-N most relevant tools with names, descriptions, full input schemas). Combined with clear usage guidance and parameter semantics, the description is completely informative for an AI agent.

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

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

Schema coverage is 100% and each parameter is described, but the description adds value by explaining that multiple aliases (q, task, search, description) all map to the same query parameter and provides concrete example queries.

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-noun pair ('Find tools by describing the data or task') and enumerates numerous example domains, distinguishing this from sibling tools which are more specific search or analysis tools.

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

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

Explicitly states 'Call this FIRST when you have many tools available and want to see the option set (not just one answer),' providing clear when-to-use guidance and context relative to other tools.

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

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

The description discloses behavioral traits beyond annotations, such as the patent data source with a known sunset date ('soft-fails until reactivated'), the use of GDELT→GNews fallback, and the sorting of fundamentals. It also confirms read-only behavior, aligning with annotations but adding context about data freshness and failure modes.

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

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

The description is a single, dense paragraph that efficiently conveys key information, examples, and preferences. While it is not overly long, it could benefit from breaks or bullet points for readability. However, every sentence adds value, so it remains fairly concise.

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

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

Without an output schema, the description provides a good overview of the returned data (e.g., 'up to 5' filings, 'LATEST 10-K' fundamentals, fallback behavior). It does not specify the exact output format (e.g., JSON structure), but the examples of pipeworx URIs and patent status are sufficient for an agent to understand the tool's capabilities.

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

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

Schema coverage is 100%, so the schema already documents the 'type' and 'value' parameters. The description adds practical examples ('AAPL', '0000320193') and reinforces that names are not supported, which adds value beyond the schema's basic 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 explicitly states the tool returns a 'full cross-source profile of a US public company in ONE parallel call' and lists the specific data components (CIK, filings, fundamentals, patents, news, LEI). It distinguishes itself from siblings like 'compare_entities' and 'resolve_entity' by focusing on holistic company profiles.

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

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

The description clearly advises to 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also explicitly states that names are not supported and directs users to 'use resolve_entity first if you only have a name,' providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already mark destructiveHint true. Description adds context about clearing sensitive data and pairing with other tools, which is consistent and adds value.

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

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

Two sentences, front-loaded with action. 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?

Simple tool with one required parameter and no output schema. Description covers purpose, usage, and paired tools adequately.

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. Description adds no additional semantics beyond the schema's parameter 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?

Clearly states 'Delete a previously stored memory by key', using specific verb and resource. Distinguishes from siblings remember and recall.

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

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

Explicitly provides when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also pairs with remember and recall as 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, destructiveHint. The description adds that it fetches the page, extracts title/description/key links, and emits standard markdown. This is useful context beyond annotations, though edge cases like invalid URLs are not covered.

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

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

The description is three sentences, front-loaded with purpose, and each sentence adds value. No wasted words or repetition. It efficiently conveys what the tool does, how it works, and when to use 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?

No output schema exists, but the description explains output as a 'single text blob ready to drop at site-root/llms.txt'. It covers input parameters, process, and use cases. The missing details on error handling or format spec are minor given the tool's simplicity.

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 described. The description does not add new meaning beyond implying that max_links limits extracted entries. Baseline 3 is appropriate as the schema already handles semantics.

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

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

The description clearly states the tool generates a production-ready llms.txt file for any URL, specifying the verb 'generate' and the resource 'llms.txt file'. It differentiates from siblings like scan_competitor_ai_presence by focusing on standard format output.

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: getting client's site indexed, drafting for own project, auditing competitor. It does not mention when not to use it, but the three use cases give clear guidance. Exclusion of alternatives is not needed given the unique purpose.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive. The description adds value by specifying the data source (GreyNoise Community), authentication requirement (BYO API key), and return fields including a deep link. 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 action, second lists return fields. Front-loaded and efficient. 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 simple classification tool with an output schema, the description covers the key aspects: input, data source, authentication, and output fields. It is sufficiently 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?

Only one parameter 'ip' with schema description 'IPv4 address'. Description does not significantly add beyond schema; baseline score is appropriate given 100% schema coverage.

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

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

The description clearly states it classifies an IPv4 address using the GreyNoise Community dataset and lists return fields. It distinguishes from sibling tools which focus on entities, research, or subscriptions.

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

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

The description mentions 'BYO API key' as a prerequisite but does not explicitly state when to use vs. alternatives. However, the purpose is clear enough that an agent would recognize it for IP reputation classification.

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, non-destructive. Description adds return field details and context, building on 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?

Two efficient sentences with no extraneous content; first states function, second provides usage guidance.

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

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

For a simple tool with one optional parameter and annotations covering safety, the description fully explains purpose, output, and use case.

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

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

Schema coverage is 100% with a clear parameter description. Description does not add additional semantics beyond what the schema provides, so baseline score.

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

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

Clearly states the tool lists active subscriptions and specifies return fields. Distinguishes from sibling tools like subscribe and unsubscribe.

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

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

Provides explicit usage guidance: review before subscribing or to get a cancellation ID. Does not explicitly state when not to use, 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 are all false (no hints), so the description bears full responsibility. It discloses rate limits ('Rate-limited to 5 per identifier per day'), quota behavior ('Free; doesn't count against your tool-call quota'), and team-read frequency ('digests daily'). It also instructs users not to paste end-user prompts, adding behavioral guardrails.

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

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

The description is longer than average but every sentence earns its place: purpose, usage criteria, exclusions, content guidelines, and operational details. It is front-loaded with the main action and uses clear labeling ('ONLY for tools served by this Pipeworx connection').

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 tool sends feedback and produces no meaningful output schema, so the description must cover purpose, usage, policy, and exclusions — it does all of this comprehensively. It also explains the relationship to sibling tools by clarifying which tools are in scope for feedback.

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 parameters with descriptions, so baseline is 3. The description adds value by explaining how to frame the message ('Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt') and by clarifying type semantics beyond enum labels (e.g., 'bug = something broke or returned wrong data'). This elevates 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 opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly describes the tool as a feedback mechanism and distinguishes it from sibling tools that perform queries, research, or memory operations.

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

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

The description explicitly states when to use the tool ('Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise)') and provides a clear exclusion: if the tool came from a different MCP server, file it with that server instead.

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

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

Annotations already indicate read-only, open-world, and idempotent properties. The description adds caching behavior (5min-1h), data source (CF analytics-engine), and privacy (no PII), providing valuable 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?

Three sentences, efficiently structured with bullet-like list for use cases. Every sentence adds value; 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 simple tool with one parameter and no output schema, the description covers purpose, usage, data source, caching, and privacy. The return is described generically but adequately. Minor improvement could be exact output structure.

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

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

Schema coverage is 100% with a single enum parameter. The schema already explains the window options well. The description adds slightly more context about when to use each window, justifying a score above baseline.

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

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

The description clearly states the tool returns top tools, packs, and call volume over a window. It distinguishes itself from sibling tools by focusing on aggregated trending data, not individual queries or entity profiles.

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

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

Three explicit use cases are given: discovering hot data sources, confirming canonical tools, and aligning use case with agent needs. It lacks explicit when-not-to-use directions but the context is clear and helpful for selection.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description adds significant behavioral details: semantic anchor with Jaccard similarity, partition filter for placeholder slugs, fill check against live CLOB depth, and a warning not to trade when realizable_edge_pp ≤ 0. 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 thorough and front-loaded with the core purpose. However, it is somewhat verbose with many technical details (e.g., Jaccard threshold, placeholder fraction). It could be slightly more concise while retaining 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?

The description provides a summary of the response structure for both modes, including fields like gap_pp, suggested_trade, reasoning, and partition_check details. It also mentions fill check behavior. Without an output schema, this is fairly complete, though it could describe error conditions or edge cases more thoroughly.

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

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

Input schema covers 100% of parameters with descriptions. The description adds substantial meaning: it explains the modes corresponding to each parameter, provides example values, and clarifies that no args triggers trending_scan. This goes well 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 finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It explains two distinct modes (event and topic) with specific use cases, providing a clear verb-resource pair.

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 when to call with no arguments (trending_scan), when to use event (specific market), and when to use topic (cross-event scanning). It recommends event for specific markets and suggests an alternative tool (polymarket_fill_risk) for custom sizing, providing clear guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds extensive behavioral context: model families (crypto_price, news_momentum, partition_overround, concentrated_longshot), edge calculation details, slippage assumptions, caching (1h at KV level), and diagnostic fields. No contradiction with annotations.

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

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

The description is very dense and technical, covering model formulas and caching details. It is well-structured with sections (by_segment, tradeable-edge knobs, response top-level) and front-loaded with the core purpose. However, it could be more concise for an AI agent.

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

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

Given the complexity (9 parameters, no output schema, nested response structure), the description is extremely complete. It explains the response format (by_segment, fed_candidates, diagnostics), tradeable-edge knobs, and caching. Without an output schema, the description fully compensates by detailing return values.

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

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

Schema coverage is 100%, but the description enriches every parameter with usage context. For example, slippage_pp explains Polymarket's fee structure, min_liquidity explains the rationale for filtering, and category_filter lists valid values. This goes beyond what the schema provides.

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

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

The description clearly states the tool scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It uses specific verbs ('Scan top Polymarket markets and return opportunities') and identifies the resource (Polymarket markets). The detailed explanation of the three segments distinguishes it from sibling tools like polymarket_arbitrage or polymarket_edge_tracker.

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 frames the tool for 'what should I bet on today' and explains the three segments with their purposes. It advises that Fed bets are excluded from ranking due to unreliable signal and mentions caching. However, it does not explicitly state when not to use this tool or how it compares to sibling tools like polymarket_arbitrage.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive. Description adds behavioral nuances: snapshot TTL (60-day), decay from daily closes (not intraday), gaps meaning no scan that day. 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?

Description is lengthy with technical details but structured clearly with sections (args, RESPONSE, LIMITS). However, it could be more concise; some sentences are dense and require careful 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?

No output schema, but description thoroughly explains the return fields (tracked[], expired[], snapshot_dates[]) with key attributes and semantics, making the tool's response predictable.

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

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

Schema covers 100% of parameters with descriptions. Description only reiterates defaults and max days without adding 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?

Description clearly states the tool provides 'edge persistence and decay telemetry' and answers a specific question about edge age and shrinkage. It distinguishes itself from sibling polymarket_edges by focusing on temporal analysis 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?

Implies usage for judging trade quality based on edge persistence (fresh vs. old wide edge) but lacks explicit when-to-use or when-not-to-use instructions. No direct mention of alternatives like polymarket_edges for current snapshots.

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, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: 'walks the ladder', returns specific fields like slippage_pp, verdict, thin_legs, and warns about 'forced_directional_risk'. Since annotations cover the basics (read-only, non-destructive, state-dependent), the description provides supplementary detail 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 front-loaded with the core purpose and uses capitalized section headers (REQUIRES, SINGLE-MARKET, BASKET) to organize. However, it is verbose with run-on sentences (e.g., the last sentence) and could be tightened. Some details like parameter defaults could be left to schema, but overall structure is clear.

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

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

Despite no output schema, the description lists all return fields for both single-market (top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict) and basket (theoretical_sum, realizable_sum, capture_ratio, profit_usd, per-leg fill detail, thin_legs, max_clean_notional_usd, forced_directional_risk). It also explains risks and provides usage thresholds. This is highly complete for agent decision-making.

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

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

Schema coverage is 100% with descriptions for all four parameters. The description adds meaning by explaining modes: market for single-market, event for basket, and how side defaults to 'auto' based on partition sum for basket. It interprets size_usd differently for single-market (max spend/target proceeds) vs basket (settlement notional). This goes beyond schema to clarify parameter behavior in context.

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

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

The description clearly states the tool performs a 'realizable-vs-theoretical edge check against live CLOB order-book depth' with specific modes (single-market vs basket) and parameters (market/event, side, size_usd). It distinguishes itself from siblings by advising use before acting on signals from polymarket_arbitrage or polymarket_edges. The verb 'check' combined with the resource 'fill risk' is specific and unambiguous.

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

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

The description explicitly states 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It explains the rationale: theoretical overround on thin books is not capturable and partial basket fills convert an arb into an unhedged directional position. This provides clear when-to-use and why, with implicit alternatives from sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds rich behavioral context: two failure modes for compatibility_warning, temporal alignment field, skipped cross types/subtypes, and the rarity of real spreads. This goes well beyond annotations.

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

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

The description is well-structured with sections for overview, modes, response structure, and safety fields. It is front-loaded with purpose. However, it is slightly verbose; could be trimmed without losing information.

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

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

Despite lacking an output schema, the description thoroughly details response fields (per-venue prices, matched spread, compatibility_warning conditions, temporal_alignment, skipped counters). Given the tool's complexity and the absence of output schema, this is very complete.

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

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

Schema coverage is 100% (all 3 parameters described). The description adds meaning by explaining the two modes (topic vs explicit), listing valid topic values, and specifying that explicit ticker/slug override the topic side. This 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 the tool computes cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes two modes (pre-mapped topic shortcuts vs explicit ticker/slug) and mentions when bet shapes are equivalent or not. This specificity differentiates it from sibling tools like polymarket_arbitrage.

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

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

The description explicitly tells when to use the tool (to find spread opportunities) and when not (when compatibility_warning fires, e.g., non-equivalent bet shapes or semantically unrelated events). It also warns that most pre-mapped topics return warnings, setting proper expectations.

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, idempotentHint=true, destructiveHint=false. The description adds context beyond annotations, such as scoping to an identifier and listing behavior when 'key' is omitted. No contradictions.

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

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

The description is three sentences, front-loaded with the core function. Every sentence adds value, and there is no unnecessary information.

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

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

For a simple retrieval tool with no output schema, the description covers purpose, usage, scoping, and interaction with sibling tools. It is thorough and leaves no major gaps.

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

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

Schema coverage is 100% with a single optional 'key' parameter described. The description reinforces the schema ('omitting key lists all keys') and adds examples of potential key values, but does not significantly add new semantic meaning beyond the schema.

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

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

The description clearly states that 'recall' retrieves a value saved via 'remember' or lists all keys if 'key' is omitted. It provides concrete examples of what can be stored (target ticker, address, research notes) and distinguishes itself from sibling tools 'remember' and 'forget' by describing their relationship.

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

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

The description explains when to use the tool: to look up previously stored context without re-deriving it. It also mentions scoping to an identifier and pairing with 'remember' and 'forget'. While it doesn't explicitly state when not to use it, the guidance is clear enough for a simple retrieval 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?

The description mentions that mark_read:true flags events as read, which implies a state modification. The annotations declare readOnlyHint=true, creating a contradiction. The description's transparency is undermined by this inconsistency.

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

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

The description is three sentences long, front-loaded with the purpose, and covers all key aspects without extraneous words. Every sentence adds value.

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

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

Despite no output schema, the description details return fields and optional behaviors (filtering, mark_read). It also notes polling suitability and an alternative access method, making it complete for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing an example for type ('sec_8k'), clarifying since as ISO timestamp, and explaining the effect of mark_read. 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 it retrieves recent alerts from the subscription feed, specifying the returned fields (source, citation_uri, payload). It distinguishes itself from siblings like list_subscriptions by focusing on events rather than subscriptions.

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

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

The description says 'Polls work fine' and provides an alternative URL for scripts/dashboards, giving context for usage. However, it does not explicitly state when not to use this tool or compare it to 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 readOnly, idempotent, openWorld. The description adds significant behavioral context: parallel fan-out to SEC EDGAR, GDELT/GNews fallback, USPTO soft-fail, and return structure (changes grouped by source, total_changes, citation URIs).

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 well-structured with front-loaded examples and clear sections. It is slightly verbose but every sentence adds value, neither overly terse nor rambling.

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 (multiple data sources, fallback, soft-fail) and no output schema, the description covers all necessary aspects: input formats, behavior, output structure, and alternative tools. No gaps remain.

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%, meeting baseline of 3. Description adds value with detailed explanation of `since` format including examples and recommended values, and clarifies `type` is limited to 'company'. This guidance surpasses schema alone.

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

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

The description states the tool fetches recent changes (filings, news, patents) for a company within a time window. It differentiates from sibling entity_profile by specifying that tool provides static profiles regardless of time window.

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 example queries like 'What's new with X' and explicitly advises use of entity_profile for static profiles, providing clear when-to-use and when-not-to-use guidance.

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

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

The description adds value beyond annotations: it explains scoping ('by your identifier'), authentication-dependent persistence ('Authenticated users get persistent memory; anonymous sessions retain memory for 24 hours'), and the nature of storage (key-value pair). Annotations already indicate idempotentHint=true and destructiveHint=false, and the description aligns with those.

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 (5 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, usage criterion, storage details, persistence info, and pairing with siblings. No fluff.

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

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

Given the tool's simplicity (two simple parameters, no output schema), the description is complete. It covers purpose, when to use, parameter semantics (though schema covers them), behavioral nuances (scoping, persistence), and relationships to sibling tools.

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

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

The input schema covers both parameters with descriptions, so baseline is 3. The tool description does not add significant new parameter semantics beyond examples in parentheses. The schema descriptions are already clear, so no deduction or bonus.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later.' It specifies the action (save), the resource (data), and the scope (across conversations/sessions). It also distinguishes from sibling tools like 'recall' and 'forget' by mentioning them.

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

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

The description provides explicit usage guidance: 'Use when you discover something worth carrying forward.' It also tells when not to use other tools by suggesting alternatives: 'Pair with recall to retrieve later, forget to delete.' Additionally, it explains persistence behavior for authenticated vs. anonymous users.

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=false. The description adds valuable context that each call cascades through several lookup endpoints internally, replacing 2-3 manual lookups, without contradicting annotations. No mention of rate limits or auth, but annotations cover the safety profile.

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

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

The description is front-loaded with clear examples and imperative language. At around 150 words, every sentence serves a purpose: examples, usage guideline, supported types with return details. No redundant or vague statements.

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 thoroughly covers return formats for both entity types. It also explains internal cascading for transparency. For a tool with only 2 simple parameters, this provides complete context for correct 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 coverage is 100%, so baseline is 3. The description adds significant meaning: it explains the return format for both types (company returns ticker+CIK+name+citation URI; drug returns RxCUI+ingredient+brand+citation) and clarifies that company accepts ticker, CIK, or name. This goes beyond the schema's enum and type 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 explicitly states the tool resolves a name to a canonical identifier, provides concrete examples like 'What's the ticker for...', and distinguishes it from sibling tools by noting it replaces 2-3 manual lookups. The verb 'resolve' and resource 'entity' are specific and clear.

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 advises 'Use FIRST whenever you have a name but need an ID,' which is a strong usage guideline. However, it does not explicitly mention when not to use this tool or suggest direct alternatives among the many sibling tools, though the context of needing an ID is well covered.

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 as false. The description adds valuable behavioral context: it probes each entity, ranks by score, and surfaces which is most/least recognized. It also describes the return format (score, confidence, signal density). No contradictions.

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

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

The description is four sentences long, each providing essential information. It is front-loaded with the main purpose and uses clear, direct language with 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?

Given no output schema, the description compensates by explaining the return format (ranked list, score, confidence, signal density). It also ties to sibling ai_visibility_check, gives input semantics, and provides a concrete example. The tool feels complete for its intended use.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds extra meaning for the entities parameter, specifying that the first entry is treated as the 'subject' for narrative. This goes beyond the basic schema description.

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

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

The description clearly states the verb 'compare' and the resource 'AI visibility across multiple entities', with a concrete example. It distinguishes itself from sibling tools like ai_visibility_check by explicitly noting it aggregates multiple probes and provides a ranked comparison.

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

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

The description gives a clear use case ('competitive AI-marketing audits') and an example question. However, it does not explicitly say when not to use this tool or mention alternatives like compare_entities or 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?

The description goes beyond annotations by detailing partial failure modes ('bundlephobia's first measurement on a new version can take 5-30s; sources_failed will list it if it times out') and the output structure (summary block, per-advisory detail, links). It aligns with the readOnlyHint, idempotentHint, and destructiveHint 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 concise at roughly 5 sentences, with the main purpose front-loaded. Every sentence provides essential information, and the structure is clear 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?

Despite lacking an output schema, the description fully compensates by enumerating the return fields and explaining partial failure behavior. It covers all necessary context for an agent to understand the tool's capabilities and limitations.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds value by noting that scoped packages are accepted for 'package' and that 'version' defaults to latest. This extra context justifies a score above the baseline 3.

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

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

The description explicitly states it's a composite check for evaluating npm packages, covering safety, size, and licensing. It specifies the verb ('scan'), resource ('dependency'), and scope ('npm'), clearly distinguishing it from sibling tools which are unrelated to package scanning.

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

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

The description provides explicit usage conditions: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me".' It also clarifies limitations ('NPM ecosystem only in v1') and points to alternatives for other ecosystems ('PyPI / Maven / Cargo / Go fall under deps.dev:version directly'), giving comprehensive guidance.

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

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

Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds technical details: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char limit with truncation flag, and that results include character offsets and similarity scores. This is valuable beyond annotations, though a perfect score would require more on idempotency guarantee.

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

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

The description is moderately long but each sentence is purposeful: purpose, use case, technical details, pairing. It is front-loaded with the primary action. Minor redundancy (e.g., 'P pairs with' could be more concise), but overall efficient.

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

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

No output schema, but the description explains returns: top-N passages with character offsets and similarity scores. Covers input limits, embedding details, window size, truncation behavior, and pairing with another tool. Fully addresses what an agent needs to know to use and interpret results.

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

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

All three parameters have schema descriptions (100% coverage). The description enriches with examples for query ('supply-chain risk', etc.), default behavior for limit (1-20, default 5), and context for text (max ~200K chars). This goes beyond the schema but doesn't add critical missing info.

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', using a specific verb (search) and resource (record). It distinguishes from siblings by specifying it works inside a fetched document, contrasting with 'ask_pipeworx_grounded' which is mentioned as a paired tool for grounding over passages.

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

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

Explicitly advises using when the record is too big for the prompt, emphasizing context savings. Mentions pairing with 'ask_pipeworx_grounded' for grounded reasoning, providing clear when-to-use and alternatives.

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

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

The description adds behavioral context beyond annotations: returns new subscription ID, requires OAuth, details delivery channels with constraints (SMS cap, webhook auto-disable). It aligns with annotations (idempotent, non-destructive) 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 concise, well-structured with clear front-loading of purpose. Each sentence adds necessary details without redundancy, using bullet-like formatting for readability.

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

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

Given no output schema, the description adequately covers return value ('returns the new subscription id'), input parameters, delivery options, and constraints. Could mention how to use the returned ID later (e.g., for unsubscribe), but overall complete.

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

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

Schema coverage is 100%, but the description enhances understanding with concrete examples and constraints (e.g., phone verification, 10/day SMS cap, webhook signing). This adds value beyond the schema alone.

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

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

The description clearly states the tool's purpose: 'Create a proactive monitoring subscription to a live-data event stream' with specific verb-resource combination. It distinguishes from siblings like list_subscriptions, unsubscribe, and recent_alerts.

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

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

The description specifies when to use (proactive monitoring), includes prerequisites ('Requires a Pipeworx OAuth account'), and provides examples of supported types. It implies when not to use (anonymous accounts) but doesn't explicitly name alternatives like list_subscriptions for managing existing subscriptions.

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 valuable behavioral context beyond the annotations: it returns example questions with exact tool usage, drawn from the live catalog. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false, and the description aligns with these.

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

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

The description is relatively long but well-structured and front-loaded with example queries. Each sentence provides useful information, though it could be slightly more concise without losing detail.

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 single optional parameter and no output schema, the description fully explains what the tool returns and when to use it. It covers all necessary context for an onboarding 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?

There is only one optional parameter (topic) with 100% schema coverage. The description adds nuance by listing example topics and clarifying that omitting the argument gives a cross-category spread, adding 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's purpose: it returns category-bucketed example questions with the exact tool and argument shapes. It explicitly distinguishes itself as the onboarding entry point for an agent that just connected, differentiating from sibling tools like ask_pipeworx.

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

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

The description provides explicit guidance: 'Use this FIRST when you do not yet know what Pipeworx can do for you.' It also explains when to call with no arguments versus passing a topic, and how it helps learn meta-tools.

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

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

Discloses ownership enforcement and deactivation behavior, adding significant context beyond annotations. Annotations already indicate idempotent and non-destructive; description reinforces and explains the non-destructive nature.

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

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

Two sentences, no redundant information. Every sentence adds value: core action, ownership, side effect. Excellent 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 one-parameter tool with no output schema, the description fully covers the operation's purpose, constraints, and post-condition. References to 'recent_alerts' provide integration context.

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

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

Schema coverage is 100% and the parameter is well-described in the schema. Description merely references 'by id' without adding additional semantic value or constraints beyond what the schema provides.

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

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

Description clearly states 'Cancel a subscription by id' with specific verb and resource. It distinguishes from siblings like 'subscribe' and 'recent_alerts' by noting deactivation versus deletion and historical event availability.

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 context: ownership enforcement (only own subscriptions) and side effect (deactivation, not deletion). Implicitly tells when to use but does not explicitly state alternatives or when not to use.

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

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

The description adds detailed behavioral context beyond the annotations, such as the exact percent-delta math for financial claims, the automatic fallback to a grounded pipeline for other claims, and the verdict types returned. There is no contradiction with the annotations, which indicate read-only, idempotent, and non-destructive behavior.

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

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

The description is a single, well-structured paragraph that efficiently conveys the tool's purpose, behavior, and return values. It lists examples upfront, then explains the two pipelines, and ends with output details. While comprehensive, it is not overly verbose, though slight trimming could improve conciseness.

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

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

Given the tool's complexity (two distinct verification pathways, multiple verdict types, and citation format) and the absence of an output schema, the description fully covers what the agent needs to know. It explains the return values (verdict, actual value with citation, reasoning) and the fallback logic, making it complete for effective tool 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 coverage is 100%, so the description's role is supplementary. It adds value by explaining the default behavior of tolerance_pct, including its override purpose for hallucination detection, and clarifies that the claim parameter is a natural-language factual claim. This goes beyond the schema descriptions without being redundant.

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 natural-language examples clearly indicating the tool's purpose for fact-checking claims. It explicitly distinguishes between company-financial claims (handled via SEC EDGAR + XBRL) and any other factual claim (routed to a grounded pipeline), making it highly specific and differentiable from sibling tools.

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

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

The description states 'Use whenever the agent needs to check whether something a user said is factually correct.' It explains the two pathways and notes that the tool replaces multiple sequential calls. While it does not explicitly list when not to use it or mention alternatives beyond the sibling list, the guidance is clear and contextually sufficient.

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