Gov Bids

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds valuable behavioral context: returns per-model scores/confidence/signals/raw response, combined view, and that Anthropic calls require own key and payment. 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?

Single paragraph with no fluff. Each sentence serves a purpose: main action, default, optional key, return format, use cases. Perfectly front-loaded with the core purpose.

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

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

Given 4 parameters and no output schema, the description covers purpose, all parameters with defaults/options, return format (per-model fields), and use cases. Lacks explicit detail on the combined view or raw_response structure, but sufficient for an agent to understand what it returns.

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

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

Schema coverage is 100%, baseline 3. The description adds meaning beyond schema by explaining default model, how to omit models list, the key format for _apiKey, and an example for context. This enriches understanding beyond the parameter descriptions.

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

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

The description clearly states the tool probes LLMs for knowledge about an entity and scores visibility per model. The verb 'probe' and resource 'visibility' are specific, and it distinguishes itself from sibling tools like 'ask_pipeworx' or 'deep_research' by focusing on brand visibility across models.

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 context on when to use (AI-marketing audits, pre-launch brand checks) and how to use (default model free, optional Anthropic key). Does not explicitly state when not to use or list alternatives, but the use-case 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?

Even though annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the description adds valuable behavioral context: it routes to other tools, fills arguments, returns structured answers with stable pipeworx:// citation URIs, works on every tier, and is a single fast call. This goes well beyond the annotations without contradicting them.

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

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

The description is lengthy but every sentence serves a distinct purpose: preference over web search, supported domains, routing behavior, usage triggers, examples, when to use alternatives, and handling of breaking news. It is front-loaded with the most critical guidance ('PREFER OVER WEB SEARCH') and remains well-structured throughout, with no redundancy.

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

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

Given the tool's complexity as a meta-router with no output schema, the description is remarkably complete. It explains what the tool does, what kind of questions to ask, what the answer will look like (structured with citation URIs), and how to choose alternatives. This covers all necessary context for an agent to select and invoke the tool correctly.

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

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

The schema already provides 100% coverage for all parameters, with clear descriptions of the main 'question' field and its aliases. The description adds semantic guidance by enumerating acceptable question types and providing concrete examples, but this is supplementary since the schema itself is already strong. Baseline is 3, and the added context raises it to 4.

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

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

The description clearly states the tool's function: routing questions to one of 5,467 tools across 1,423 verified sources and returning structured answers with citations. It uses specific verbs and resources, and explicitly distinguishes itself from siblings like ask_pipeworx_grounded and deep_research by describing when each is appropriate.

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 vs. alternatives, including 'PREFER OVER WEB SEARCH,' 'START HERE for most questions,' and specific conditions for stepping up to ask_pipeworx_grounded or deep_research. It also lists trigger phrases and example questions, covering both inclusion and exclusion 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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint; the description adds significant behavioral context: experimental status, live candidate switching, current match to stable, and no fallback (it IS the full router). 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 dense sentences cover beta identity, current state, and usage guidance. Each sentence earns its place, and the key phrase 'Beta version of ask_pipeworx' is front-loaded. 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 covers purpose, sibling relationship, current state, and behavioral expectations. The phrase 'same response shape' handles return expectations. Everything the agent needs to know is present, with no ambiguity.

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

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

Input schema has 100% description coverage; all parameters are aliases for 'question' and are fully documented. The description mentions 'same arguments' but adds no detail beyond the schema, so baseline 3 is appropriate.

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

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

The description explicitly identifies this as the beta version of ask_pipeworx, stating it is 'identical universal router (same 5,467 tools, same arguments, same response shape)'. It clearly distinguishes from the stable ask_pipeworx by noting experimental routing improvements when under test, and confirms it is a full working router, not a thin wrapper.

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?

Direct usage guidance is provided: 'Use it exactly like ask_pipeworx when you want the newest routing'. It contrasts with the stable router and clarifies current state (no candidate active, matches ask_pipeworx exactly). This gives the agent enough context for when to prefer 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?

The description fully discloses behavioral traits beyond the readOnly/idempotent/destructive annotations. It details the refusal mechanism with specific refusal reasons, mentions the requirement to use ONLY the tool result for extraction, and notes the extra LLM call cost. 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 dense but every sentence provides unique value: purpose, routing comparison, return structure, refusal behavior, use cases, and cost tradeoff. It is front-loaded with the core purpose and structured logically, earning a high score for conciseness without sacrificing necessary detail.

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

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

No output schema exists, so the description compensates by fully explaining both success and refusal return formats, including specific refusal reasons. Combined with the annotations and usage guidance, this makes the tool behavior completely predictable for an agent, even in complex high-stakes scenarios.

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

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

Schema description coverage is 100%, with the 'question' parameter and aliases fully documented. The description adds context about how the question is processed (routed to 5,467 tools) but does not provide additional param-level meaning. Baseline 3 is appropriate as the schema carries the weight.

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

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

The description clearly states the tool's purpose: a hallucination-resistant answer mode for high-stakes reads. It distinguishes itself from ask_pipeworx by explaining it uses the same routing but then extracts answers only from the tool result. This specific verb+resource identification sets it apart from siblings.

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

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

Explicit guidance is provided: use when answers will be quoted, cited, or acted on and facts must not be invented, with concrete examples like financial verdicts and legal claims. It also advises preferring ask_pipeworx for casual lookups due to the extra LLM call cost, giving clear when-to-use and when-not-to-use direction.

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

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

The description goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) by detailing fan-out behavior, response shapes, resolver contract, parent event extraction, news fallback mechanisms, safety short-circuits for low-confidence or closed markets, wide-spread handling, and resolution-rule risk. It provides complete transparency about what the tool does in various edge cases.

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

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

The description is lengthy but well-structured, starting with a high-level summary and then systematically covering classifiers, fan-out examples, response shapes, safety mechanisms, and edge cases. It front-loads key information but could be slightly more concise without losing critical details.

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

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

Given the tool's complexity (multiple classifiers, fan-out patterns, response shape variations, safety checks, cancellation rules), the description covers virtually every important scenario. It explains low-confidence matching, closed markets, wide spreads, resumption rules, and parent event extraction. No output schema is provided, but the description compensates with detailed response field explanations.

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 input schema already documents all three parameters with descriptions (100% coverage), the tool description adds significant meaning: it explains how the 'market' parameter can be a slug, URL, or question text; it describes the 'depth' enum and default behavior; and it clarifies the 'include_raw' parameter's impact on response size. This context helps the agent use parameters effectively.

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: to research a Polymarket bet by pulling relevant Pipeworx data in one call. It specifies inputs (slug, URL, question text) and outputs (evidence packet, market-vs-model comparison). It distinguishes itself from siblings like polymarket_edges and polymarket_arbitrage by focusing on comprehensive research rather than specific edge or arbitrage calculations.

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

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

The description explicitly states when to use the tool: for questions like 'should I bet on X', 'what does the data say about Y', or 'is there edge in Z'. It provides multiple examples and scenarios, but does not explicitly list when NOT to use it or recommend alternative sibling tools for specific cases.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds beyond annotations by detailing that results are sorted by primary metric, returns paired data with citation URIs, and explains what data is pulled for each type (e.g., latest 10-K for companies, FAERS for drugs). No contradictions.

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

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

Description is well-structured with example queries upfront and clear sections. It is slightly verbose but each sentence adds value; could be tightened but remains efficient.

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

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

Given only 2 parameters, no output schema, and comprehensive annotations, the description fully covers input semantics, data returned, sorting behavior, and citation format. It is complete for the tool's purpose.

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

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

Schema description coverage is 100%, but description adds substantial meaning: explains that type='company' pulls revenue, net income, cash, debt with off-calendar fiscal year handling, and type='drug' pulls adverse-event counts, FDA approvals, trial counts. This significantly enhances the enum 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?

Description clearly states it performs side-by-side comparisons of 2-5 companies or drugs in one parallel call. It uses specific verbs ('compare') and resources ('companies or drugs'), and distinguishes from sequential lookups by noting it replaces 8-15 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 instructs 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', giving clear context for when to use. Provides example queries, though it does not explicitly state when not to use (e.g., for in-depth single entity analysis).

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the tool never invents answers (gaps[]), uses parallel routing to 5,467 tools, returns citations only when fetchable, semantically excerpts large records, and discloses latency expectations (15-90s). Slight deduction because the description doesn't mention rate limits or quota usage despite the paid-plan note.

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 and starts with the most critical constraint (account required), but it is a large wall of text with many parentheticals and run-on sentences. It could benefit from short paragraphs or bullet-like separation of 'when to use', 'behavior', and 'performance'. Every sentence adds value, but structure/length hurt scannability.

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 tool with no output schema, the description comprehensively covers purpose, auth/plan requirements, alternatives, depth semantics, output structure (findings packet, gaps[], contradictions[], hop field, citation_uri), failure modes (empty gaps for non-catalog topics), and timing expectations. This is sufficient for an agent to select and invoke the tool correctly without further documentation.

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

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

Schema coverage is 100%, so the schema already documents both parameters, but the description adds meaningful context: it explains the 'depth' values in terms of facet counts and recovery hops ('quick=3, standard=5, thorough=8'), and clarifies that 'question' can be broad/multi-part and will be decomposed. This goes beyond the enum labels and justifies a score above the baseline of 3.

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

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

The description opens with a clear action verb ('Grounded multi-source research across Pipeworx's 1423 STRUCTURED data sources') and explicitly distinguishes itself from open-web search and from siblings like ask_pipeworx. It specifies the resource (structured data sources/tools) and the outcome (findings packet with citations and gaps).

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

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

The description gives explicit when-to-use guidance ('Best for broad/multi-part questions over structured data'), explicit when-not-to-use ('For a single lookup use ask_pipeworx... For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'), and names the alternative tool. It also explains depth-level trade-offs so the agent can select the right variant.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by explaining what is returned: top-N relevant tools with full input schemas and curated examples, ready to call. No contradiction.

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

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

Description is front-loaded with main purpose and usage. It lists many domains which is helpful but slightly verbose. Overall efficient and well-structured.

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

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

With 100% schema coverage and no output schema, the description fully explains what the tool returns and its purpose. Complete for a discovery-oriented tool with good annotations.

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

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

Schema coverage is 100%, so baseline is 3. Description includes examples but adds minimal extra semantics beyond what the schema already provides (aliases, limit).

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 it finds tools by describing data or task, listing many domains. It distinguishes from siblings by saying 'Call this FIRST' when you have many tools. Specific verb 'discover' and resource 'tools' are clear.

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

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

Explicitly says to call this first when many tools are available and you want to see options. Implies not for when you just want one answer. Does not explicitly name alternatives, but sibling list provides 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?

Adds behavioral context beyond annotations: mentions soft-failing of patents API, describes fan-out across sources, and lists return fields. Annotations already indicate readOnly, openWorld, idempotent, non-destructive; description reinforces and adds nuance. Lacks explicit error/rate limit info but sufficient.

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?

Effective front-loading with examples, then behavioral details. Dense but each sentence adds value. Could be slightly more structured (e.g., bullet lists) for readability, but remains concise and informative.

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 explains what is returned (cik, filings with URIs, fundamentals, patents, news, LEI) and how sources work. For a tool with 2 simple params, this provides full contextual completeness.

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

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

Schema coverage is 100%, so schema already describes parameters. Description adds value by reinforcing the name-not-supported constraint, clarifying that type is only 'company', and providing examples (ticker or CIK). This goes beyond the schema's brief 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 verb+resource ('full cross-source profile') and lists concrete outputs (cik, filings, fundamentals, patents, news, LEI). Example queries clearly communicate intent, and it distinguishes itself from sibling tools by explicitly recommending this tool over chaining single-pack lookups for holistic views.

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?

Includes explicit guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view' and states when not to use (names not supported, use resolve_entity first). Provides clear context for tool selection.

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

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

The description aligns with annotations (destructiveHint=true, idempotentHint=true) and adds behavioral context like clearing sensitive data. No contradictions.

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

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

Two sentences, front-loaded with the primary action, no wasted words.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately covers purpose, usage, and behavioral context, though could mention response or error behavior.

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

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

Schema coverage is 100% with a single parameter already well-described in the schema. The description does not add new parameter meaning beyond the schema.

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

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

The description clearly states the action ('delete') and the resource ('a previously stored memory by key'), and explicitly contrasts with siblings 'remember' and 'recall', distinguishing it effectively.

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

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

The description provides explicit context for when to use the tool ('when context is stale, the task is done, or you want to clear sensitive data') and mentions paired tools, but does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that it fetches external pages and extracts specific fields, which is valuable context. No contradictions. Lacks details on error handling or rate limits but acceptable given 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, well-structured paragraph with no wasted words. First sentence states purpose and process; second sentence lists use cases. Every sentence earns its place.

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

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

For a simple tool with 2 params and no output schema, the description fully explains inputs (URL, optional max_links), process (fetch, extract, emit), and output format (llms.txt markdown). 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 coverage is 100%, so the description adds limited value beyond restating schema details. It mentions 'any URL' and the default/max for max_links, but these are already in 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 clearly states the tool generates an llms.txt file for a URL, specifying the action (fetch, extract, emit) and the resource (URL). It distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on llms.txt generation.

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 concrete use cases (client indexing, own project drafting, competitor auditing) but does not explicitly state when not to use or name alternative tools. The context is clear enough for an agent to decide.

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, and non-destructive behavior. The description adds that the tool returns jurisdiction key, name, and current open-bid count, providing useful output structure beyond the annotations.

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

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

The description is a single sentence that efficiently conveys the tool's action and output, with no wasted words.

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

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

Given the tool's simplicity (0 parameters, no output schema), the description fully covers the needed context: what it lists and the fields returned. Complete for its intended use.

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

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

The input schema has zero parameters and 100% schema coverage. With no parameters, the description does not need to add parameter details, aligning with the baseline score of 4.

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

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

The description clearly states that the tool lists US city & county procurement portals covered by open_bids_search, providing the jurisdiction key, name, and open-bid count. It distinguishes itself from sibling tools like open_bids_search.

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 that this tool lists jurisdictions covered by open_bids_search, implying its use for retrieving that list. No explicit exclusions or alternatives are given, but the purpose is well-defined.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Description adds return field details but no additional behavioral traits such as pagination or rate limits.

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

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

Two sentences, zero waste. Purpose and usage are front-loaded, no redundant information.

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

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

Given one optional parameter, rich annotations, and no output schema, the description covers purpose, return format, and usage context. Could mention default filter (active only) but it's implied by parameter.

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 (include_inactive). Description does not elaborate beyond schema, so baseline 3 is appropriate.

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

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

Clearly states it lists the caller's active subscriptions and specifies returned fields (id, type, etc.). Verb 'list' and resource 'subscriptions' are specific, and it distinguishes from siblings 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 context: use to review monitoring before adding more or to find id for cancellation. Lacks explicit when-not but offers clear practical use cases.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Beyond that, description adds that results are updated daily, sorted by soonest close date by default, returns specific fields, and retains history for closed/all status. 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 a single paragraph but well-structured: starts with primary purpose, then details filters, then default behavior and alternatives. It includes examples naturally. Could be slightly more concise, but all sentences earn their place.

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

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

Given no output schema, the description explicitly lists return fields (title, reference number, awarding jurisdiction, close date, URL). With 5 parameters all described and no required fields, the description covers defaults and usage patterns completely. No gaps.

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

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

Schema description coverage is 100% (all 5 parameters described). Description adds value beyond schema by explaining that keyword matches solicitation title/reference, jurisdiction uses keys like 'fort-worth-tx', closing_within_days applies only to open bids, and limit has default 25 and max 100.

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 finds open US government bid solicitations (RFPs/RFQs/IFBs) that vendors can respond to, from city & county procurement portals. It specifies the verb 'find' and the resource 'open bids', and distinguishes from sibling tool gov_contracts_search for awarded contracts.

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 (for open bids) and when not ('for awarded contracts use gov_contracts_search'). Provides example queries like 'what is <city/county> currently bidding out' and explains that status can be set to 'closed' or 'all' to search past solicitations.

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

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

Goes far beyond the annotations by disclosing rate limiting (5 per identifier per day), the free/quota-free nature, the daily digest cycle, and the claim_token behavior when no account exists. Also clearly scopes the tool to only this Pipeworx connection. No contradiction with annotations.

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

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

The description is long but every sentence earns its place. It is front-loaded with the core purpose, then covers usage, exclusions, content rules, workflow, and limits in a logical order. Nothing is repeated from the schema, and no fluff exists.

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 nested parameters, claim_token flow, rate limits, and exclusions, the description covers all necessary decision points. The absence of an output schema is mitigated by the explanation of what a filing returns ('a claim_token' and later 'the status and, once resolved, what actually changed').

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?

Since schema coverage is 100%, a baseline of 3 applies, but the description adds meaningful parameter behavior: 'pass it back later as pipeworx_feedback({claim_token:"pwfb_…"})', message length guidance, and the distinction between bug/feature/data_gap/praise. This extra context makes the parameters more than just names and types.

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 'Tell the Pipeworx team something is broken, missing, or needs to exist,' a specific verb and resource. It enumerates exact use cases (bug, feature/data_gap, praise) and is clearly distinguished from sibling tools: it is the only feedback tool, while siblings are research or query tools.

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

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

Provides explicit when-to-use triggers (bug, feature/data_gap, praise) and an explicit exclusion: if the tool came from a different MCP server, file there instead. It also explains the correct content scope ('describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt') and the claim_token workflow, giving an agent full guidance on when and how 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 provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds meaningful context: source (CF analytics-engine), no PII, caching (5min-1h), and that it's self-aggregating. 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?

Three tightly packed sentences: main output, use cases (numbered), technical notes. Front-loaded with what it does, no fluff. Every sentence earns its place.

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

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

Despite no output schema, description explains return values (top tools, top packs, call volume). Covers caching, source, privacy. Complete for a read-only, non-destructive tool with simple parameters.

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 window parameter with enum and description (100% coverage). Description adds interpretation: 'Shorter windows surface what's hot right now; longer windows show steady-state demand,' adding behavioral guidance beyond schema.

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

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

Description clearly states it returns top tools, top packs, and call volume by window. Differentiates from siblings like discover_tools by focusing on trending usage rather than discovery. Specific verb+resource.

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

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

Explicitly lists 3 use cases (discovering hot data sources, confirming canonical choice, seeing alignment) and distinguishes window behaviors (short vs long windows). Lacks explicit when-not-to-use but covers key guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description greatly expands on this by detailing internal algorithms (partition check, monotonicity, Jaccard filter, placeholder filter), fill check logic, and output structure. No contradictions with annotations.

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

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

The description is well-organized with sections separated by blank lines and mode labels. It front-loads the core purpose and then details each mode. While slightly verbose, every sentence adds necessary context. A minor conciseness improvement could condense some technical 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 having no output schema, the description thoroughly documents the response structure (opportunities array with fields, partition_check object, fill check results). It covers all relevant aspects of the tool's behavior, including edge cases (placeholder filters, similarity thresholds) and practical trade advice (how to interpret fill check results).

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

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

Schema description coverage is 100% for both parameters, but the description adds significant extra meaning: explains event accepts slugs or URLs, topic takes seed questions, and describes the behavior triggered by each. This goes well beyond the schema to clarify parameter usage.

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

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

The description clearly states the tool's purpose: finding arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes between three usage modes (no args, event, topic) and separates itself from sibling tools like polymarket_edges and polymarket_fill_risk by specifying the unique algorithms and scan types.

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 each mode: no args for trending scan, event for specific market partition check, topic for cross-event scanning. It explains the benefits of topic mode (catches patterns missed by single-event) and warns against trading when fill check shows realizable_edge_pp ≤ 0. This gives 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 goes far beyond annotations by detailing caching behavior (1h KV), internal model families (crypto_price, news_momentum, partition_overround, concentrated_longshot), diagnostics, and special handling of Fed bets. All annotations (readOnlyHint, idempotentHint, etc.) are consistent with the described behavior.

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

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

The description is extremely verbose (500+ words) and includes unnecessary technical details about model formulas and specific parameters. The first sentence states the purpose well, but the rest is dense and could be structured more concisely for an LLM to parse quickly.

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

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

Given the complexity (9 parameters, no output schema, multiple model segments), the description is remarkably complete. It explains output structure (by_segment, fed_candidates, diagnostics), edge cases (why segments might be empty), and provides enough context for an agent to understand the tool's full behavior and output.

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

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

With 100% schema coverage, the baseline is 3. The overall description adds meaningful context beyond schema descriptions by explaining how parameters like min_kelly vs min_partition_leg_kelly interact, and the concept of 'tradeable-edge knobs'.

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

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

The description clearly states the tool scans top Polymarket markets for opportunities where Pipeworx data disagrees with market price, explicitly targeting 'what should I bet on today'. This is a specific verb+resource combination that distinguishes from sibling tools like polymarket_arbitrage.

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

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

The description provides clear context for when to use this tool (discovering betting opportunities) and detailed knobs to control output. However, it does not explicitly mention when not to use it or guide toward alternatives like polymarket_edge_tracker or polymarket_fill_risk.

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

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

Annotations indicate read-only, idempotent, non-destructive. The description adds significant behavioral context: data source (daily snapshots), derived fields (trend, decay rate), structure of response (tracked, expired, snapshot_dates), and limitations (60-day TTL, non-intraday). No contradictions.

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

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

Description is front-loaded with purpose and response structure. While slightly long, every sentence provides valuable information. No wasted words.

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

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

Despite no output schema, the description fully explains the response format (tracked array with fields, expired array, snapshot_dates) and includes limitations and caveats. Complete for a telemetry tool.

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

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

Schema coverage is 100% with clear descriptions for both parameters. Description restates defaults and adds context (snapshot family), but adds no meaning beyond what schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool provides edge persistence and decay telemetry from daily snapshots, answering a specific question ('how long has this edge existed and is it shrinking?'). It distinguishes from sibling tools like polymarket_edges (raw edges) and polymarket_arbitrage.

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

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

The description explains when to use the tool (to distinguish fresh vs. persistent edges) and gives context for interpretation. It doesn't explicitly list when not to use or alternative tools, but it's clear in 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?

Adds significant behavioral details beyond annotations: describes walking the order book ladder, return fields (top_of_book, vwap_fill_price, slippage, etc.), and warns that partial basket fills convert an arb into an unhedged directional position. No contradiction with annotations (readOnlyHint, idempotentHint, etc.).

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 well-structured with clear sections for single-market and basket. Every sentence adds value, though some redundancy could be trimmed. Front-loaded with core purpose.

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

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

Given the tool lacks an output schema, the description thoroughly explains all return fields (top_of_book, vwap, slippage, shares_filled, verdict, etc. for single-market; theoretical_sum, realizable_sum, capture_ratio, thin_legs, forced_directional_risk for basket). 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?

Despite 100% schema coverage, the description adds crucial meaning: explains how size_usd differs between single-market (spend/target) and basket (shares per leg), details side defaults, and clarifies the basket mode's interpretation of size_usd as settlement notional.

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

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

Clearly states the tool checks 'realizable-vs-theoretical edge against live CLOB order-book depth' and distinguishes two modes (single-market, basket). Specific verb and resource, differentiates from siblings like polymarket_arbitrage and 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?

Explicitly tells when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. Also provides prerequisites (REQUIRES market or event) and warns about pitfalls.

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

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

Discloses behavior beyond annotations: two modes, response structure, safety fields (compatibility_warning, temporal_alignment, skipped counters). No contradiction with readOnlyHint, openWorldHint, idempotentHint.

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 slightly verbose; however, every sentence adds value and it fronts the main purpose. Could trim some minor redundancies.

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 covers response fields (probabilities, spreads, safety fields) and explains complex cross-venue matching and compatibility detection, making it self-contained.

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

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

Schema coverage is 100%, and the description adds meaning: explains topic macro list, provides examples for explicit tickers, and clarifies override behavior for explicit parameters.

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

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

The description clearly states the tool computes the cross-venue spread between Kalshi and Polymarket, distinguishing it from sibling tools like polymarket_arbitrage which focus on intra-venue 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 describes two modes (topic shortcuts and explicit tickers) and explains when to use each. Details when compatibility_warning fires, advising users that most pre-mapped topics return warnings and are not tradeable.

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 scoping info (by identifier) and listing behavior when key omitted, enhancing transparency.

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

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

Three sentences, no wasted words, well-structured—purpose, usage context, scoping. Efficient and clear.

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

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

Simple tool with 1 optional param and good annotations. Description fully covers purpose, usage, scoping, and interaction with siblings. 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 already describes parameter well. Description adds examples of what keys store (ticker, address, notes) and clarifies listing behavior, adding beyond schema's 100% coverage.

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

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

The description clearly states the verb 'Retrieve' or 'list' and the resource 'saved memory keys', distinguishing it from sibling tools like '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 context for when to use (look up stored context like ticker, address, research notes) and pairs with remember/forget. Does not explicitly state when not to use, but 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?

The description states mark_read:true flags returned events read, which mutates state, contradicting the readOnlyHint=true annotation. This is a serious inconsistency, so score 1 as per contradiction rule. However, it does add behavioral details like polling suitability and alternative endpoint 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?

Four concise sentences, front-loaded with purpose, then key behavioral notes. No fluff, each sentence earns its place.

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

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

Given no output schema, description adequately covers return fields (source, citation_uri, raw payload), all parameters, and behavioral nuances. Also mentions alternative access method, making it self-contained.

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

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

Schema coverage is 100%, baseline 3. Description adds value by explaining mark_read's effect on future calls and practical uses of parameters (e.g., 'next call only shows newer ones'). Exceeds 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 explicitly states it pulls fired events from a subscription feed, returning most recent alerts with source, citation_uri, and raw payload. It clearly differentiates from siblings like list_subscriptions by focusing on events already written to the feed.

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

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

The description provides clear usage context: filtering by type and since, mark_read behavior, polling suitability, and alternative endpoint. However, it does not explicitly exclude scenarios or compare to siblings for 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 declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds granular behavioral context: fan-out to SEC EDGAR, GDELT→GNews fallback, USPTO soft-failure note, and output structure (changes grouped by source, total_changes, citation URIs). No contradictions.

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

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

Description is a single dense paragraph but front-loads key behavior and includes many examples. While every sentence adds value, it is slightly verbose and could be more structurally organized.

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

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

Given the complexity (multiple data sources, fallback, output format), the description covers all essential aspects: input constraints, behavior, output structure, and alternative tools. Since no output schema exists, the description explains the return format adequately.

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

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

Schema has 100% coverage with descriptions for all 3 parameters. Description adds further value by explaining supported formats for `since` (ISO date and relative shorthand like '30d', '1y'), and clarifies that `type` only supports 'company'. This goes 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 returns a change feed for a company in a recent time window, with specific examples like 'What's new with X' and 'latest on Y'. It distinguishes itself from sibling tool 'entity_profile' by explicitly stating when to use that instead.

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 this tool vs alternative 'entity_profile' for static profiles. Explains fan-out to multiple data sources, fallback behavior (GDELT→GNews), and gives parameter usage examples such as '7d' or '30d' for the `since` parameter.

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

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

The description adds significant behavioral context beyond annotations: scoped by identifier, persistent memory for authenticated users vs. 24-hour retention for anonymous sessions. Annotations already indicate idempotent and non-destructive, and description aligns with 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 moderately long but well-structured: each sentence adds value (purpose, usage, storage details, pairing). Not overly verbose, though slightly redundant with schema for parameter names.

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

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

The description covers key aspects (persistence, pairing), but does not mention return behavior or what happens on key collision. Given no output schema, a bit more detail would improve completeness.

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

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

Schema coverage is 100% with clear parameter descriptions. The description provides examples (e.g., 'subject_property') but adds no new syntax or format beyond schema. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later.' It specifies the scope (across conversation or sessions) and gives concrete examples. It distinguishes itself from sibling tools by mentioning pairing with 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?

The description explicitly states when to use: 'when you discover something worth carrying forward' and 'so you don't have to look it up again.' It also pairs with recall/forget, providing context, but lacks explicit 'when not to use' guidance.

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

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

The annotations already signal read-only and idempotent behavior, and the description adds valuable context: it discloses internal endpoint cascading, auto-disambiguation, and the exact return fields and citation URIs per entity type. This goes well beyond the structured metadata.

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

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

The description is moderately dense but well-organized with example phrases up front and a 'SUPPORTED TYPES' breakdown. Every sentence contributes to the agent's understanding, though it could be slightly tightened without losing 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?

With no output schema, the description compensates well by explicitly listing return fields for both supported types and describing input normalization. It covers the core usage and output interpretation needs, though it omits edge cases like ambiguous names or error behavior.

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

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

Schema coverage is 100%, so the baseline is met, and the description adds meaningful examples for the value parameter ('AAPL', '0000320193', 'ozempic') and explains what each type returns. It enriches the schema without unnecessary repetition.

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 resolves user-spoken names to canonical/official identifiers, with specific verb and resource. It also differentiates from siblings by noting the resolved IDs are required by other tools and by listing the supported entity types (company, drug) with concrete outputs.

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

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

It explicitly says 'Use FIRST whenever you have a name but need an ID' and defines the supported types and accepted input formats. While it doesn't name specific alternative tools or provide explicit when-not conditions, the context and positioning relative to other tools make the usage scenario clear.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds significant behavioral detail: it probes each entity with ai_visibility_check, ranks results, and returns a ranked list with score, confidence, signal density. It also notes the first entity is treated as the 'subject' for narrative. 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 two sentences with no wasted words. It is front-loaded with the main purpose and followed by a concrete example and return details. Every sentence is informative and earns its place.

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

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

Given 4 parameters, no output schema, and rich annotations, the description is complete enough for an agent. It explains the workflow (probes, ranks, returns) and the return format. It does not mention rate limits or edge cases, but overall it provides sufficient context for selection and invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add new parameter meanings beyond the schema; it only mentions the first entity is the subject, which adds slight context. Overall, the schema already documents all 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 compares AI visibility across multiple entities, probes each with ai_visibility_check, ranks by score, and surfaces most/least recognized. It is specific to competitive AI-marketing audits and distinguishes from sibling tools like ai_visibility_check (single entity) and compare_entities (generic).

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

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

The description provides a clear use case ('competitive AI-marketing audits') and an example query. It implies when to use (comparing multiple entities) but does not explicitly exclude alternatives or state when not to use it. Sibling tool ai_visibility_check is a natural alternative for single entity checks, but this is not mentioned.

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

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

The description adds significant behavioral context beyond annotations, including graceful degradation of partial failures, timing for bundlephobia first measurement (5-30s), and that sources_failed lists timeouts. 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 and provides essential details, but is somewhat lengthy. Every sentence earns its place, though minor trimming could improve conciseness without losing information.

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

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

Despite no output schema, the description thoroughly explains return values (summary block, advisories, links, alternative versions) and notes partial failures and timing. It is complete for an agent to understand what the tool returns and its behavior.

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

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

Schema description coverage is 100% for both parameters, so the description does not need to add much. The description provides context but does not add significant semantic meaning beyond what the schema already documents.

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

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

The description clearly states the tool performs a composite check for npm packages combining deps.dev and bundlephobia data. It specifies the ecosystem (NPM only) and distinguishes from sibling tools by noting other ecosystems fall under a different tool.

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

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

The description explicitly says 'Use whenever an agent asks is X safe / popular / small' and provides use case examples. It also mentions partial failures and timing caveats for bundlephobia, but does not explicitly state when not to use the tool.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description adds specific behavioral details: uses BGE-base-en embeddings with cosine similarity over 500-character overlapping windows, and a 200K char cap with truncation flagging. 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 five sentences long, each sentence adds value. It is front-loaded with the core purpose. It could be slightly more concise, but it is not verbose or wasteful.

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

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

Given no output schema, the description explains return values (passages with offsets and scores), mentions truncation behavior, and recommends pairing with another tool. It provides complete guidance for the agent to use the tool effectively.

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

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

The input schema already provides 100% description coverage for all three parameters. The description adds contextual usage advice but does not introduce new semantic meaning beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states it performs semantic search inside a fetched record, provides concrete examples (SEC 10-K, article), and specifies it returns top-N passages with offsets and scores. It distinguishes itself from siblings by mentioning how it pairs with ask_pipeworx_grounded.

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

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

The description explicitly advises using this tool when the record is too large for the prompt to save context, and pairs it with ask_pipeworx_grounded. It lacks explicit 'when not to use' statements but implies the context sufficiently.

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 claims each call creates a new subscription ('Returns the new subscription id'), implying side effects. However, annotations mark idempotentHint=true, which means the tool should be safe to retry without side effects. This contradiction indicates a serious inconsistency. The description does disclose delivery limitations and verification requirements, but the contradiction overrides any positive aspects.

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

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

The description is front-loaded with the main purpose. It is somewhat lengthy but every sentence adds necessary detail. No filler or tautology. The structure is logical: purpose, return value, requirements, types, delivery. Could be slightly condensed but remains efficient.

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

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

The description covers all essential aspects: creation action, return value, authentication prerequisites, supported subscription types with examples, delivery channels with constraints, and failure behavior (webhook auto-disable). There is no output schema, but the description adequately explains the return value. The tool is fully described for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. However, the description adds significant value by providing usage examples for each type (e.g., sec_8k with items), explaining delivery channel constraints (SMS cap, webhook signing secret), and clarifying prerequisites. This goes well beyond the schema's basic descriptions.

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

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

The description uses the verb 'Create' and resource 'proactive monitoring subscription to a live-data event stream'. It clearly distinguishes from sibling tools like list_subscriptions and unsubscribe by stating it creates a new subscription. Examples of supported types and delivery channels further clarify the purpose.

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

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

The description provides when to use (proactive monitoring) and prerequisites (Pipeworx OAuth account). It lists supported types with contextual examples. However, it does not explicitly guide when not to use or compare to siblings like recent_alerts, though the context is clear enough for most use cases.

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. Description adds valuable context: the function returns category-bucketed examples with exact tool+argument shapes drawn from a live catalog. It also explains the input behavior (no args vs optional topic). No contradictions.

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

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

The description is a single, dense sentence that front-loads trigger phrases and then explains the output and usage. It is efficiently structured but could be slightly more concise; however, it earns its length by providing essential detail.

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

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

Given that the tool is an onboarding entry point with one parameter and no output schema, the description covers what it returns, how to invoke it, and when to use it. It could hint at limits or caching, but overall it is complete enough for an agent to use 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 one optional parameter described. Description adds meaning by explaining that omitting the topic gives a full spread and that the topic focuses on a specific category, which goes beyond the schema's enum-like list.

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 category-bucketed example questions and is the onboarding entry point. Uses specific verb ('returns') and resource ('example questions'), and distinguishes from siblings by positioning as the first tool to use when unfamiliar with Pipeworx.

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

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

Explicitly says to use this tool first when the agent doesn't know what Pipeworx can do or to learn how to call meta-tools. Provides trigger phrases like 'what can I ask Pipeworx?' but doesn't explicitly state when not to use or name alternatives, though the 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?

Description adds ownership and deactivation details beyond annotations (idempotentHint, destructiveHint). Clarifies non-destructive nature and state change, aligning with annotations.

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

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

Two concise sentences front-load the action then add constraints. No extraneous content, each sentence adds value.

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

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

Covers purpose, ownership, and data effect. Lacks mention of return value or error behavior, but acceptable for a simple 1-param tool with 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?

Single parameter 'id' fully described in schema. Description adds that it is returned by subscribe, which is helpful but minimal; baseline 3 due to 100% schema coverage.

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

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

Clearly states it cancels a subscription by id, aligning with the title 'Unsubscribe from Alerts'. 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?

Explicitly mentions ownership enforcement and deactivation behavior, guiding when to use (own subscriptions) and what to expect (historical data preserved). Lacks explicit when-not scenarios but sufficient for context.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant value beyond these by detailing the internal routing logic (structured vs grounded pipeline), the nature of return values, and the fact that it consolidates multiple steps. 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 moderately lengthy but each sentence adds value. It front-loads with query patterns and quickly explains the dual pipeline. Slightly more concise could be achieved, but it is well-structured and informative 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?

Given no output schema, the description covers all necessary aspects: input parameters, internal behavior (dual pipeline), and output format (verdicts, citations, reasoning). It provides complete functional understanding for a complex tool with two parameters and no nested structures.

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. However, the description significantly enhances understanding by explaining the 'claim' parameter's natural-language scope with concrete examples, and the 'tolerance_pct' parameter's override behavior with recommended values for hallucination detection. This goes well beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: 'natural-language claim verification against authoritative sources' with specific example query patterns. It distinguishes from siblings by describing its unique dual-pipeline approach (SEC EDGAR vs grounded) and positioning it as replacing multiple sequential calls, which differentiates it from other fact-checking 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 explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It provides detailed context on handling company-financial claims versus other factual claims. While it doesn't explicitly list when not to use it or name alternatives, the guidance is clear and adequate for agent selection.

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