Regrid

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

The description goes beyond annotations (readOnlyHint, idempotentHint, destructiveHint) by explaining the cost implications (free default, BYO key for Anthropic) and the output structure (per-model score, confidence, signals, raw_response + combined view). No contradictions with annotations.

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

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

The description is concise (5 sentences) and well-structured, front-loading the main action and output, then detailing parameters and use cases. No unnecessary words.

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

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

Despite lacking an output schema, the description adequately explains the return format (per-model score, confidence, signals, raw_response + combined view). It covers all parameters, usage scenarios, and behavioral notes, making it complete for the tool's complexity.

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

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

The input schema already has 100% description coverage, but the tool description adds valuable context: the default model is free, _apiKey is passed straight through, and context helps disambiguate. This enriches understanding beyond the schema.

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

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

The description clearly states the tool's purpose: probing LLMs for what they know about an entity and scoring visibility (0-100) per model. It specifies the default model and the option to add Anthropic, and distinguishes itself from siblings by focusing on AI-marketing audits and brand checks.

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 guidance on when to use the tool (pre-launch brand checks, competitive monitoring) and how to configure it (default model, _apiKey for Anthropic). However, it does not explicitly state when not to use it or provide alternatives among 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?

Adds substantial behavioral context beyond the annotations: routing mechanism, argument filling, stable citation URIs, 'one fast call', works on every tier, and that it remains the right choice even when web search could answer. The read-only/open-world annotations align with the description, and the description enriches them with concrete operational details.

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

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

Front-loaded with 'PREFER OVER WEB SEARCH' and structured with clear sections (domains, triggers, examples, alternatives). While longer than minimal, every part serves a purpose for a default entry-point tool, and the use of markers like 'START HERE' and 'Step up only when needed' makes it easy to scan.

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

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

Given the tool has no output schema, the description properly explains the return format (structured answer with citations). It covers the full decision space: when to use, when to step up to alternatives, example domains, and limitations (breaking news is covered), making it fully actionable 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%, with the question parameter and its aliases fully documented in the schema. The description adds value by specifying the types of questions it handles (factual, real-world) and giving examples, which helps craft effective queries, though the core parameter meaning is already present.

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 role: it routes factual questions to one of 5,501 tools across 1,441 verified sources, fills arguments, and returns structured answers with citation URIs. It explicitly distinguishes itself from siblings by framing itself as the default entry point and comparing to ask_pipeworx_grounded and deep_research.

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

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

The description gives explicit when-to-use guidance with trigger phrases and example questions, and provides step-up alternatives: ask_pipeworx_grounded for hallucination-resistant single answers, deep_research for broad/multi-part questions. It also clarifies that breaking news is already handled, leaving no ambiguity about when to choose this tool.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context beyond annotations: it explains that this is a full working router with no fallback, that candidate routing improvements are enabled live when under test, and that currently no candidate is active so it matches ask_pipeworx exactly. This conveys the experimental nature and current operational state, which annotations cannot capture.

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 but comprehensive, covering identity, equivalence, current state, usage, and fallback behavior in four sentences. It is front-loaded with the key fact (beta version of ask_pipeworx) and each sentence contributes useful information. Slightly verbose in the last sentence but not wasteful.

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

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

Given the absence of an output schema, the description compensates by stating the response shape is identical to ask_pipeworx, which provides sufficient context for an agent familiar with the stable tool. It also addresses the experimental edge, current candidate status, and comparison logic. The description is complete for a tool that is essentially a variant of a known sibling.

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

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

Schema description coverage is 100%, with all parameters documented as aliases for 'question.' The description does not add any parameter-specific information, but the schema is already complete and self-explanatory. The baseline of 3 applies because the schema does the heavy lifting, and the description adds no additional meaning beyond what's in the schema.

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

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

The description clearly identifies this as a beta version of ask_pipeworx, a universal router, and explicitly states it shares the same 5,501 tools, arguments, and response shape. It distinguishes itself from the stable ask_pipeworx and related siblings by emphasizing the experimental routing edge, making the tool's purpose unambiguous.

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

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

It provides clear when-to-use guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also explains the current inactive state and that results are compared to the stable router for merge decisions. While it doesn't explicitly list when not to use it, the beta/experimental framing implies a trade-off, and the alternative (ask_pipeworx) is evident from the sibling context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description goes further by revealing the extraction-only behavior, structured output with evidence, and the explicit refusal mechanism with specific reasons like not_in_source, no_tool_match, tool_error, data_truncated, llm_error. This provides deep behavioral insight beyond the annotations.

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

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

The description is moderately long but every sentence earns its place. It is front-loaded with the core purpose ('Hallucination-resistant answer mode'), then details process, return format, usage, and trade-off. The refusal reason list is detailed but useful; 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?

Even without an output schema, the description fully explains return values and error handling. It covers when to use, when not to use, cost implications, and the relationship to sibling ask_pipeworx. Given the tool's complexity and high-stakes nature, the description is complete and self-sufficient.

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

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

Schema description coverage is 100%, with the question property and aliases fully documented. The description adds no additional parameter-specific semantics, but the schema already carries the full load, so a baseline score of 3 is appropriate.

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

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

The description clearly states it is a 'Hallucination-resistant answer mode for high-stakes reads' and explains the process: same routing as ask_pipeworx, fetches data, then extracts the answer using ONLY the tool result. It also distinguishes itself by detailing the structured response with evidence and refusal reasons, making it specific and differentiated from siblings.

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

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

Explicit use-cases are given: 'Use whenever an answer will be quoted, cited, or acted on' and examples like financial verdicts, legal claims, medical lookups. It also tells when NOT to use it: 'prefer ask_pipeworx for casual lookups' and notes the cost trade-off of one extra LLM call, naming the alternative sibling function.

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 discloses behavior beyond annotations: parallel fan-out, resolver contract with confidence levels, parent event extraction, news fallback mechanisms, safety short-circuits for low-confidence and closed markets, spread warnings, and resolution-rule risk. All of this adds value beyond the readOnlyHint, openWorldHint, idempotentHint, and destructiveHint 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 long and detailed, covering many edge cases and examples. While every sentence provides useful information, the length may hinder quick comprehension. It is front-loaded with purpose but becomes dense with classifier lists and fan-out examples.

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 (3 params, no output schema), the description is exceptionally complete. It covers all return shapes (market, analysis, evidence), resolver contract details, parent event extractor, news fields, safety mechanisms, and resolution rules. No output schema is needed because the description thoroughly documents the response.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal new meaning beyond what the schema already provides for each parameter (e.g., it restates accepted formats for 'market' and default for 'depth'). It does not introduce nuances not already in the schema.

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

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

The description clearly states it researches Polymarket bets by pulling Pipeworx data. It specifies the verb 'research' and resource 'Polymarket bet', and distinguishes itself from siblings like 'ask_pipeworx' or 'polymarket_edges' by focusing on bet-specific evidence gathering. The use cases are explicit.

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

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

The description explicitly says 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"', providing clear when-to-use guidance. However, it does not contrast with sibling tools like 'polymarket_arbitrage' or 'polymarket_edge_tracker' to indicate when not to use this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context: it specifies what data is retrieved (revenue, net income, etc. for companies; adverse-event counts for drugs), confirms correct handling of off-calendar fiscal years, and notes that results are sorted by primary metric. 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 informative but somewhat verbose. It effectively front-loads the purpose with examples and uses bold for emphasis. However, it could be trimmed slightly by removing redundant phrases like 'in ONE parallel call'. Still, it earns its length given the tool's complexity.

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

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

No output schema is provided, but the description mentions paired data and citation URIs per entity, which gives a basic idea of the return structure. It also notes sorted results. While not fully detailed, this is sufficient for understanding the tool's functionality, especially with rich annotations.

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

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

Schema coverage is 100% with descriptions for both parameters, but the description enhances understanding by elaborating on the enum values for 'type' (specific data pulled per type) and providing examples and constraints for 'values' (tickers/CIKs vs. names, min/max items). This adds significant meaning 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 defines the tool's purpose: side-by-side comparison of 2-5 companies or drugs. It provides specific natural language triggers ('Compare X and Y', 'which is bigger') and details the data sources for each type (SEC EDGAR/XBRL for companies, FAERS for drugs). This distinguishes it from sibling tools like 'entity_profile' or 'resolve_entity'.

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

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

The description explicitly states 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', providing clear guidance on when to use this tool versus alternatives. It also implies the alternative (sequential lookups) and includes concrete examples of queries that trigger its use.

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

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

Annotations declare readOnly/openWorld/idempotent/non-destructive, and the description goes far beyond by disclosing account requirements, time expectations (15-60s, thorough up to ~90s), behavior for unanswered facets (gaps[]), contradiction scans, citation resolvability, and semantic excerpting. No contradiction with annotations.

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

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

The description is long but every sentence carries critical information for a complex tool. It front-loads the account requirement, then systematically covers purpose, alternatives, output expectations, and limitations. The structure is dense yet logically ordered.

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, the description fully covers prerequisites, use-cases, limitations, runtime, output details, and fallback alternatives. The absence of an output schema is compensated by a thorough explanation of the findings packet, gaps[], contradictions[], and citation_uri. It is complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, but the description adds meaning by explaining the depth parameter in terms of facets, hops, and paid plan, and by clarifying that 'question' accepts broad natural language. This enriches 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 names a specific verb and resource ('Grounded multi-source research across Pipeworx's 1441 STRUCTURED data sources') and clearly differentiates from siblings like ask_pipeworx ('this is NOT open-web search', 'For a single lookup use ask_pipeworx'). It explains what the tool does step-by-step and its output format.

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: 'Best for broad/multi-part questions over structured data' and 'For a single lookup use ask_pipeworx', plus 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'. It also specifies the paid tier requirement, which is essential for when-to-use decisions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral details: returns top-N most relevant tools with full schemas and curated examples, and each result is ready to call directly—no second lookup needed. No contradiction.

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

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

The description is slightly verbose but well-structured: purpose first, then when-to-use, then returns summary. Every sentence adds value, but could be tightened slightly.

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

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

Given the tool's discovery role, the description fully covers what it does, what it returns, and how to use it. No output schema is needed because the description explains the return content.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by noting multiple aliases for query (task, q, search, description) and providing example inputs, which helps the agent use the parameters correctly.

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 core purpose: 'Find tools by describing the data or task.' It distinguishes itself from sibling tools by being the only discover/browse tool, and it lists specific domains (SEC filings, FDA drugs, etc.) that reinforce its purpose.

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

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

Explicit guidance: 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This tells the agent when to use it and sets expectations for the role of this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds significant behavioral context: parallel fan-out across sources, specific return data, USPTO sunset soft-fail, and news fallback.

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

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

Description is front-loaded with example queries, then structured as a clear list of returned items. Every sentence adds value; no fluff.

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

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

Given the tool's complexity (multiple sources, multiple data types), the description is remarkably complete. It lists all returned fields, mentions parallel call, and handles edge cases like USPTO sunset and name resolution.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning by explaining type enum (only company), value (ticker or CIK), and explicitly stating names not supported, with examples.

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

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

The description explicitly states the tool returns a full cross-source profile of a US public company, listing data sources and returned fields. It distinguishes itself from chaining individual lookups by stating preference for holistic queries.

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?

Clearly states when to use ('ALWAYS PREFER over chaining...') and when not to use ('names not supported – use resolve_entity first'). Provides clear alternatives and context.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds 'Delete' which confirms destructiveness but does not elaborate on idempotency, error handling, or effects of deleting a non-existent key. The description adds minimal value beyond annotations.

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

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

The description is a single sentence plus one usage sentence, with no wasted words. The key purpose is front-loaded. Every sentence is necessary.

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 delete tool with one parameter and no output schema, the description provides purpose, usage context, and sibling relationships. It lacks details on return value or confirmation, but these are often implicit for delete operations. Slightly incomplete but adequate.

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% for the single parameter 'key', with a basic description. The tool description does not add further meaning about what constitutes a valid key or how to obtain it. Baseline of 3 is appropriate since schema covers the parameter completely.

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

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

The description clearly states the action ('Delete') and the resource ('previously stored memory by key'), and distinguishes it from sibling tools 'remember' and 'recall' by mentioning them for pairing.

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

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

The description explicitly lists when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. It also suggests pairing with 'remember' and 'recall', providing context on alternatives. However, it does not state when NOT to use.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds behavioral details: that it fetches a page (network operation), extracts title/description/key links, and outputs a single text blob. This provides useful context beyond annotations.

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

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

The description is four sentences with zero wasted words. It front-loads the core action, then explains the method, output format, and use cases in a logical order.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers all necessary aspects: what it does, how it works, what it returns, and when to use it. It is self-contained and leaves no obvious gaps.

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

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

Schema description coverage is 100% (both parameters have descriptions). The description reiterates 'any URL' and mentions 'maximum number of link entries' but adds no significant new meaning beyond the schema. 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 explicitly states 'generate a production-ready llms.txt file for any URL' and details the process (fetches, extracts, emits). It clearly distinguishes from sibling tools, which cover different domains like betting, crypto, or entity resolution.

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

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

The description provides three specific use cases: getting a client's site indexed, drafting for own project, and auditing competitors. It also names the target AI crawlers (ChatGPT, Claude, Perplexity), offering clear context for when to invoke this tool.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by listing the exact fields returned and specifying 'caller's active' scope, giving further 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?

Two concise sentences; first sentence states core purpose, second provides use case guidance. No unnecessary words, efficient and front-loaded.

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

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

Tool is simple with one optional parameter, complete annotations, and no output schema. Description covers purpose, returned data, and usage context adequately for an AI agent to invoke correctly.

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

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

Schema coverage is 100% with a well-described boolean parameter. The description does not add additional semantic detail beyond the schema, but it implicitly aligns 'active' with default parameter behavior. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'list', the resource 'subscriptions', and specifies scope as 'the caller's active subscriptions'. It also lists returned fields, distinguishing it 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 guidance on when to use: to review monitoring before adding more subscriptions or to find an ID for cancellation. Could mention the include_inactive parameter for listing inactive ones, but the guidance is clear.

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

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

Annotations are all false, so the description carries full behavioral burden. It goes beyond them by disclosing the anonymous claim_token workflow, the ability to later poll for resolution status, the 5/day rate limit, and that it's free and doesn't consume tool-call quota. This is substantial extra context.

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

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

Long but every sentence carries actionable information: purpose, when-to-use, scope exclusions, phrasing guidance, token workflow, rate limit, and quota note. It is front-loaded with the core purpose and contains no filler or redundancy.

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

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

For a tool with 4 optional params, a nested context object, no output schema, and nuanced usage rules, the description covers the full feedback lifecycle: what to report, how to phrase it, scope boundaries, the claim_token retrieval path, rate limits, and quota impact. Nothing important is left unexplained.

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

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

Schema coverage is 100% with detailed param descriptions, so baseline is 3. The description adds workflow meaning by explaining that filing returns a claim_token and how to use it later, and it maps type values to real-world scenarios, enriching the schema.

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

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

The description opens with a specific action ('Tell the Pipeworx team something is broken, missing, or needs to exist') and enumerates feedback categories (bug, feature/data_gap, praise). It explicitly restricts scope to Pipeworx tools, distinguishing it from sibling tools like ask_pipeworx or discover_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 gives explicit when-to-use triggers for each feedback type, a clear exclusion for tools from other MCP servers ('file it with that server instead'), and a heuristic for identifying Pipeworx tools. It also advises on phrasing and states the rate limit, leaving no ambiguity about when this tool is appropriate.

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

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

Annotations declare readOnly, openWorld, idempotent, and non-destructive. Description adds valuable context: data source (CF analytics-engine), no PII, cache duration (5min-1h). 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?

Three efficient sentences plus a bullet list. Every sentence adds value: core purpose, use cases, and transparency. No redundancy or fluff.

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

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

With single optional parameter and no output schema, description adequately explains return (top tools, packs, volume). Could clarify what 'top' means (e.g., by call count), but sufficient for a simple trending 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?

Only parameter 'window' has 100% schema coverage and enum values with descriptions. Description adds nuance: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' Enhances understanding beyond enum labels.

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 returns 'top tools, top packs, and total call volume' over a window, with a specific verb 'Returns' and resource 'trending tools/packs'. It differentiates from siblings like 'discover_tools' by focusing on current usage trends.

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?

Lists three explicit use cases (discovering hot data sources, confirming canonical tools, aligning use case). Explains window choice (short for hot, long for steady-state). Lacks explicit when-not-to-use or alternative tools, 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?

Disclosures beyond annotations include semantic anchor (Jaccard similarity >= 0.30), partition filter (placeholder slugs), fill check against live CLOB depth, and conditions for not trading. Annotations (readOnly, idempotent) are consistent, and description adds critical behavioral context.

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

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

The description is thorough but somewhat lengthy. However, it is well-structured with clear sections for each mode and key details. Every sentence adds value, but a slightly more compact presentation 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 complexity and absence of an output schema, the description fully explains the return structure (opportunities[] with fields, partition_check in event mode) and covers all key aspects like fill check and filtering. 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 descriptions cover both parameters ('event' and 'topic') fully. The tool description adds significant context (e.g., accepted formats, recommended usage, how each mode works) that enhances understanding beyond the schema.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes itself from sibling tools like polymarket_edges and polymarket_fill_risk by focusing on arbitrage detection across events and modes.

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

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

Explicitly explains three usage modes: no args for trending scan, 'event' for specific markets (recommended), and 'topic' for cross-event scans. Provides concrete examples and context for each, leaving no ambiguity about when to use which.

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 significant value beyond annotations: it explains caching (1h at KV level), response structure (by_segment, _diagnostics), model details, and tradeable-edge knobs. No contradictions.

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

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

The description is well-structured with sections (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT) and uses bold for key terms. It is dense but every sentence adds value. However, its length could be trimmed slightly; still highly 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 (9 parameters, multiple model families, no output schema), the description is remarkably complete. It explains why Fed bets are excluded, what diagnostics are returned, and the caching behavior. Everything an agent needs to understand and use the tool is present.

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

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

Schema coverage is 100% (all 9 parameters described), so baseline is 3. The description adds rich context: slippage_pp explains Polymarket fees, min_partition_leg_kelly clarifies why min_kelly doesn't apply to partitions, and category_filter options are listed with examples. 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 uses specific verbs ('scan', 'return opportunities') and clearly identifies the resource (Polymarket markets). It distinguishes from siblings by emphasizing Pipeworx data and the unique model-driven approach, stating it's built for 'what should I bet on today'.

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 context for when to use the tool (discovery of opportunities) and mentions exclusions (Fed bets are excluded from ranking). However, it does not explicitly compare to sibling tools like polymarket_arbitrage or polymarket_edge_tracker.

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 behavior beyond annotations: it is read-only, idempotent, and not destructive. It details return structure (tracked, expired, snapshot_dates) and limitations (TTL, snapshot gaps, decay from daily closes). 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 front-loaded with purpose, then explains args, response structure, and limitations in a logical order. It is slightly verbose but well-structured, with every sentence providing value. Could be tightened, but effective.

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

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

Despite lacking an output schema, the description thoroughly covers return fields (tracked[], expired[], snapshot_dates[]) and their subfields (first_seen, trend, decay_pp_per_day, lifespan_days). It also addresses limitations like history depth and snapshot gaps. Highly complete for the tool's complexity.

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

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

Schema descriptions already cover both parameters (days and window) with defaults and constraints. The description adds context: explains 'days' as lookback, clarifies the default (14) and max (30) despite schema clamping to 2-30, and mentions the default window ('1wk'). This adds marginal value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It answers a specific question ('how long has this edge existed and is it shrinking?') and distinguishes itself from sibling tools like polymarket_edges by focusing on historical telemetry rather than current edges.

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

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

The description explains when to use the tool: to determine if an edge is new or old, implying it is not for just current edges (which would use polymarket_edges). It provides context about the value of freshness but does not explicitly name alternatives, though the implication is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds behavioral context: it computes slippage, returns verdicts, and describes risk of partial basket fills converting arb into unhedged position. 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?

Description is comprehensive and well-structured with clear sections (REQUIRES, SINGLE-MARKET, BASKET, USE THIS). Every sentence adds value, though length could be trimmed slightly. Front-loaded with purpose, then mode-specific details.

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

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

Despite no output schema, description enumerates all return fields for both modes (top_of_book, vwap_fill_price, capture_ratio, thin_legs, etc.). Covers rationale, risk, and usage context thoroughly. Leaves no significant gaps given tool complexity.

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

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

Schema coverage is 100%, but description adds significant meaning: interprets size_usd differently for single-market vs basket, explains side default for basket (auto from partition sum), and documents clamp range. These details go beyond schema descriptions.

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

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

Description clearly states the tool checks realizable-vs-theoretical edge against live order-book depth, distinguishing single-market and basket modes. Verbs like 'walks the ladder' and return values like 'top_of_book', 'vwap_fill_price' make purpose precise and differentiate from siblings 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?

Explicitly states when to use: before acting on polymarket_arbitrage SELL/BUY-EVERY-LEG or edges above ~$500. Explains why theoretical overround is not capturable on thin books and warns of directional risk from partial fills. Provides mode-specific usage details.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description goes far beyond by detailing safety fields (compatibility_warning conditions, temporal_alignment, skipped_cross_type/subtype) and explaining when results are meaningless. No contradiction with annotations.

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

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

The description is relatively long but well-structured with clear sections (MODES, RESPONSE, SAFETY FIELDS). It is front-loaded with the core purpose. While every sentence adds value, it could be slightly more concise 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?

Given the tool's complexity and lack of output schema, the description fully explains return values (leg-by-leg prices, spread array, safety fields) and edge cases (compatibility warnings, temporal alignment). It provides complete context 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% with each parameter described. The description adds significant value: enumerates all topic options, explains override behavior when both topic and explicit parameters are provided, and clarifies the effect of each parameter on the tool's behavior.

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

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

The description clearly states the tool's purpose: computing cross-venue spread between Kalshi and Polymarket. It specifies the verb 'spread' and resource 'cross-venue', and distinguishes from sibling polymarket tools (e.g., polymarket_arbitrage) by focusing on spread calculation rather than arbitrage opportunities.

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 two modes (topic shortcuts and explicit event tickers) and provides warnings about compatibility, indicating when the tool may not be useful. It implicitly suggests using explicit mode over pre-mapped topics for reliability, though it does not explicitly compare to sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds scoping detail (by identifier) and pairing context, which goes beyond annotations without contradiction.

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

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

Four sentences, front-loaded with purpose, each sentence provides distinct value. No redundant or peripheral information.

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

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

Given the tool's simplicity (one optional param, no output schema), the description covers purpose, usage, scoping, and sibling relationships completely.

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

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

Schema coverage is 100%, and the description's comment about omitting key to list all keys is already in the parameter description. No additional meaning is added 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 retrieves or lists saved values from 'remember', with specific verb 'Retrieve' and resource 'value previously saved'. Distinguishes from siblings 'remember' and 'forget'.

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

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

Provides explicit use cases (look up ticker, address, notes) and mentions pairing with remember/forget. Lacks explicit when-not-to-use, but context is clear enough.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description reveals critical behavior: setting mark_read:true flags events as read so subsequent calls only show newer ones. It also clarifies return fields (source, citation_uri, raw payload). 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 concise and front-loaded with the core purpose. Every sentence adds value, and there is no redundant or tangential information.

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

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

For a tool with no output schema, the description covers return fields, parameters, and behavior (mark_read affecting subsequent calls). It also mentions an alternative access method. Slight gap: does not mention pagination or sorting, but overall it's quite complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context for type and since with an example ('sec_8k') and explains mark_read's effect, but the schema already defines these parameters adequately.

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

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

The description clearly states the tool 'pulls fired events from your subscription feed' with specific details on what each alert contains. While it doesn't explicitly differentiate from sibling tools, the verb 'pull' and resource 'subscription feed' establish a clear purpose.

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

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

The description explains when to use filtering (type, since) and the mark_read behavior. It also notes that polling works fine and mentions an alternative HTTP endpoint (GET .../alerts.json) for scripts/dashboards, providing good usage context.

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

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

Annotations already indicate readOnly and idempotent. The description adds details: fans out to multiple sources, GDELT→GNews fallback, USPTO soft-fails, and output structure (changes[] grouped by source, total_changes count, 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?

The description is a single paragraph of ~100 words, front-loaded with example queries, and every sentence adds meaningful information without redundancy.

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

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

Despite no output schema, the description explains the return format. It covers all key behavioral aspects (sources, fallback, parameter formats) and provides a clear alternative tool reference.

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 value by explaining the `since` parameter format (ISO date or relative shorthand with examples) and that `value` accepts ticker or CIK.

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 recent changes (SEC filings, news, patents) for a company in a time window. It includes concrete example queries and explicitly distinguishes from the sibling tool 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 provides explicit guidance on when to use this tool ('What's new' queries) and when not to (use entity_profile for static profile). It also explains the fallback logic for news sources.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by detailing the output fields (parcel number, owner, land use, etc.) and specifying the database scope (US/CA). This provides behavioral context beyond what annotations offer, though it doesn't cover edge cases like pagination or error handling.

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 with only two sentences and an inline code example. Every sentence is informative, and the example demonstrates usage. No unnecessary words or repetition.

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

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

Given the tool's simplicity (3 params, no output schema, rich annotations), the description adequately covers what the tool does and what it returns. It specifies the geographic scope and includes an example. However, it could be slightly improved by mentioning the default limit or error handling, but overall satisfactory.

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

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

Schema coverage is 100%, with all three parameters described. The description provides an example with typical values but does not add new semantics beyond what the schema already provides. The example is helpful but doesn't elevate the score above baseline.

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

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

The description clearly states the tool looks up parcel information for a given address, specifying the verb 'look up' and the resource 'parcel.' It lists the types of data returned (owner, zoning, etc.), making the purpose clear. However, it does not explicitly distinguish itself from the sibling tool 'regrid_parcel_by_point,' which uses coordinates instead of addresses.

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

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

The description implies the tool is used when you have an address and want parcel data, but it provides no guidance on when not to use it or when to use alternatives like regrid_parcel_by_point. No explicit context for tool selection is given.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds that it returns parcels containing or 'near' the coordinate, clarifying the radius parameter's effect. 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?

Extremely concise: two sentences and a code example. Example is front-loaded and directly demonstrates usage. 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?

Covers purpose, parameters, and output fields. With no output schema, it would help to describe return format or typical fields. However, given simplicity and the example, it is mostly complete. Distinction from sibling could be clearer.

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 already describes all 4 parameters. Description adds value through two examples showing how to call with and without radius, clarifying that radius is for 'near' searches. This goes beyond the schema's text.

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 action (Find parcels), input (lat/lon point), and output (owner, zoning, land use, acreage, boundary). Distinguishes from sibling 'regrid_parcel_by_address' which uses an address instead of coordinates.

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

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

Provides an example but no explicit guidance on when to use this vs alternatives like 'regrid_parcel_by_address'. Does not mention when to include radius or any exclusions.

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

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

Adds important context beyond annotations: scoping by identifier, persistence differences for authenticated vs anonymous users (24-hour retention), key-value nature. 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?

Single paragraph with front-loaded purpose, followed by use case, scope, and pairing. Every sentence adds value, no redundancy.

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

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

For a simple 2-param tool with no output schema, the description fully covers purpose, usage, behavior, and context. No gaps.

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

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

Schema covers both parameters with descriptions (100% coverage). Description adds example keys and purpose context, but does not significantly extend schema details; baseline 3 with modest addition.

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

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

Clear verb ('save') and resource ('data to reuse later') with specific scope ('across conversation or sessions'). Differentiates from siblings by mentioning 'recall' and 'forget'.

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

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

Explicitly states when to use ('when you discover something worth carrying forward') and gives concrete examples. Pairs with recall/forget, providing clear alternative context.

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

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

Annotations already declare read-only and idempotent behavior. The description adds that the call cascades through multiple lookup endpoints, replaces 2-3 manual lookups, and returns specific citation URIs, which is useful behavioral context beyond annotations.

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

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

The description is moderately long but well-structured, with examples front-loaded and a clear breakdown of supported types. No redundant sentences; each phrase adds 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?

No output schema is provided, but the description enumerates returned fields (ticker, CIK, company_name, RxCUI, ingredient, brand) and citation format. Combined with annotations, it provides sufficient context for a lookup 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?

Input schema provides 100% coverage of both parameters, including acceptable value formats. The description adds examples (e.g., 'ozempic', 'metformin') and notes auto-disambiguation, but these are supplementary rather than essential given the schema.

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

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

The description clearly identifies the tool's function: resolving user-spoken names to canonical identifiers. It provides concrete examples ('What's the ticker for…') and distinguishes supported entity types (company/drug), making it distinct from sibling tools like entity_profile or search 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 advises 'Use FIRST whenever you have a name but need an ID,' giving clear usage context. It does not name alternatives or exclusions, but the instruction is strong enough to guide deployment.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds value by explaining the internal process (probes each entity with ai_visibility_check), the return format (ranked list with score, confidence, signal density), and the use case. 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 concise at four sentences, front-loading the purpose, then covering process, use case, and return format. Every sentence adds value without redundancy or fluff.

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

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

Given moderate complexity (4 parameters, no output schema), the description adequately explains the tool's purpose, internal working, use case, and output structure ('ranked list with score, confidence, signal density per entity'). It does not cover edge cases or error conditions, but the core functionality is clearly described.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The tool description reiterates that the first entity is the subject and rest are competitors, which is also in the schema. It does not add significant meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description uses specific verbs ('Compare', 'Probes', 'ranks', 'surfaces') and clearly defines the resource (AI visibility of multiple entities side-by-side). It distinguishes itself from sibling tools by specifying it compares multiple entities, unlike 'ai_visibility_check' which checks a single entity.

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

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

The description explicitly states it is 'Useful for competitive AI-marketing audits' and provides a concrete example question. It implies the tool is for multi-entity comparison but does not explicitly exclude single-entity checks (for which 'ai_visibility_check' is available). The mention of using 'ai_visibility_check' internally gives context, but direct alternatives are not named.

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

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

Annotations already indicate read-only, open-world, idempotent. Description adds critical behavioral details: fans out across two services, bundlephobia first measurement can take 5-30s, sources_failed will list timeouts, and partial failures degrade gracefully. 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?

Highly efficient: front-loaded purpose, then use cases, ecosystem limitation, performance note. 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?

Given complexity (composite call, two data sources, potential timing), description covers return fields, failure modes, and version alternatives. No output schema, but return fields are listed, making the tool fully understandable.

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

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

Schema already achieves 100% coverage. Description adds context: package is npm package name (accepts scoped packages), version defaults to latest. Adds value beyond schema without redundancy.

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

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

Clearly states it's a composite check for npm packages covering licenses, advisories, and bundle size. Distinguishes from sibling tools by specifying ecosystem scope and mentioning alternatives for other ecosystems.

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

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

Explicitly says 'Use whenever an agent asks...' and provides when-not-to-use: 'NPM ecosystem only in v1; PyPI/Maven/Cargo/Go fall under deps.dev:version directly.' Also addresses partial failures and graceful degradation.

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

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

Adds substantial context beyond annotations: embedding model (BGE-base-en), windowing (500-char overlapping), character cap (200K with truncation flag), and offset details. No contradictions.

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

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

Information-dense single sentence, front-loaded with key purpose. Slightly dense but 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 adequately explains return format (passages, offsets, scores) and truncation behavior. Complete enough for a read-only search tool.

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

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

Schema coverage is 100%, but description adds examples for 'query', clarifies 'text' is the document, and explains default for 'limit'. Adds behavioral constraint on text length.

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

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

Description clearly states 'Semantic search INSIDE a fetched record' with concrete examples (SEC 10-K, article) and distinguishes from sibling tools like ask_pipeworx_grounded.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt' and explains how it saves context and enables verification via offsets. Also pairs with ask_pipeworx_grounded.

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 discloses behavioral traits beyond annotations: authentication requirements (Pipeworx OAuth, not anonymous/BYO), delivery channel constraints (SMS cap, phone verification), webhook signing secret returned once, auto-disable after 10 consecutive failures, and type-specific parameter details. No contradiction with annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false).

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

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

The description is appropriately sized given the tool's complexity. It is front-loaded with the core purpose, then organized into clear sections: subscription types, delivery channels, and constraints. Every sentence earns its place without redundancy.

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

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

Considering the tool's complexity (3 parameters, nested objects, no output schema), the description is remarkably complete. It covers all subscription types, parameter formats, delivery options, authentication requirements, and behavioral quirks. No gaps are apparent.

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 goes far beyond—providing concrete examples for each subscription type, explaining item codes for sec_8k, delivery channel details, and validation constraints. This adds significant meaning that helps the agent construct correct parameter values.

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

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

The description clearly states the tool creates a proactive monitoring subscription to a live-data event stream and returns the new subscription id. It uses specific verbs and resources, and its purpose is distinct from siblings like list_subscriptions, unsubscribe, and recent_alerts, even without explicit contrast.

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 context for when to use the tool (setting up monitoring subscriptions) and includes important prerequisites like requiring a Pipeworx OAuth account. However, it does not explicitly exclude alternative tools or state when not to use it.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds value by explaining the output structure: returns category-bucketed example questions with exact tool+argument shapes. 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 front-loaded with example queries and each sentence adds value. It is slightly lengthy but still efficient for the amount of information conveyed. No redundant or tautological 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 the tool's simplicity (1 optional param, no output schema, clear annotations), the description covers purpose, usage, output, and context. It is complete for an onboarding tool, providing all needed information for an agent to decide when and how to call it.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that omitting topic gives a cross-category spread and listing possible focus areas (finance, pharma, etc.), which goes beyond the schema description 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 it is an onboarding entry point that returns category-bucketed example questions with tool+argument shapes. It uses specific verbs like 'returns category-bucketed example questions' and explicitly distinguishes from siblings like ask_pipeworx by positioning itself as the first tool to use when the agent doesn't know what Pipeworx can do.

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

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

Explicitly states 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' Also explains the topic parameter for focusing. Lacks explicit when-not-to-use guidance, but the advice is clear enough.

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

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

Adds significant context beyond annotations: ownership enforcement, row deactivation, and historical event availability. 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?

Two sentences, front-loaded with purpose, no wasted words.

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

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

Adequately covers purpose, constraints, and effect for a simple single-parameter tool; lacks output description but acceptable given no output schema.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by referencing 'subscribe' as the source of the id, improving parameter 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?

Clearly states action 'Cancel a subscription by id' with specific verb and resource, and is distinct from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Provides ownership enforcement and behavior (deactivation, not deletion) but does not explicitly state when to use versus alternatives; however, context is clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds significant behavioral detail: explains the dual pipeline (structured SEC vs grounded), the output format (verdict, actual value with citation, reasoning), and performance benefits (replaces 4-6 calls). 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 well-structured: trigger phrases first, then usage, then internal paths, then output summary. Every sentence contributes meaningful information. While not extremely concise, it earns its length by packing in essential details.

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

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

Given 2 parameters with 100% schema coverage and no output schema, the description is complete. It details the types of claims handled, the two pipelines, the verdict types, and the output components (citation, reasoning). This suffices for the tool's complexity.

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

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

Schema coverage is 100%, baseline 3. The description adds value beyond schema by providing examples for 'claim' (Apple revenue, Microsoft profit) and context for 'tolerance_pct' (overrides implied tolerance, recommended for hallucination detection). This is above average.

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 explicit trigger phrases and defines the tool's purpose as natural-language claim verification against authoritative sources. It distinguishes between company-financial claims (SEC EDGAR path) and other claims (grounded pipeline), setting it apart from sibling tools like deep_research or 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 states 'Use whenever the agent needs to check whether something a user said is factually correct.' It provides clear subcases (financial vs other) and hints at the internal routing. It does not explicitly list when not to use, but the sibling list and context make it clear this is for verification, not general research.

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