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?

Annotations already declare readOnly, openWorld, and idempotent behavior. The description adds meaningful behavioral detail: it routes across 5,798 tools and 1,517 sources, fills arguments automatically, and returns structured answers with stable pipeworx:// citation URIs. This goes beyond the annotations and gives the agent a realistic model of what the tool does.

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 drawn out: it repeats the routing/citation idea, lists many overlapping domains, and ends with a dense, awkwardly punctuated sentence about news feeds. While 'START HERE' and 'Step up only when needed' help structure it, the overall length is not proportional to the added value.

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

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

Even though there is no output schema, the description tells the agent what kind of answer to expect: structured, with stable citation URIs. Combined with the annotations covering safety and the schema covering the question parameter, the description gives sufficient context for an agent to invoke the tool correctly in most situations.

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

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

The schema already has 100% coverage for the single conceptual parameter, with descriptions for question and all its aliases. The description adds natural-language examples and domain guidance, but it doesn't change the fact that the schema carries the parameter semantics. Baseline 3 is appropriate.

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

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

The description clearly states what the tool does: it routes questions to the appropriate tool among thousands of verified sources and returns structured answers with citation URIs. It also distinguishes itself from siblings by calling it the 'default entry point' and naming ask_pipeworx_grounded and deep_research as escalation alternatives.

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

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

The description is explicit about when to use the tool: 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and 'Use whenever the user asks...'. It also gives clear escalation criteria for ask_pipeworx_grounded and deep_research, plus a note that breaking-news is already handled by this tool rather than requiring a separate one.

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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond annotations: the current live state ('No candidate is active right now'), the testing/retirement cycle, and the reassurance that it is a full working router with no 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?

Four sentences, with the key identity ('Beta version of ask_pipeworx') front-loaded. The specific retirement date is a minor extra detail, but every sentence contributes useful context about experimental status, current equivalence, and comparison behavior.

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 the essentials for a routing tool: relationship to ask_pipeworx, current state, matching response shape, and fallback expectations. No output schema exists, but referencing 'same response shape' as the stable sibling is 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% — all six parameters, including aliases, are documented in the schema. The description mentions 'same arguments' but adds no new semantic detail beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific resource ('beta version of ask_pipeworx: identical universal router') with the same 5,798 tools, arguments, and response shape. It clearly distinguishes itself from the stable sibling via 'candidate routing improvements' and 'experimental edge'.

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 instructs when to use it: 'Use it exactly like ask_pipeworx when you want the newest routing.' It names the stable router as the alternative and explains the comparison purpose. Lacks explicit when-not-to-use guidance, so not a 5.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, and the description adds substantial context about refusal reasons, evidence extraction, verbatim quotes, data-truncation handling, and the cost of an extra LLM call. It does not contradict any annotation and makes the tool's failure modes explicit.

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 information-dense with no wasted sentences: purpose, routing behavior, return contract, usage guidance, and cost tradeoff are each covered efficiently. The return and refusal schemas are compactly embedded, and the usage guidance is front-loaded with the key differentiator.

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 being an internally complex routing tool, the description covers everything an agent needs: when to use it, how it behaves, what success and refusal responses look like, and how it relates to the sibling ask_pipeworx. The input schema handles the parameter side, so no important context is missing.

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

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

Schema coverage is 100%, and the schema fully describes the question parameter and its aliases, so the description does not need to add parameter-level detail. The description adds no new parameter semantics, but it also does not need to, making the baseline of 3 appropriate.

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

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

The description clearly identifies this as a hallucination-resistant answer mode, names the specific routing behavior, and contrasts it with ask_pipeworx by emphasizing evidence-grounded extraction. It also specifies the exact success and refusal return shapes, leaving no ambiguity about what the tool does.

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

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

The description explicitly says when to use this tool — when answers will be quoted, cited, or acted on and must not be invented — and when to prefer ask_pipeworx instead for casual lookups. It also mentions the extra LLM call cost as a tradeoff, giving the agent clear decision criteria.

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 already cover safety (read-only, non-destructive, idempotent), and the description adds rich behavior beyond those: parallel decomposition across 5,798 tools, findings packet contents, never-invented gaps[], contradiction scans, semantic excerpting, hop/recovery behavior, and precise latency expectations. 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?

Long but dense and front-loaded with the critical prerequisite (account required) and fallback. Each clause adds a distinct behavioral fact; however, the heavy use of parentheses and nested asides makes it harder to parse than necessary. The length is justified for 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?

Despite having no output schema, the description fully covers the return contract (verbatim evidence, confidence, source, fetched_at, citation_uri, gaps[], contradictions[]), limitations (structured sources only, not open-web), usage context, and performance expectations. An agent has everything needed to decide whether to call this tool and what to anticipate.

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 does add value by explaining the practical meaning of depth tiers in terms of hops and latency ('quick=3 (single hop)... thorough=6 (paid)'), and clarifies that 'question' accepts broad/multi-part natural language. This goes slightly beyond the schema's already-detailed enum 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?

States a specific action (grounded multi-source research), the exact resource scope (1517 structured data sources), and a clear contrast ('this is NOT open-web search'). Also names the sibling alternative (ask_pipeworx), making it easy to distinguish.

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 when to use: 'Best for broad/multi-part questions over structured data.' Provides direct exclusion: 'For a single lookup use ask_pipeworx instead' and requires sign-in with fallback routing to ask_pipeworx. This is concrete when/when-not guidance with named alternatives.

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

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

Annotations already declare readOnlyHint=true, 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 readOnly/openWorld/idempotent, and the description adds substantial behavior beyond that: parallel fan-out across sources, sources_used/sources_failed semantics, empty sections meaning true 'no data', patents API soft-failure, FDA biologics filtering, and name resolution via EDGAR. 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?

Long but appropriately so for a tool with many source sections and edge cases. It front-loads the purpose and examples, then densely packs return-field semantics; semicolons and bullet-like clauses keep it scannable without wasted filler.

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

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

There is no output schema, so the description correctly carries the full burden. It enumerates every return section (cik, recent_filings, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI, sources_used/failed) and covers input and resolution edge cases. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the schema already documents both parameters thoroughly. The description adds the private-company resolved:false behavior and reiterates interchangeable type values — a small but meaningful semantic addition, so a slight boost from baseline is warranted.

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

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

States a clear verb+resource: 'full cross-source profile of a US public company in ONE parallel call,' and grounds it with concrete user prompts. It effectively distinguishes itself from the single-pack SEC/XBRL/news lookups it is meant to replace.

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 instructs when to prefer this tool: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also gives clear input routing (ticker, CIK, name) and edge-case behavior (private company returns resolved:false), leaving little ambiguity.

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

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

Annotations already 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?

With no output schema, the description carries the burden of explaining behavior, and it does so thoroughly: compatibility codes, temporal mismatches, skipped unclassified legs, keyword-based matching, fee modeling limits, and gross-vs-net spread are all disclosed. It also adds significant context beyond the existing read-only, idempotent, non-destructive annotations.

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

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

The description is long and dense, but it is clearly structured with labeled sections like TWO MODES, RESPONSE, SAFETY FIELDS, and Codes. The purpose is front-loaded, and most sentences carry important caveats; however, some repetition and the sheer length keep it from being maximally concise.

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

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

This is a complex tool with no output schema, yet the description documents response fields, safety flags, compatibility codes, spread semantics, skipped-leg counters, and fee limitations. An agent has enough information to invoke the tool correctly and interpret its results, including edge cases where matching is unreliable.

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

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

The schema already covers 100% of the parameters, so the baseline is 3. The description adds useful semantic structure by explaining the two modes, the auto-fetch behavior of `topic`, and the override relationship of the explicit parameters. This is meaningful but not exhaustive enough to justify a 5 given the schema already documents each field.

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

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

The first sentence states the exact function: "Cross-venue spread between Kalshi and Polymarket for the same resolving question." It goes on to distinguish two modes and clearly identifies the resource and outcome being measured, making it easy to separate from related tools like polymarket_arbitrage or polymarket_edges.

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

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

The description gives clear context on how to use the tool: the `topic` mode auto-fetches pre-mapped events, while explicit ticker/slug mode is for custom pairings, and both modes run the same matcher. It warns that pre-mapped topics are often not tradeable, but it never explicitly names alternative tools or states when this tool should be chosen over a sibling.

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?

Beyond annotations, it reveals cascade behavior, graceful degradation when GLEIF/OpenFIGI are unavailable, explicit unresolved reporting, and ambiguity handling via figi_candidates. These are meaningful behavioral traits not captured by annotations, and none contradict the readOnly/idempotent/destructive hints.

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

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

The description is front-loaded with user-phrasing examples and a direct usage directive, and most details are valuable. However, the long nested parentheticals and repeated clarifications make it denser than necessary, so it is not maximally concise.

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

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

For a complex two-type resolver with no output schema, the description covers inputs, outputs, ambiguity, failure handling, and degradation. Nothing an agent needs in order to call it correctly is missing.

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

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

Although schema coverage is 100%, the description adds essential semantics: accepted forms for company (ticker, CIK, ISIN, name) and the critical caveat to pass only the entity name, with a bond-issuer example. This goes well beyond the schema's one-line 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 states a precise purpose: converting a user-spoken name into canonical/official identifiers, with supported types ('company', 'drug') and concrete identifier outputs. It is clearly distinguished from siblings like entity_profile and compare_entities by focusing on resolution into IDs that other tools require.

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 instructs agents to 'Use FIRST whenever you have a name but need an ID,' providing strong selection context. It does not explicitly name sibling tools as alternatives or state when not to use it, so it stops at clear context rather than full exclusions.

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

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

Annotations declare 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?

Beyond the readOnly/idempotent annotations, the description discloses two distinct execution paths, the full set of verdicts, and critical semantics for could_not_verify (no evidence for/against) and unsupported (no source coverage). It also surfaces potential failure via verification_error{stage,detail}, adding notable behavioral detail.

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

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

The description is fairly long but well-structured, starting with natural-language examples and ending with important caller caveats. Every sentence conveys necessary information; the only minor critique is that the opening phrase list could be condensed, but it aids recognition.

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

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

With no output schema, the description must explain return semantics, and it does: verdict list, actual value with citation, reasoning, and the distinction between could_not_verify and unsupported. It also covers the two routing paths and error handling, making it complete for a complex verification 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?

While the schema already documents both parameters at 100% coverage, the description adds meaningful guidance: examples for claim format, and for tolerance_pct explains how it overrides implied wording, suggests 1–2 for hallucination detection, and notes the default cap of 5. This goes beyond schema boilerplate.

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

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

The description clearly identifies the tool as natural-language claim verification against authoritative sources, with specific trigger phrases and a structured verdict system. It distinguishes itself from siblings by detailing the SEC EDGAR fast path and grounded pipeline, and by noting it replaces 4–6 sequential calls.

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

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

Explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct' and outlines which path applies (company-financial vs any other claim). It does not name alternative tools or exclusions, but the context is clear enough for most selection decisions.

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