Noaa

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds behavioral details: default free model, BYO key for Anthropic with direct billing, and the structure of return data (per-model score, confidence, signals, raw_response, combined view).

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

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

The description is concise (two sentences) and front-loaded with the core purpose. Every sentence adds value, with no redundant or filler content.

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

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

Despite no output schema, the description explains what is returned (per-model or combined). All 4 parameters are covered, use cases are given, and behavioral aspects like cost implications are disclosed. The description is complete for the tool's complexity.

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

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

Schema coverage is 100%, but the description adds meaningful context beyond the schema: default model behavior, that _apiKey is needed only for Anthropic, and that context helps disambiguate common names. This helps the agent understand parameter usage beyond the schema's descriptions.

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

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

The description explicitly states the tool probes LLMs for knowledge about an entity and scores visibility per model. It specifies default model and optional Anthropic probe, and differentiates from siblings like scan_competitor_ai_presence by listing specific use cases (AI-marketing audits, pre-launch checks, competitive monitoring).

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: AI-marketing audits, pre-launch brand checks, competitive monitoring. While it doesn't explicitly exclude alternatives, the context is sufficient for an agent to decide when to use this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: automatic routing, argument filling, stable pipeworx:// citation URIs, 'one fast call', and that it works on every tier. It does not go into failure modes, rate limits, or detailed output structure, but the annotation coverage lowers the burden.

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

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

The description is longer than average but front-loaded with the most important directive ('PREFER OVER WEB SEARCH'). The content is organized into a coherent flow: preference, domain coverage, routing behavior, trigger phrases, examples, defaults, and step-up alternatives. Some redundancy exists between 'PREFER OVER WEB SEARCH' and 'START HERE', but no sentence feels wasted.

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

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

For a single-purpose routing tool with one required parameter, no output schema, and good annotations, this description is complete. It covers domain scope, examples, citation behavior, alternatives, and when to use it. Even without an output schema, it tells the agent what to expect: a structured answer with stable citation URIs.

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 covers 100% of parameters and already documents the 'question' param with aliases (q, text, input, query, prompt). The description reinforces usage with examples and trigger phrases but does not add meaning beyond what the schema 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 what the tool does: it routes questions to one of 5,529 tools across 1,455 verified sources and returns structured answers with citations. It uses a specific verb ('routes', 'returns') and distinguishes itself from siblings by explicitly naming ask_pipeworx_grounded and deep_research as alternatives for different use cases.

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?

This is exemplary. The description says 'PREFER OVER WEB SEARCH', 'START HERE for most questions', and gives explicit when-to-step-up guidance: use ask_pipeworx_grounded for hallucination-resistant single answers and deep_research for broad/multi-part questions. It also provides trigger phrases and examples.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context beyond this: the tool's experimental nature, live candidate routing changes, and the fact that 'Falls back to nothing — this IS a full working router, just the experimental edge.' It also discloses the current state (no active candidate) and the comparison process. This is strong supplementary behavior disclosure, though it could mention failure modes 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?

The description is front-loaded with the beta status and identity, then explains current state, usage, and fallback in four dense sentences. Each sentence adds essential information, but it could be slightly tighter (e.g., removing the exact date or the 'falls back to nothing' phrasing) without losing value. Still, it earns its length.

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 references ask_pipeworx for the response shape, grounding the agent's expectations. It also clarifies the router's full functionality and experimental differences. For a beta variant of an existing tool, this is sufficient context for correct selection and invocation, though more detail on return format or routing behavior could enhance 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?

The input schema has 100% coverage with all parameters documented as aliases for 'question'. The description does not add parameter-specific semantics beyond saying 'same arguments' as ask_pipeworx, which is a reference rather than additional meaning. With schema coverage so high, the baseline of 3 applies.

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

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

The description clearly states this is a beta version of ask_pipeworx, an 'identical universal router' with the same 5,529 tools, arguments, and response shape. It explicitly distinguishes it from the stable ask_pipeworx and other siblings by labeling it as the experimental edge with candidate routing improvements.

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

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

The description provides clear usage guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' It implies the alternative is the stable ask_pipeworx, and notes that results are compared to decide merges. However, it does not explicitly state when NOT to use it (e.g., for production stability), which would have made it a 5.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive, and the description adds significant context beyond this: the exact return shape, the set of possible refusal_reasons, and the behavior of extracting only from tool result. It also discloses the cost of an extra LLM call, all without contradicting annotations.

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

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

The description is compact and front-loaded with the core purpose, then flows logically through mechanics, return format, usage guidance, and cost comparison. Every sentence adds value, and specific details like refusal reasons are structured into a clear list.

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

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

Since there is no output schema, the description fully documents the return values and error/refusal cases. It covers usage trade-offs, cost implications, and high-stakes scenarios, making the tool's behavior complete for an agent to decide when and how to invoke it.

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

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

The input schema is fully self-descriptive with 100% coverage: all six parameters are aliases for 'question' with descriptions. The description adds no additional parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb and resource: 'Hallucination-resistant answer mode for high-stakes reads' with detailed mechanics (routing, fetching, extracting). It explicitly distinguishes itself from the sibling tool ask_pipeworx by emphasizing extraction based only on the tool result and a defined refusal behavior.

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

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

Provides explicit usage guidance: use when answers will be quoted, cited, or acted on, and for high-stakes domains like financial/legal/medical. It also names the alternative (ask_pipeworx for casual lookups) and mentions the additional cost trade-off, making when-to-use vs. when-not-to-use clear.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true. The description adds significant behavioral context: it resolves market, classifies, fans out, returns evidence packet, and details resolution confidence, parent events, news fallbacks, safety mechanisms, wide spreads, and cancellation rules. It also explains that closed markets return a specific status and skip fan-out. There is no contradiction with annotations; in fact, the description reinforces 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 long but structured with clear section headers (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.). It front-loads the core purpose and usage. Every section adds necessary detail for a complex tool. While not perfectly concise, the length is justified by the tool's complexity and the lack of output schema. A slight deduction for verbosity.

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

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

With no output schema, the description must explain all return fields and behaviors. It does so extensively: response shapes, resolver contract, parent event extractor, news field behaviors, safety mechanisms, wide spread handling, and cancellation rules. It covers edge cases like low-confidence matches, closed markets, and fallback attempts. This is extremely complete for the tool's complexity.

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

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

Schema coverage is 100% with detailed descriptions for all three parameters. The description adds extra context: for 'market', it lists the three input formats; for 'depth', it explains enum values and default; for 'include_raw', it explains when to use true vs false and the size implications. This goes well beyond the schema.

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

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

The description clearly states it researches a Polymarket bet by pulling Pipeworx data. It specifies exact input types (slug, URL, question text) and output (evidence packet + comparison). It distinguishes itself from siblings like 'polymarket_edges' and 'polymarket_arbitrage' by being a general research tool for any bet, while siblings are more specific. The purpose is unambiguous and complete.

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: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z".' It provides extensive examples of classifiers and fan-out scenarios. It also includes warnings about low-confidence matches, closed markets, and wide spreads, guiding the agent on when results may be unreliable. This is comprehensive guidance.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable behavioral details: sources (SEC EDGAR/XBRL for companies, FAERS for drugs), handling of off-calendar fiscal years, sorting by primary metric, and citation URIs. It does not discuss limitations like data staleness 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?

Very concise yet information-dense. Front-loaded with common query phrases, followed by clear preference guidance, then type-specific details. Every sentence adds value 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?

For a tool with 2 simple parameters and no output schema, the description covers the return format (paired data + citation URIs) and sorting behavior. It lacks details on error handling or what happens with invalid inputs, but overall sufficiently complete for an agent to use effectively.

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

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

Schema coverage is 100% with descriptions for both 'type' and 'values'. The description enriches by providing examples ('AAPL','MSFT'), entity-specific behavior, and constraints (2-5 items). This adds meaning beyond the schema alone.

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

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

The description clearly states the tool performs side-by-side comparison of 2-5 entities (companies or drugs) in a single parallel call. It lists trigger phrases like 'X vs Y' and 'rank these companies', and distinguishes itself from siblings by explicitly preferring over sequential single-pack lookups.

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

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

Provides strong guidance on when to use (comparing entities, ranking) and explicitly prefers this over sequential lookups. However, it does not explicitly exclude use cases like single entity lookup or non-comparative queries, though the context implies such.

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

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

The description discloses behaviors beyond annotations: it 'never invented' answers (with gaps[]), notes that citation_uri is 'present only when the source emits one that resources/read can actually serve', explains semantic excerpting of large records, and gives latency expectations. This adds substantial context not visible in the structured fields.

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?

Although long, every sentence earns its place: it front-loads the critical account requirement and fallback, then delivers purpose, usage guidance, behavior, and performance. The information is dense and logically ordered, with no filler or redundancy.

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

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

With no output schema, the description compensates by enumerating the findings packet fields (evidence, confidence, source, fetched_at, citation), explaining gaps[], contradictions[], hop, and citation_uri fetchability, and covering edge cases like unavailable citations and timeouts. This gives a complete mental model for a complex tool.

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

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

Schema coverage is 100% and the schema already describes both parameters. The description adds valuable nuance by noting that depth:"thorough" requires a paid plan, explaining standard/thorough re-angle gaps and chase leads, and confirming question accepts broad/multi-part input. However, it doesn't explicitly mention the 'quick' option, and much of the extra detail is a restatement of schema content.

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 verb+resource: 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources... in ONE call.' It explicitly contrasts itself with open-web search and gives concrete examples of suitable questions, making its scope unambiguous and easily distinguishable 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?

It provides explicit when-to-use vs alternatives: 'For a single lookup use ask_pipeworx', 'For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx', and 'If you are not signed in, use ask_pipeworx instead.' It also states the ideal scenario ('Best for broad/multi-part questions') and clarifies the depth tiers.

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

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

Annotations already indicate readOnlyHint: true, idempotentHint: true, destructiveHint: false. The description adds that it returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed,' providing valuable behavioral context about the return format and efficiency without contradicting 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 concise, front-loads the main purpose, and includes a list of example data domains. Every sentence adds value, though it could be slightly trimmed without losing impact.

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 role (discovery), the description fully explains what it does, how to use it, and what the return includes (schemas ready to call). No output schema is needed because the description covers the return value sufficiently.

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

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

Schema coverage is 100% with parameter descriptions. The description adds value by noting that query accepts multiple aliases (task, q, description, search) and gives examples, enhancing semantics 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 starts with 'Find tools by describing the data or task,' clearly stating the verb (find, discover) and resource (tools). It distinguishes from siblings by being a meta-tool for navigation, not a domain-specific query 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?

Explicitly states 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This provides clear when-to-use guidance and implies that for specific data, other tools are more appropriate.

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

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

Description adds behavioral context beyond annotations: fans out across multiple sources, returns specific fields, notes patent soft-fail until May 2025. Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description enriches without contradiction.

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

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

Description is detailed but every sentence adds value. Starts with clear examples, then explains functionality and limitations. Could be slightly more compact but overall efficient.

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

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

Given complexity (multiple sources) and no output schema, description fully explains return fields (cik, company_name, recent_filings, fundamentals, patents, news, LEI) and limitations (patents sunset, name restriction). Complete for 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 coverage is 100%, but description adds value by explaining the parameters (type only 'company', value as ticker or zero-padded CIK, names not supported) and provides examples. Enhances understanding beyond enum descriptions.

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

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

Description clearly states it provides a full cross-source profile of US public companies, with explicit examples like 'Tell me about X' and mentions specific sources (SEC, XBRL, USPTO, etc.). Distinguishes from siblings like resolve_entity by clarifying that names are not supported.

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

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

Explicitly advises to prefer this tool over chaining single-pack lookups for holistic views, and notes that names require resolve_entity first. Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description's 'delete' aligns but adds little beyond 'clear sensitive data' annotation. Did not contradict annotations.

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

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

Two sentences: first states action, second provides usage guidance. Front-loaded, efficient, no wasted words.

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

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

For a simple tool with one parameter and no output schema, the description fully covers purpose, usage, and relationships, leaving 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% and clearly describes the 'key' parameter. The description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the action ('delete') and the resource ('previously stored memory by key'), and distinguishes from sibling tools like 'remember' and 'recall'.

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

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

Explicitly states when to use (when context is stale, task done, clear sensitive data) and pairs with related tools 'remember' and 'recall', providing clear context and alternatives.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds process details: fetches page, extracts title/description/key links, emits markdown. 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?

Two sentences plus a 'Useful for' list. Front-loaded with core purpose, no filler. Every sentence adds value.

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

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

Tool is simple (2 params, no output schema) with rich annotations. Description covers mechanism, output format, and use cases. Fully complete for the tool's complexity.

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

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

Schema coverage is 100% (url and max_links described). Description mentions 'fetches the page' and 'extracts title/description/key links', adding context for url, but adds little beyond 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?

Description clearly states 'Generate a production-ready llms.txt file for any URL', specifying the verb (generate), resource (llms.txt file), and scope. 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?

Explicitly lists use cases: getting a client's site indexed, drafting your own, auditing a competitor. No explicit when-not-to-use, but context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. Description adds return fields and default behavior (active subscriptions), but does not add major behavioral insights beyond annotations.

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

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

Two sentences, no fluff, front-loaded with purpose and return fields. Every sentence adds value.

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

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

For a simple list tool with one optional parameter and no output schema, the description covers purpose, return fields, and usage context. Annotations cover safety. Complete.

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

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

Schema coverage is 100% (include_inactive described). Description mentions 'active subscriptions' aligning with the default, but does not explain the parameter further. Baseline 3 is appropriate.

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

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

Description clearly states it lists the caller's active subscriptions and enumerates returned fields (id, type, params, etc.). It distinguishes from sibling tools like subscribe and unsubscribe by focusing on listing.

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

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

Explicitly says 'Use this to review what you're monitoring before adding more or to find an id to cancel,' providing clear context. Does not explicitly mention when not to use it, but siblings are obvious.

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 (all false except readOnlyHint false), the description discloses the claim_token return/review mechanism, rate limiting (5 per identifier per day), and that it is free with no quota impact. This gives the agent a full picture of side effects and constraints, with no contradiction to annotations.

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

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

The description is compact yet information-dense: it opens with purpose, then flows through use cases, exclusions, content guidance, token mechanics, and limitations. Every sentence contributes distinct operational guidance; no filler.

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

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

Given the absence of an output schema, the description still explains what the caller receives (a claim_token) and how to use it later for status updates. It also covers prerequisites, content expectations, and service-level constraints, making the tool fully usable from the description alone.

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 covers all parameters with rich descriptions (100% coverage), so the baseline is 3. The description adds extra usage semantics: it cautions not to paste the end-user's prompt, explains that filing without an account returns a claim_token to later read status, and explicitly links claim_token usage to a prior filing. This goes beyond the schema and merits a 4.

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

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

The description opens with a clear verb+resource ('Tell the Pipeworx team') and enumerates the exact feedback categories (broken, missing, praise). It explicitly scopes the tool to this Pipeworx connection, effectively distinguishing it from all sibling tools that are research/search functions.

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

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

It provides explicit when-to-use triggers for bug, feature/data_gap, and praise, and an explicit when-not-to-use: feedback for tools from other MCP servers should be filed elsewhere. It also gives a method for disambiguation ('Pipeworx tool names are the ones this connection lists').

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 useful context: caching (5min-1h), no PII, data source (CF analytics-engine), and nature of data (self-aggregating signal). No contradictions.

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

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

The description is concise, uses bullet points for use cases, and front-loads the main purpose. Every sentence adds value 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 a simple tool with one optional param and no output schema, the description adequately covers inputs, outputs, caching, and use cases. It could specify the exact output structure but is sufficient for agent use.

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

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

Schema coverage is 100% and already describes the window parameter. The description adds value by explaining that shorter windows surface current hotness and longer windows show steady-state demand, which aids agent understanding.

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

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

The description clearly states the tool returns trending tools, packs, and call volume on Pipeworx, with specific verb and resource. It distinguishes itself from siblings like 'discover_tools' by focusing on real-time aggregated usage data.

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

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

The description provides three explicit use cases (discovering hot data, confirming canonical tools, aligning use cases). It does not explicitly mention when not to use it, but the context is clear enough.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds extensive behavioral context: algorithm details (monotonicity, partition checks), response structure, similarity threshold (0.30 Jaccard), partition filter (placeholder slugs), and fill check behavior (theoretical vs realizable edge). No contradictions with annotations.

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

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

The description is front-loaded with the core purpose, then structured into clear paragraphs for each mode, semantic anchor, partition filter, response, and fill check. Every sentence adds necessary information without redundancy. The length is appropriate given the tool's complexity.

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

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

Despite the lack of an output schema, the description comprehensively covers input, algorithm, constraints (similarity threshold, placeholder filter), output structure (opportunities[], partition_check, fill check results), and trade execution guidance. It also references a sibling tool for custom sizing, ensuring the agent has all needed context to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining each parameter's purpose, providing examples (event slugs, seed questions), and differentiating mode-specific behaviors. It also notes that full Polymarket URLs are accepted for event. This enrichment justifies a score above baseline.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket using monotonicity violations and partition-sum checks. It distinguishes itself from siblings like polymarket_edges and polymarket_fill_risk by detailing its unique approach and two modes (event and topic). The verb 'find' and resource 'arbitrage opportunities' are specific and unambiguous.

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

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

The description provides explicit guidance on when to use each mode: 'Call with NO args for trending_scan', 'pass event for strongest per-event partition_check', and 'pass topic for cross-event scan'. It recommends event mode for a specific market and explains cross-event mode catches patterns single-event misses. It also advises against trading when fill check shows realizable_edge_pp ≤ 0 and points to polymarket_fill_risk for custom sizing.

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 behavior. The description adds extensive behavioral context: detailed model methodology (e.g., lognormal barrier, GDELT ratio, partition_overround), response structure (by_segment, diagnostics), knobs (min_liquidity, max_spread_pp), and caching. 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 detailed but verbose, with extensive technical jargon (e.g., 'Fred 90d log-returns', 'GDELT 7d/21d article-volume ratio'). While it is structured with segments, it could be more concise for a tool description.

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, full schema coverage, and no output schema, the description is highly complete. It covers response structure, diagnostics, caching, edge cases (empty segments, Fed bets), and all knobs, leaving no obvious gaps.

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

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

Schema coverage is 100% with adequate descriptions for all 9 parameters. The description adds some context (e.g., slippage_pp explanation) but does not significantly enhance understanding beyond the schema. Thus 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 scans top Polymarket markets for opportunities where Pipeworx data disagrees with market price, specifically for 'what should I bet on today'. It uses a specific verb-resource combination and inherently distinguishes from siblings like polymarket_arbitrage by focusing on Pipeworx disagreement.

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 it is built for discovering betting opportunities without paging hundreds of markets, providing clear when-to-use context. However, it does not explicitly state when not to use or name alternative tools, stopping short of full usage guidelines.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive behavior. The description adds extensive behavioral details: response structure (tracked, expired, snapshot_dates), time-series computation, trend categories, and limitations (snapshot TTL, intraday vs daily data). No contradiction with annotations.

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

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

The description is well-structured and front-loaded with the core purpose. It is somewhat lengthy but every sentence contributes useful information about behavior, response, and limits. Minor reduction could improve conciseness.

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

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

Given the tool's complexity (no output schema, detailed response), the description is remarkably complete. It explains the entire response structure, data sources, computation logic, and limitations, leaving little ambiguity for the AI agent.

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

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

The input schema already has full coverage (100%) for both parameters, including defaults and constraints. The description repeats these details without adding new semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry. It answers a specific question about edge duration and trend, and distinguishes itself from the sibling 'polymarket_edges' tool by being a higher-level analysis built from its snapshots.

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 this tool (to understand edge age and decay) and provides context like history depth limits. However, it does not explicitly state when not to use it or list alternatives, though the sibling list implies alternatives exist.

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, non-destructive. Description adds substantial behavioral detail: walks order ladder, returns top-of-book, vwap, slippage, verdict, and warns about thin legs and forced directional risk. 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 relatively long but well-structured with clear sections (overview, single-market, basket, usage advice). Every sentence adds value given the tool's complexity. Could be slightly more concise but remains effective.

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

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

Despite no output schema, the description enumerates all return fields for both modes. Covers both operational modes, parameter defaults, and practical usage scenarios. Fully addresses the tool's complexity.

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

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

Schema coverage is 100% with descriptions. The description adds significant meaning beyond schema: explains size_usd differently for single-market vs basket, default side logic in basket mode, and clarifies parameters with examples.

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

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

The description clearly states the tool checks realizable vs theoretical edge against live CLOB order-book depth, explaining both single-market and basket modes. It distinguishes from siblings like polymarket_arbitrage and polymarket_edges by specifying when to use this tool before those.

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 before acting on arb signals or trades above ~$500, with reasoning about thin books and partial fills. Does not directly state when not to use, but context is clear. No explicit alternative tools mentioned, 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?

Annotations already show readOnlyHint=true, idempotentHint=true, etc. The description adds extensive behavioral context: it can warn about non-equivalent bet shapes, temporal mismatches, and provides counters for skipped comparisons. 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 relatively long but well-structured with clear sections for modes, response fields, safety fields, and caveats. Every sentence adds value, though some redundancy (e.g., re-listing topics) could be trimmed. Front-loaded with purpose and modes.

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 the response structure including leg-by-leg prices, top spreads, compatibility warnings, temporal alignment, and skipped counters. Covers edge cases and provides examples. Highly complete for a tool with 3 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 coverage is 100% with detailed descriptions for each parameter. The description adds value by explaining the interaction between topic and explicit parameter overrides, and by listing valid topic values. Could be slightly richer on parameter constraints but overall strong.

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

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

The description clearly states the tool computes cross-venue spreads between Kalshi and Polymarket for the same resolving question. It distinguishes from siblings like polymarket_arbitrage by specifying the multi-venue nature and provides specific use cases.

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 of use (topic shortcuts or explicit tickers) and provides guidance on when to use each. Warns that real spreads are rarer than the shortcut list suggests and explains compatibility/temporal alignment considerations, helping the agent choose appropriately.

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

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

Beyond annotations (readOnly, idempotent, non-destructive), the description adds scoping details ('Scoped to your identifier') and operational context (pairing with remember/forget). 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 long, front-loading the action and then providing usage context. Every sentence is informative without redundancy, making it highly efficient.

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

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

For a simple retrieval tool with no output schema, the description covers purpose, usage, scoping, and related tools. It does not explicitly state the return format (e.g., 'returns the stored value or a list of keys'), but this is inferable from context.

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

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

The schema covers 100% of parameters, so baseline is 3. The description adds value by explaining the effect of omitting the key (list all keys) and giving examples of typical key values, enhancing understanding beyond the schema.

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

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

The description explicitly states 'Retrieve a value previously saved via remember, or list all saved keys' with specific verb and resource. It distinguishes from siblings by naming 'remember' and 'forget' as related tools, making its purpose clear.

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

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

The description provides concrete examples of when to use the tool (e.g., look up user's target ticker, address, research notes) and contrasts with re-deriving info. It implicitly suggests its use over alternatives but lacks explicit 'when not to use' statements.

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. The description adds behavioral context: it specifies return fields (source, citation_uri, payload) and explains that mark_read:true flags events read, affecting future calls. 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 efficient (4 sentences) and front-loads the main purpose. It uses plain language. Could be slightly more structured (e.g., bullet points for parameters), but it is not verbose or rambling.

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

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

Given 5 optional parameters, no output schema, and annotations covering safety, the description is mostly complete. It explains return content and the polling-friendly nature. Minor gap: no mention of 'unread_only' behavior, but schema covers it.

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

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

Schema coverage is 100% with descriptions for all 5 parameters. The description adds examples (e.g., 'type' filter like 'sec_8k') and clarifies the effect of 'mark_read' beyond the schema's basic description, providing meaningful extra guidance.

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 retrieves recent alerts from a subscription feed using specific verbs ('Pull', 'Returns'). It distinguishes the resource but does not explicitly differentiate from siblings like 'list_subscriptions' or 'subscribe'.

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 filtering options (type, since), the effect of mark_read, and mentions an alternative feed URL for scripts/dashboards. It does not explicitly state when not to use this tool or compare directly to siblings, but provides clear usage context.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context: fan-out pattern, fallback from GDELT to GNews, the PatentsView API sunset issue, and return structure (changes grouped by source, total_changes count, citation URIs). No contradiction with annotations.

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

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

The description is a single paragraph that efficiently communicates all key information: purpose, usage examples, data sources, parameter details, return structure, and alternative tool. No redundant or irrelevant sentences.

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

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

Given the tool has 3 required parameters, no output schema, and moderate complexity with multiple data sources, the description fully covers functionality, parameter semantics, return format, and when to use an alternative. An AI agent has sufficient information to select and invoke this tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining 'since' accepts ISO date or relative shorthand with concrete examples, and 'value' accepts ticker or CIK. It also clarifies that 'type' is limited to 'company'. This adds value beyond the plain schema.

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

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

The description clearly states the tool's purpose as a change feed for a company, listing example user queries and specifying it fans out to multiple sources (SEC EDGAR, GDELT→GNews, USPTO). It also explicitly distinguishes from the sibling tool 'entity_profile' which provides static profiles.

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

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

Provides explicit when-to-use guidance with natural language examples, and directs users to use 'entity_profile' for static profiles. Also notes USPTO soft-fail condition, adding operational context.

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

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

Beyond annotations (idempotentHint=true), description adds persistence details for authenticated vs anonymous sessions (24-hour retention). 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 well-structured sentences front-load the purpose and usage, with no extraneous 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 low complexity (2 params, no output schema), description adequately covers behavior, persistence, and sibling relationships.

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

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

Schema covers both parameters with descriptions. Description adds value by providing concrete key naming examples (e.g., 'subject_property', 'target_ticker') 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 saves data for reuse, specifies it's a key-value store scoped by identifier, and distinguishes itself from sibling tools like recall and forget.

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

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

Explicitly tells when to use (discovering something worth carrying forward) and mentions pairing with recall and forget for complete workflow.

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

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

The description adds substantial behavioral context beyond the annotations: cross-source enrichment, source-labeled identifiers, explicit 'unresolved' reporting, graceful degradation when GLEIF/OpenFIGI is unavailable, and cascading internal lookups. These are non-obvious traits the agent would not otherwise know.

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

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

The description is front-loaded with example queries and a clear directive, then breaks down supported types in a structured way. It is somewhat verbose due to multiple paraphrased query examples, but every sentence adds useful 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?

With no output schema, the description carries the full burden of explaining return values. It thoroughly covers resolved identifiers, source provenance, unresolved handling, ownership data, and failure modes for enrichment services. For a two-parameter tool with this complexity, the description is comprehensive.

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?

Even though the schema already covers the two parameters, the description significantly enriches them by explaining accepted input forms (ticker, CIK, name; brand or generic drug name), output fields (CIK, ticker, LEI, FIGI, RxCUI, ingredient, brand), and enrichment fallback behavior—all beyond the schema's minimal 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 that the tool resolves user-spoken names into canonical/official identifiers needed by other tools, using the specific verb 'resolve' and naming exact outputs such as CIK, ticker, LEI, and RxCUI. The natural-language examples and 'Use FIRST' directive distinguish it from siblings like entity_profile and compare_entities.

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 details input formats for both company and drug types. It gives clear context but does not explicitly name alternatives or state when not to use the tool, stopping short of a 5.

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

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

Describes internal mechanism: probes each entity with ai_visibility_check and ranks results. Annotations indicate safe read-only operation, no contradiction. Additional context about ranking and output fields adds value beyond annotations.

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

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

Three sentences: main action, mechanism, usage example. Front-loaded with key purpose. 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?

Despite no output schema, description specifies return type: ranked list with score, confidence, signal density per entity. Covers all parameter semantics and use-case context adequately.

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

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

Schema coverage is 100% with descriptions for all 4 parameters. Description adds value by clarifying first entity is treated as 'subject' for narrative and rest as competitors, which is not in 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?

Clear verb 'Compare', resource 'AI visibility', and scope 'across multiple entities side-by-side'. Distinguishes from sibling ai_visibility_check (single entity) and compare_entities (likely generic comparison).

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

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

Explicitly states use case: competitive AI-marketing audits. Provides example query. Does not explicitly state when not to use, but context implies single-entity comparisons should use ai_visibility_check.

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

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

Annotations declare read-only, idempotent, non-destructive behavior. The description adds significant context: composite nature with two sources, graceful degradation for partial failures, timing caveats for bundlephobia first measurement, and specific return fields. 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 dense but efficient; every sentence provides necessary details. It front-loads the core purpose and then covers edge cases (ecosystem limitation, timing, error handling) in a logical order. No redundant or filler content.

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 (composite, multiple sources, partial failures, return structure), the description covers all relevant aspects: behavior, caveats (timing, ecosystem), return fields, and error handling. No output schema exists, but the description sufficiently explains return values.

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

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

Schema description coverage is 100% with clear parameter descriptions. The description adds minimal extra context (e.g., scoped packages accepted, version defaults to latest). With high schema coverage, a baseline of 3 is appropriate as the description does not substantially enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool performs a composite check for npm packages, combining deps.dev and bundlephobia, and explicitly contrasts with ecosystem-specific tools like deps.dev:version for other languages. It distinguishes from sibling tools by focusing on npm package vetting (safety, popularity, size).

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 the tool (e.g., 'is X safe / popular / small' or 'what does adding lodash cost me'), and notes limitations like NPM-only and potential delays from bundlephobia. However, it does not explicitly list exclusions or alternatives beyond mentioning deps.dev:version for other ecosystems.

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 rich behavioral details beyond annotations: embedding model (BGE-base-en), window size (500-char overlapping), similarity metric (cosine), character cap (200K chars) with truncation flag, and that passages carry offsets for verification. Annotations (readOnlyHint, idempotentHint) are consistent.

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

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

The description is well-structured and front-loaded with purpose and usage, followed by technical details. Every sentence adds value without redundancy. Length is appropriate for the information conveyed.

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

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

For a read-only search tool with 3 parameters and no output schema, the description covers the input, output (passages with offsets and similarity scores), constraints (200K cap), and pairings. It is sufficiently complete for an agent to understand and use the tool.

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

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

Schema coverage is 100%, so the schema already describes parameters. The description adds some context (examples for query, clarification for text) but does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool does semantic search inside a fetched record, specifying verb (search), resource (inside a record), and scope. It distinguishes from sibling tools by naming ask_pipeworx_grounded as a partner and implying exclusive use for searching within a specific text.

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

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

The description explicitly says when to use: 'Use when the record is too big to cram into the prompt' and provides a pairing workflow with ask_pipeworx_grounded. It does not explicitly state when not to use, but 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?

Annotations already indicate idempotent (safe to retry), non-destructive, and open-world. The description adds context beyond annotations: requires OAuth (not anonymous), per-type parameter specifics, delivery channel rules (SMS verification, 10/day cap, webhook auto-disable after failures), and the one-time return of webhook signing secret. 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 relatively long but well-structured: first sentence captures core purpose, followed by requirements, then bullet-style explanations for types and delivery channels. Every sentence adds information; no redundancy. Could be slightly more concise (e.g., merging some details into tables), but efficiency is good given the complexity.

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

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

Tool is complex (3 params, nested objects, 5 enums, 3 delivery methods, no output schema). The description covers all: type definitions, parameter constraints, delivery options with prerequisites (phone verification, webhook HTTPS-only), rate limit (10 SMS/day), and webhook failure behavior (auto-disable after 10 fails). It explains the always-on feed fallback. No gaps for a first-time user to understand usage.

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%, yet the description adds substantial meaning: it explains each type's parameter structure in detail (e.g., items codes for sec_8k, topics for polymarket_edge), clarifies optional-required constraints (clinical_trial needs sponsor or condition), and describes delivery object fields with real-world examples (phone verification, webhook HMAC signing). This goes well beyond the schema's minimal 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 strong action verbs ('Create', 'subscribe') and clearly identifies the resource ('proactive monitoring subscription to a live-data event stream'). It explicitly states the output ('Returns the new subscription id') and distinguishes from sibling tools like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation of persistent subscriptions.

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

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

The description explains when to use this tool (for proactive monitoring of live-data event streams), states a requirement (Pipeworx OAuth account), and lists supported types and delivery channels. It implicitly contrasts with pull-based tools like recent_alerts by noting that feed is always on and pullable. However, it does not explicitly exclude alternative scenarios or compare against other monitoring siblings like polymarket_arbitrage or validate_claim.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it returns 'category-bucketed example questions' drawn from a 'live catalog', and explains the effect of the topic parameter. 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 somewhat long but front-loaded with an extensive list of trigger phrases, making it easy to match. Every sentence adds information about purpose, usage, or behavior. Minor redundancy exists (e.g., listing categories twice), but overall it is well-structured and 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 the tool's simplicity (one optional parameter, no output schema), the description is complete. It covers what the tool returns, when to use it, and how to use arguments. The annotations handle safety. There are 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% (the only parameter is documented). The description adds meaning beyond the schema by listing example topic values and explaining the behavior when omitted ('full spread' vs. focused). This is helpful context that the schema alone does not provide.

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

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

The description starts with multiple natural language queries that clearly define the tool's purpose: onboarding for a new agent. It lists the categories of results and explicitly states it returns example questions with tool/argument shapes. Siblings like ask_pipeworx and deep_research are for direct queries or deeper research, not onboarding, so this tool is clearly distinguished.

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

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

The description explicitly states 'Use this FIRST when you do not yet know what Pipeworx can do for you' and explains when to use it vs. meta-tools. It also gives concrete guidance on the topic parameter and when to omit it. This is excellent usage 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?

Discloses non-destructive deactivation behavior beyond annotations, which already indicate destructiveHint=false and idempotentHint=true.

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

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

Two efficient sentences front-loading action then constraints. No fluff.

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

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

With one parameter, no output schema, and strong annotations, description fully explains behavior, constraints, and side effects.

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 id parameter fully (100% description coverage); description adds 'by id' but no new semantics.

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

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

Clear verb 'Cancel' and resource 'subscription by id'. Distinguishes from siblings 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?

Explicit ownership enforcement ('only cancel your own subscriptions') and states result (deactivation, not deletion) with forward reference to 'recent_alerts'.

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

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

Annotations already indicate readOnly/idempotent/non-destructive, so the description goes beyond by adding the internal pipeline routing, the exact verdict enum (confirmed / approximately_correct / refuted / inconclusive / unsupported / could_not_verify), the requirement for pipeworx:// citation, and crucially the semantic distinction between could_not_verify (check did not happen, not evidence) and unsupported (no source). 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 delivers material value: trigger phrases, routing logic, verdict list, error semantics, and efficiency rationale. It is front-loaded with purpose and examples, but a few sentences could be condensed without losing critical caveats.

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

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

Given the tool's complexity (two pipelines, nuanced verdict semantics) and the absence of an output schema, the description fully covers return types, citation format, error handling, and the distinction between inconclusive outcomes. It also explains why this tool replaces multiple sequential calls, giving the agent a complete mental model.

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, with detailed descriptions of claim and tolerance_pct including default behavior and use cases. The main description adds no extra parameter-level semantics beyond what the schema already covers, so a 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 uses specific trigger phrases ('Is it true that…', 'fact check', 'verify the claim') and clearly identifies the resource: natural-language claim verification against authoritative sources. It distinguishes itself from siblings by emphasizing the verdict-based output and the consolidated replacement of 4–6 sequential calls.

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

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

It explicitly states when to use: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also differentiates between company-financial claims (SEC EDGAR fast path) and other factual claims (grounded pipeline), and explains the meaning of could_not_verify vs unsupported. However, it does not explicitly name alternatives or provide a when-not-to-use scenario, so it falls just short of a 5.

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