Arcgis Pittsburgh

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable context: the default model is free (Workers AI Llama-3.3-70b), using Anthropic requires a BYO key with direct payment to Anthropic, and the return format includes score, confidence, signals, raw_response, and a combined view. It doesn't deep-dive into failure modes, but adds meaningful cost and output behavior.

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

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

The description is three sentences with no fluff. It front-loads the core purpose, then covers key parameters and use cases, and every sentence contributes new information. It's succinct while comprehensive.

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

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

The tool has 4 parameters, no output schema, and moderate complexity. The description covers the return structure ('Returns per-model {score, confidence, signals, raw_response} + a combined view'), parameter behavior for models and API key, and real-world use cases. This is sufficient context for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying the default model ('Default model is Workers AI Llama-3.3-70b (free)') and the relationship between _apiKey and the models parameter ('pass _apiKey to also probe Anthropic'). This enriches the schema definitions for models and _apiKey.

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

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

The description clearly states the tool's function: 'Probe one or more LLMs for what they know about a business / brand / product / topic and score visibility (0-100) per model.' It uses a specific verb ('probe') and resource (LLMs) and differentiates from siblings like ask_pipeworx by focusing on visibility scoring rather than general Q&A.

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

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

The description gives explicit use cases: 'Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also explains when to use the optional Anthropic key and default model. However, it doesn't explicitly contrast with sibling tools like scan_competitor_ai_presence, leaving some ambiguity for similar-sounding tools.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavioral context: it routes to 5,529 tools, fills arguments, returns structured answers with stable pipeworx:// citation URIs, and is 'one fast call'. It does not mention potential latency, error handling, or rate limits, but the annotations cover the safety profile, so the added behavioral detail earns a 4.

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 the description is longer than average, it is front-loaded with the critical 'PREFER OVER WEB SEARCH' directive and organized logically: scope, mechanism, triggers, examples, alternatives. Every sentence contributes actionable information, and no fluff is present. Given the tool's complexity, the length is appropriate and well-structured.

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

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

The description covers all necessary context: what the tool does, how it works, when to use it, when to escalate to siblings, and what the output looks like (structured answer with citation URIs). With no output schema present, the description explains the return format. The examples and alternatives make it complete for an AI agent to select and invoke correctly.

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

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

The input schema has 100% description coverage, including the primary 'question' parameter and five aliases with clear descriptions. The description enhances parameter semantics by providing concrete example questions and specifying the natural-language style of input, which goes beyond the schema's coverage. Although no new syntax is added, the practical usage examples justify a 4 rather than the baseline 3.

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

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

The description clearly states the tool's function: routing natural language questions to one of 5,529 tools across verified sources and returning structured answers with citations. It distinguishes itself from siblings like ask_pipeworx_grounded and deep_research by positioning itself as the default entry point and describing its scope (SEC filings, FDA data, news, etc.). The verb 'ask' plus the resource 'pipeworx' is specific and unambiguous.

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

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

The description explicitly says to prefer it over web search and provides a comprehensive list of trigger phrases ('what is', 'look up', 'find', etc.) and concrete examples. It also gives clear when-not-to-use guidance: use ask_pipeworx_grounded for hallucination-resistant answers, deep_research for broad/multi-part questions, and notes that breaking news is already covered. This is exemplary usage 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 cover read-only, idempotent, and non-destructive behavior. The description adds valuable context: it is experimental, routes to the same tools, has no fallback, and results are compared against the stable router. It also discloses the current inactive candidate state. 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?

Four sentences, each carrying substantive info: definition, current status, usage directive, and clarification about being a full router. Slightly verbose but every sentence earns its place, and the key facts are front-loaded.

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

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

The description covers experimental nature, routing improvements, comparison methodology, current state, and that it is fully functional. It references the same response shape as ask_pipeworx, which suffices given the absence of an output schema. No major gaps for a beta variant.

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

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

Schema coverage is 100%, with all six parameters described as aliases for 'question'. The description adds no parameter-specific meaning beyond the schema, but it does mention 'same arguments' as ask_pipeworx, which is a minor reinforcement. 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 is a 'Beta version of ask_pipeworx' acting as an 'identical universal router' with the same 5,529 tools, arguments, and response shape. It distinguishes itself from the stable ask_pipeworx by noting it includes candidate routing improvements and current status. The verb/resource/scope is explicit.

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

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

The description explicitly says 'Use it exactly like ask_pipeworx when you want the newest routing' and contrasts with the stable router. It implies when-not by positioning this as the experimental edge. It does not mention alternatives like ask_pipeworx_grounded, but provides clear context for selection.

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

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

Goes beyond annotations by disclosing the extra LLM call cost, the exact return shape ({answer, evidence, confidence, source, fetched_at, refusal_reason}), and the explicit refusal reasons (not_in_source, no_tool_match, etc.). It also notes the tool uses 'ONLY what the tool result contains' to prevent hallucination, which is key behavioral context not present in 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 efficiently organized: it states the mode, contrasts with ask_pipeworx, describes the return contract, and gives usage trade-offs. Every sentence adds value, though a couple of technical details (like exact refusal strings) could be trimmed without losing core guidance.

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

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

With no output schema, the description fully explains the return structure and all refusal reasons. It also covers use cases, cost trade-off, and how it relates to a sibling. This is more than enough for an agent to decide when and how to invoke it correctly.

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

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

The input schema already documents all six parameters, with five as aliases for 'question' and 100% coverage. The description adds no further parameter-specific meaning beyond implying the question is in natural language. Since schema coverage is high, baseline 3 is appropriate; the description does not need to compensate.

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

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

The description states a clear, specific purpose: it is a 'Hallucination-resistant answer mode for high-stakes reads' that routes like ask_pipeworx but extracts answers only from tool results. It names a sibling tool (ask_pipeworx) and distinguishes its behavior, making it immediately clear what it does.

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

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

Provides explicit guidance: 'Use whenever an answer will be quoted, cited, or acted on' and 'prefer ask_pipeworx for casual lookups.' It also lists example domains (financial verdicts, legal claims, medical lookups) where grounded answers are critical, giving the agent actionable decision criteria.

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

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

The description goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint). It discloses important behavioral traits: resolver confidence levels, safety short-circuiting (status:'low_confidence_match'), handling of closed/dead markets, wide-spread tradeability flags, cancellation rule parsing, and news fallback behavior. These details are crucial for an agent to understand the tool's guarantees and caveats.

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

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

The description is long but well-structured with uppercase section headers (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, etc.) and a front-loaded core purpose. Every sentence adds useful information, and the fan-out examples are illustrative without being redundant. While it could be trimmed, the length is justified by the tool's complexity, making it appropriately sized.

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 takes full responsibility for explaining return values. It thoroughly documents response shapes (market, analysis, evidence), resolver contract (market_match_confidence, alternatives, suggestions), parent_event extraction, news fields, safety statuses, and cancellation rules. It also covers edge cases like GDELT rate limiting and wide spreads. This makes the tool self-explanatory despite missing an output schema.

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

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

The schema covers all 3 parameters and has 100% description coverage (baseline 3). The tool description adds extra meaning by explaining the market parameter's flexible input forms, the depth parameter's impact on fan-out (quick vs thorough), and include_raw's size implications (~20KB vs 50-500KB). This additional context elevates the score above baseline.

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

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

The description clearly states the tool's function: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It specifies the input types (slug, URL, or question text), the processing pipeline (resolve, classify, fan out), and the output (evidence packet + market-vs-model comparison). It also gives concrete use cases and distinguishes from sibling tools like polymarket_edges by focusing on a single bet.

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

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

The description explicitly lists when to use the tool: 'should I bet on X', 'what does the data say about Y', or 'is there edge in Z'. It also provides classifier categories and fan-out examples, giving strong contextual guidance. However, it does not explicitly mention alternatives or when not to use it, so it stops 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context: it runs in one parallel call, handles off-calendar fiscal years (e.g., AAPL, NVDA), sorts results by primary metric, and returns paired data + citation URIs. It also mentions data sources (SEC EDGAR/XBRL, FAERS), enriching the agent's understanding beyond annotations.

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

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

The description is fairly long but every sentence delivers critical information—trigger phrases, type-specific behaviors, sorting, and efficiency gains. It is front-loaded with usage examples and maintains a logical flow. Slightly dense but not bloated.

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 two entity types and an array parameter, the description fully explains what data is returned (paired data + citation URIs), how results are ordered, and why it replaces many sequential lookups. It compensates for the absence of an output schema, making the tool's behavior predictable and complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by detailing exactly what each type pulls: company type retrieves 10-K revenue, net income, cash, and long-term debt; drug type retrieves FAERS adverse-event counts, FDA approval counts, and active trial counts. This helps the agent understand parameter implications, meriting 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 uses the specific verb "compare" with a clear resource (companies or drugs), and states the scope (side-by-side, 2-5 entities in one parallel call). It explicitly differentiates from sequential single-pack lookups, making it distinct from sibling tools like entity_profile and resolve_entity.

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

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

The description lists exact user query patterns ("Compare X and Y", "which is bigger", "rank these companies") and explicitly states "ALWAYS PREFER over sequential single-pack lookups when comparing entities." It also distinguishes between company and drug use cases with type-specific data pulled, providing clear when-to-use guidance.

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

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

The description goes well beyond the annotations (readOnly, openWorld, idempotent, destructive) by adding behavioral details: 'returns explicit gaps[] for facets the data couldn't answer (never invented)', 'contradictions[] flagging findings', 'Large records are semantically excerpted to the passages relevant to each facet', 'citation_uri ... present only when the source emits one that resources/read can actually serve', and expected latency '15-60s (thorough ... up to ~90s)'. These are rich, non-obvious traits that meaningfully inform an agent's expectation and invocation.

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

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

The description is long, but every section adds operational value: account requirement, alternative tools, return packet details, gap/contradiction behavior, citation resolvability, excerpting, timing. It is front-loaded with the most critical gate ('ACCOUNT REQUIRED'). However, there is some redundancy with the schema's depth descriptions (e.g., 'standard ... gap-recovery hop' and 'thorough ... paid') which mildly inflates length without new 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?

The description covers inputs (natural-language question, depth), outputs (findings packet with evidence, confidence, source, fetched_at, citation_uri, gaps[], contradictions[], hop field), limitations (structured data only, not live news), alternatives (ask_pipeworx), auth requirements, timing, and edge cases (large records excerpted). No output schema exists, so the description carries full responsibility, and it does so comprehensively.

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

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

The schema already covers both parameters (question and depth) with 100% description coverage, including enum values and their meaning. The description adds value by noting that the question can be 'Broad/multi-part is fine — decomposition is the point' and that depth levels have hop behavior, but this largely repeats schema info. The additive 'decomposition is the point' phrase justifies a 4 rather than a baseline 3.

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

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

The description clearly states the tool's purpose: 'Grounded multi-source research across Pipeworx's 1455 STRUCTURED data sources ... in ONE call' and explicitly distinguishes it from open-web search and from ask_pipeworx for single lookups. It also specifies the key action: decomposing questions into facets and routing them in parallel across 5,529 tools. This is a specific verb+resource statement that differentiates it from siblings like ask_pipeworx 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?

The description provides explicit when-to-use and when-not-to-use guidance. It says 'Best for broad/multi-part questions over structured data', '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 notes the paid requirement for 'thorough' depth, giving clear alternatives and exclusions.

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

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

Beyond the readOnly/idempotent annotations, the description adds concrete behavioral details: it returns top-N relevant tools including names, descriptions, and full input schemas, and states that results are ready to call directly with no second schema lookup. This gives the agent clear expectations of the output format and workflow impact.

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 structured into three purposeful sentences: purpose, usage/domains, and output/usage priority. The domain list is lengthy but informative, and the description avoids unnecessary filler, earning a high score for efficiency.

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 discovery tool with one primary parameter and no output schema, the description accurately covers the input (query), the output (top-N tools with schemas), and the recommended invocation context. It is self-sufficient for an agent to decide when to use it and what to expect.

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

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

The input schema already provides 100% coverage for all parameters, including aliases and examples, so the baseline is 3. The description only reiterates 'describing the data or task' for the query parameter and lists example domains, but does not add new semantic detail beyond what the schema already offers.

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

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

The description clearly states the tool's function: 'Find tools by describing the data or task.' It specifies the verb (find) and resource (tools), and lists concrete data domains (SEC filings, FDA drugs, etc.), distinguishing it from sibling tools that perform data searches or analyses rather than tool discovery.

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

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

The description gives explicit when-to-use guidance: 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' It implies when not to use it (when you need a direct answer), but does not name specific alternative tools, falling short of the highest benchmark.

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 (readOnly, openWorld, idempotent, non-destructive), the description reveals significant behaviors: it fans out across SEC EDGAR, XBRL, USPTO, news, and GLEIF; returns specific fields with details like 'up to 5' filings and 'LATEST 10-K'; notes the patents API sunset and soft-fail; and explains the GDELT→GNews fallback. This is rich, non-redundant behavioral disclosure.

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 dense, single paragraph but well-organized: examples first, then the core purpose, then the fan-out details, then return fields, then unsupported inputs. Every sentence contributes value, though it could be slightly shortened without losing key tradecraft. It is appropriately sized for the tool's complexity.

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

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

Given there is no output schema, the description fully compensates by enumerating exactly what is returned (cik, company_name, recent_filings with URIs, fundamentals fields, patents, news, LEI). It also covers edge cases like patent API sunset, fallback behavior, and input restrictions. For a tool of this complexity, the description is essentially 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?

The input schema already covers both parameters thoroughly with examples and constraints (enum, zero-padded CIK, names not supported). The description adds value by reiterating the accepted input forms ('AAPL' or '0000320193') and reinforcing the resolve_entity flow for names, but most semantic weight is already in the schema. A 4 is appropriate since the description does add meaningful usage context beyond the schema.

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

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

The description clearly states the tool's purpose: to produce a full cross-source profile of a US public company in one parallel call. It provides multiple example phrasings ('Tell me about X', 'company profile for Microsoft') and explicitly distinguishes itself from sibling tools by saying to prefer it over chaining single-pack lookups and to use resolve_entity if only a name is available.

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

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

The description gives explicit usage guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also states exclusions: names are not supported and resolve_entity should be used first if only a name is given. This clearly tells the agent when to use this tool and when not to.

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

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

The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the operational safety profile. The description adds usage scenarios and 'previously stored' but does not disclose additional behavioral traits such as handling of non-existent keys, error behavior, or permanence. Given the annotations, the description's contribution is marginal, so a score of 3 is appropriate.

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

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

The description is concise, with two sentences that are front-loaded with the core action ('Delete'). The first sentence defines the operation, the second provides usage guidance and sibling context. There is no redundancy or filler, and every sentence earns its place.

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

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

For a simple one-parameter deletion tool, the description provides essential context: purpose, when to use, and relationship to sibling tools. The annotations cover destructive and idempotent behavior, and the schema fully documents the parameter. It does not mention return values or error handling, but given the simplicity and annotation coverage, this is a minor gap.

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

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

The input schema fully documents the single required 'key' parameter with description 'Memory key to delete.' The description essentially restates this ('by key') and adds minimal semantic detail. With schema coverage at 100%, the baseline score of 3 applies; the description does not compensate or add 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 opens with a clear action ('Delete a previously stored memory by key'), specifying both the verb and resource. It distinguishes itself from sibling tools by mentioning 'Pair with remember and recall,' which places it within a memory-management family and makes its deletion role unambiguous.

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

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

The description explicitly states when to use the tool: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also references 'remember' and 'recall' as complementary tools, providing a clear mental model. However, it doesn't explicitly state when not to use it or contrast with alternatives beyond the pairing.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful process details: it fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format. It also clarifies the output as a single text blob intended for site-root/llms.txt. There is no contradiction with annotations, and the added context goes beyond what the annotations provide.

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

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

The description is three sentences long, with the main action front-loaded. Each sentence adds distinct value: what it does, how it works, and when to use it. There is no redundancy or filler, making it appropriately concise for the information it conveys.

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

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

This is a simple tool with two parameters and no output schema, so the description carries the responsibility of explaining behavior and results. It covers the purpose, process, output format, and use cases comprehensively. The annotations handle safety and mutability. No significant gaps remain for an agent to select and invoke the tool correctly.

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

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

The input schema covers both parameters (url and max_links) fully with descriptions, so the baseline is 3. The description does not add any additional meaning for max_links, but it reinforces that url is a full URL by saying 'any URL' and mentioning site-root placement. Since schema coverage is 100%, the description is not required to compensate.

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

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

The description clearly states the verb and resource: 'Generate a production-ready llms.txt file for any URL'. It goes beyond a simple statement by detailing the process (fetches, extracts, emits) and the output format, making it easy for an agent to understand exactly what the tool does. The 'Useful for' list clarifies distinct use cases, distinguishing it from any potential sibling that might audit AI visibility or scan competitor presence.

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

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

The description provides a 'Useful for' section with three explicit scenarios, giving clear context on when to use this tool. It does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5, but the use cases and the 'any URL' scope make the conditions for use reasonably explicit.

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, so the safety profile is covered. The description adds what information is returned but does not disclose potential behavioral traits such as performance implications of fetching total record count or any network-specific considerations.

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

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

The description is a single, well-structured sentence that front-loads the core action ('Get an ArcGIS Feature/Map Service layer's schema') and efficiently lists the key outputs. There is no wasted text.

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 read-only tool with one well-documented parameter and rich annotations, the description is complete. It explicitly lists the main return values (fields, geometry type, record count, capabilities), and no output schema is needed given this clarity.

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

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

The input schema already provides full coverage of the 'url' parameter with a clear description and example. The description does not add substantial meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: to retrieve an ArcGIS layer's schema, listing specific components (fields, geometry type, record count, capabilities). It uses a specific verb and resource, but does not explicitly distinguish it from sibling tools like query_layer or search_within.

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

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

The description implies the tool is used when a layer's schema is needed, but it does not provide explicit guidance on when to use it over alternatives or any exclusions. There is no mention of alternatives like query_layer for data queries, so usage context is only implicit.

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, so the safety profile is covered. The description adds value by listing the exact returned fields and clarifying that only active subscriptions are returned by default ("active subscriptions"), which goes beyond the annotations.

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

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

The description is two sentences, front-loaded with the action and resource, and every word earns its place. It efficiently covers purpose, return values, and usage context 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?

This is a simple list tool with one optional parameter and no output schema. The description covers purpose, return fields, and use cases, while annotations cover side-effect safety. Nothing further exists to disclose.

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 single parameter include_inactive is fully described in the schema (100% coverage), so the baseline is 3. The description reinforces the active-subscription default but does not add new parameter-specific meaning beyond the schema.

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

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

The description uses a specific verb ("List") with a clear resource ("the caller's active subscriptions") and explicitly enumerates the returned fields. It clearly distinguishes from sibling tools like subscribe and unsubscribe by focusing on read-only access to existing 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 explicitly tells when to use this tool: "before adding more" (i.e., before subscribing) and "to find an id to cancel" (i.e., before unsubscribing). This provides clear context and practical use cases, effectively guiding the agent to the right 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 are all false (no hints provided), so the description carries the full burden of behavioral disclosure. It does this thoroughly: explains the claim_token flow for anonymous filing, token-based status retrieval, daily rate limit ('5 per identifier per day'), that it is free, and that the team reads digests daily. This goes far beyond the structured annotations.

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

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

The description is long but every sentence carries unique information: purpose, use cases, exclusions, token mechanics, team behavior, rate limits, and quota. It is front-loaded with the main purpose and then branches into specifics. While it could be trimmed slightly, the length is justified by the tool's conditional behavior and multiple contexts (bug/feature/praise, account vs anonymous).

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

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

The description is complete for a feedback tool of this complexity. It covers all important facets: what to report, what not to report, which servers qualify, the token-based follow-up, rate limits, and that it's free. No output schema is provided, but the description explicitly mentions the return token, so the agent knows what to expect. The nested context object is documented in the schema, and the description reinforces its 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%, so the baseline is 3. The description adds significant value beyond the schema by explaining the claim_token workflow ('Filing without an account returns a claim_token; pass it back later...') and reminding the agent not to paste the end-user's prompt. It does not elaborate on every parameter, but the schema already covers them; the extra context for claim_token lifts it above baseline.

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

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

The description clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It uses a specific verb ('tell' / 'send feedback') and resource (Pipeworx team), and distinguishes itself from sibling tools by being the only feedback channel. The enumeration of feedback types (bug, feature, data_gap, praise) adds further precision.

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

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

The description gives explicit when-to-use guidance: 'Use when a tool returns wrong/stale data (bug)...' and also explicit exclusions: 'ONLY for tools served by this Pipeworx connection... if the tool came from a different MCP server... file it with that server instead.' This clearly directs the agent away from inappropriate use and even helps disambiguate which tools are Pipeworx-owned.

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 (readOnly, openWorld, idempotent), the description adds valuable behavioral details: data source ('derived from CF analytics-engine'), privacy guarantee ('no PII'), and cache behavior ('Cached 5min-1h depending on window'). These go beyond structured fields and help the agent set expectations.

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 sized and front-loaded with the main purpose. Each sentence contributes value, though the 'Useful for' list is slightly verbose. Overall, it is well-structured and does not waste words, earning a 4.

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 appropriately explains the return content ('top tools, top packs, and total call volume' and '(pack, tool, count)'). It also covers use cases, data source, privacy, and caching. Minor details like ordering or limits are omitted but not critical for this simple tool. A 4 is warranted.

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

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

The input schema already provides a thorough description for the 'window' parameter, including the enum values and explanation of shorter vs. longer windows. The tool description mentions the window but adds no new meaning beyond the schema. With 100% schema coverage, 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 states exactly what the tool does: 'Returns the top tools, top packs, and total call volume over a recent window.' It uses a specific verb ('Returns') and resource ('top tools, top packs, and total call volume'), clearly distinguishing it from sibling tools like discover_tools or search_datasets by focusing on aggregate call volume.

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

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

The description explicitly lists three 'Useful for' scenarios, providing clear context on when to use the tool. It does not explicitly name alternatives or exclusions, but the use cases are specific enough to guide an AI agent effectively. This earns a 4 rather than 5 because it lacks explicit 'when not to use' guidance.

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

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

Annotations only declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive; the description adds extensive behavioral context: it walks child markets, computes partition sums, filters placeholder slugs, surfaces skipped_low_similarity, and describes what the response contains. It even discloses that a theoretical edge may not be realizable at the book depth, which goes far beyond what annotations imply. 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 dense and well-organized with clear section labels (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK) and front-loaded purpose. Every sentence adds operational detail, from Jaccard threshold to placeholder fraction, without filler. The structure mirrors the tool's rich internal logic, making it easy to scan.

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

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

Given the tool's complexity and the absence of an output schema, the description is fully self-sufficient: it explains the two modes, the response fields (opportunities[], partition_check, gap_pp, suggested_trade), the fill-check mechanism, and edge cases like realizable_edge_pp. It also covers the conditions under which no signal is returned (placeholder fraction >20%), making the tool's behavior predictable in all advertised scenarios.

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

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

Although schema coverage is 100%, the description greatly enriches both parameters: it explains how 'event' triggers per-event partition/ordering checks with example slugs, while 'topic' enables a cross-event flattening process with a seed question. It also clarifies the relationship between parameters (they are alternative modes, not combinable), which the schema alone does not convey.

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

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

The description opens with a specific verb phrase: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks,' identifying both the action and the resource. It explicitly distinguishes this tool from siblings like polymarket_edges and polymarket_fill_risk by detailing its unique dual-mode logic (event vs topic) and its focus on structural arbitrage rather than generic edge detection.

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 when-to-use instructions: call with no args for trending scan, pass 'event' for per-event checks, or 'topic' for cross-event scanning. It also points to a specific alternative ('For custom sizing use polymarket_fill_risk') and includes a strong negative directive ('do not trade it' when realizable_edge_pp ≤ 0), leaving no ambiguity about 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?

Beyond the read-only and idempotent annotations, the description discloses critical behavior: caching at the KV level for 1 hour keyed on all knobs, the three response segments with model details, the per-leg favorite-longshot bias correction, the placeholder-slug filter, the rare-by-design nature of concentrated longshots, and the fed candidates exclusion. It also explains the 24h-move warning and diagnostics so callers understand why segments may be empty.

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

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

The description is long but well-structured with typographic sections (FIVE MODEL FAMILIES, TRADEABLE-EDGE KNOBS, RESPONSE TOP-LEVEL, _diagnostics). It front-loads the core purpose in the first sentence. Every major section adds necessary detail for a tool with no output schema. It is dense but not bloated, though the 'FIVE MODEL FAMILIES' statement appears inconsistent with the three families explicitly listed.

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 thoroughly explains the response structure: by_segment with model_driven, structural_arbitrage, concentrated_longshot; fed_candidates/fed_note; and _diagnostics. It details the fields carried on each opportunity (edge_pp_net, kelly_fraction, liquidity, spread_pp, volume), the 24h-move warning, and why segments might be empty. It also covers caching behavior. This is highly complete given 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?

All 9 parameters are fully described in the input schema (100% coverage), so the baseline is 3. The description adds value by explaining relationships between knobs, e.g., min_partition_leg_kelly specifically applies to partition_overround legs and that min_kelly does not filter partition arbs because parent-level kelly_fraction_half is 0 by design. This clarifies cross-parameter behavior not obvious from 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 opens with a specific verb and resource: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' This clearly states what the tool does and distinguishes it from siblings like polymarket_arbitrage and polymarket_edge_tracker by emphasizing the Pipeworx data comparison and the 'what should I bet on today' use case.

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

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

The description gives clear context: 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets.' It also explains how knobs tailor output, such as min_liquidity and max_spread_pp to drop unrealizable edges. However, it does not explicitly exclude alternatives or name when not to use this tool versus siblings like polymarket_arbitrage.

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

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

The description goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) by disclosing: snapshot writing occurs only on cache-miss (gaps mean no scan), history is bounded by 60-day TTL, decay is computed from daily closes net of slippage (not intraday), and edge_pp_net is signed (negative = SELL YES). These are critical behavioral traits that annotations alone do not convey.

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 well-organized with clear sections (Args, RESPONSE, LIMITS). Every sentence adds specific value, from the core question to the explanation of tracked/expired/snapshot_dates and the TTL/slippage limits. No filler or redundancy; the length is justified by 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?

With no output schema, the description fully explains the response format (tracked[], expired[], snapshot_dates[]) and what each field means, including trend and decay_pp_per_day semantics. It also covers data limitations (60-day TTL, cache-miss gaps, daily-closing basis). This is complete for an agent to understand the tool's behavior, inputs, outputs, and caveats.

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

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

The input schema already provides 100% coverage of both parameters (days with default/clamp, window with enum values). The description's parameter mentions ('days (lookback, default 14, max 30)', 'window (snapshot family, default "1wk")') largely repeat schema content. The response breakdown adds context for how days affects snapshot lookback, but this is not a significant addition beyond the schema's 'lookback' description.

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

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

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

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 strong context for when to use the tool ('a fresh wide edge and a 3-week-old wide edge are different trades'), making the use case explicit. It does not explicitly name alternatives or state when not to use it, but the context is clear enough to guide selection among sibling tools focused on current edges or arbitrage.

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

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

Annotations already declare readOnlyHint and non-destructive, and the description adds substantial behavioral detail: mode requirements, default behaviors, return fields (top_of_book, vwap_fill_price, slippage_pp, etc.), and the risk of forced_directional_risk. No contradiction.

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

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

The description is long but highly information-dense, covering two operating modes, parameter defaults, output fields, and risk guidance. It is structured with clear mode markers (SINGLE-MARKET, BASKET) and starts with the core purpose, so it earns a 4 rather than 5 for being somewhat lengthy.

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 there is no output schema, the description enumerates all relevant return fields for both modes and explains the use case. It also addresses edge cases like thin books and partial fills, making it remarkably 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% with detailed parameter descriptions. The description adds extra depth by explaining the intent of each side (e.g., sell_yes = capture overround, buy_yes = capture underround) and clarifying size_usd interpretation in basket mode as settlement notional per leg. This goes beyond the schema.

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

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

The description clearly states the tool performs a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' and distinguishes between single-market and basket modes. It explicitly references sibling tools (polymarket_arbitrage, polymarket_edges), making its unique 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?

Explicitly states when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It also explains why, citing the risk of partial fills converting arb into unhedged directional positions.

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), the description discloses response structure, safety fields, compatibility_warning triggers, temporal_alignment semantics, and skipped_cross_type/subtype meanings. It thoroughly explains edge cases and why a spread may be meaningless, far exceeding the baseline annotation coverage.

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

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

The description is long but well-structured with clear labels (TWO MODES, RESPONSE, SAFETY FIELDS) and every sentence contributes meaningful information. It is appropriately detailed for a tool with multiple safety caveats, though it could be slightly trimmed without losing value.

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

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

Given the tool's complexity and the absence of an output schema, the description is exceptionally complete. It covers return values, error/warning conditions, temporal alignment, and practical limitations, providing an agent with everything needed to invoke and interpret results safely.

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 parameters are already documented. The description adds value by explaining the two modes, how explicit parameters override topic-mapped ones, and the available macro shortcuts. It enriches the schema by clarifying parameter interactions and expected usage scenarios.

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

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

The description clearly states the tool computes the cross-venue spread between Kalshi and Polymarket for the same resolving question. It distinguishes itself from siblings by specifying the unique cross-venue focus and the two operational modes (topic shortcuts vs explicit ticker/slug). The purpose is unmistakable and context-rich.

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

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

The description explains two usage modes and provides when-not-to-use guidance via compatibility_warning conditions and temporal alignment constraints. It explicitly warns that most pre-mapped topics return compatibility_warning, implying the tool is not always usable. However, it does not name alternative sibling tools for specific scenarios, so it falls short of a full 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it returns attribute rows and geometry, and demonstrates a safe sampling query, which goes beyond the annotations without contradicting them.

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

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

Three sentences: purpose, parameter list, and a practical tip. No redundant explanation or boilerplate; every sentence earns its place.

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

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

For a no-output-schema query tool with six parameters, the description covers the URL source, return shape, and a typical query pattern. It could mention pagination behavior explicitly, but the schema includes offset and limit, and annotations cover safety, so this is reasonably 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 descriptions cover 100% of parameters, setting the baseline at 3. The description summarizes parameter names and gives a usage example, but adds little meaning beyond the schema's existing per-parameter descriptions. The sampling tip is useful but not substantive semantic enrichment.

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 'Query an ArcGIS Feature Service / Map Service layer' with a specific verb and resource, and ties it to search_datasets for sourcing URLs. This distinguishes it from siblings like layer_info (metadata) and search_within (spatial search).

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

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

The description provides a workflow hint ('from search_datasets') and a concrete sampling pattern ('where="1=1" + out_fields="*"'), giving clear practical guidance. However, it does not explicitly contrast with alternatives such as search_within or layer_info, so it stops short of full when-to-use vs. 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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful context about scoping to the identifier and the behavior of omitting the key to list all, going 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, front-loaded with the action, and includes examples without unnecessary detail. Every sentence earns its place.

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

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

Covers purpose, usage guidance, scoping, and tool relationships. The lack of return format details is acceptable given the tool's simplicity and absence of output schema, but more info about missing keys would be ideal.

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

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

The schema already describes the only parameter 'key' with 100% coverage. The description repeats the 'omit to list all keys' behavior, adding no new meaning beyond what the schema provides.

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

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

The description clearly states the action: 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' It names the resource and distinguishes itself from sibling tools by referencing remember and forget.

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

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

The description gives concrete use cases: 'look up context the agent stored earlier... without re-deriving it from scratch.' It also explains scoping and pairing with remember/forget, but doesn't explicitly state when not to use it.

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

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

The description discloses a side effect: 'Set mark_read:true to flag returned events read so the next call only shows newer ones.' This contradicts the annotations' readOnlyHint=true and idempotentHint=true, which imply no state mutation and deterministic results. Per the rubric, contradiction with annotations yields a score of 1.

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

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

The description is four sentences, front-loaded with the main purpose, and includes necessary operational details (filters, mark_read, alternative access) without excessive verbosity. The extra HTTP endpoint info is concise and relevant.

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 5 parameters and no output schema, the description explains the return payload's core fields, filtering, mark_read behavior, and an alternative access method. It does not discuss pagination, but the description is otherwise adequate for this tool's complexity.

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

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

The schema covers all parameters (100%), so the baseline is 3. The description adds value by explaining the behavioral impact of mark_read (affects future calls) and gives a concrete example of type filtering ('sec_8k'), going beyond the schema's field 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 starts with 'Pull fired events from your subscription feed' and details what is returned (source, citation_uri, raw event payload). This distinguishes it from siblings like list_subscriptions and recent_changes, making its purpose explicit and specific.

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 mentions polling suitability and provides an alternative HTTP endpoint for scripts/dashboards, which is useful context. However, it does not explicitly compare to sibling tools or state when not to use this tool, leaving room for more direct guidance on tool selection.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses the fan-out to SEC EDGAR, GDELT/GNews, and USPTO, including the soft-fail due to PatentsView API sunset. It also reveals the return structure (changes[], total_changes, citation URIs), which is not available from any structured field.

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 front-loaded with the primary use case, followed by source details, parameter formats, output summary, and alternative tool. Every sentence serves a purpose; there is no filler or redundancy. Its length is justified by the tool's multi-source 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?

Since there is no output schema, the description fully specifies the return payload ('structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs'), lists all data sources, explains failure modes, and provides an alternative tool. It gives an agent everything needed to invoke the tool correctly without further documentation.

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

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

The description adds behavioral meaning to the parameters: it connects `since` to 'filings since `since`' and news window, provides a concrete usage recommendation ('30d' or '1m'), and clarifies that `value` maps to 'Ticker or zero-padded CIK.' Although the schema already documents all three parameters (100% coverage), the description enriches their semantics with execution context.

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

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

The description opens with concrete natural-language queries ('What's new with X') and then states 'change feed for a company in the last N days/weeks/months in ONE parallel call,' making the specific verb+resource+scope clear. It also distinguishes from the sibling tool entity_profile by explicitly naming it as the alternative for 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?

It explicitly says to use entity_profile when static profile data is needed regardless of window, providing a clear when-not-to-use rule. It also details the fallback behavior among data sources (GDELT preferred, GNews on rate-limit/5xx), which informs the agent about expected reliability and selection criteria.

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

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

The description adds behavioral context beyond annotations: storage as key-value pairs, scoping by identifier, and TTL for anonymous sessions (24 hours) vs persistent for authenticated users. It doesn't explicitly state overwrite behavior, but idempotentHint=true already covers that, and the added persistence details are valuable.

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 concise sentences: the first states the purpose, the second provides usage guidance with examples, and the third explains storage scope, persistence, and sibling relationships. Every sentence earns its place 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 simple two-parameter tool with no output schema, the description is complete: it covers purpose, usage, persistence, TTL, and relationships with recall and forget. There are no missing critical details that an agent needs to invoke it correctly.

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

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

The input schema already documents both parameters with examples and descriptions, achieving 100% coverage. The description reinforces the key-value nature but does not add new semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Save data the agent will need to reuse later' with a specific verb and resource (key-value pairs). It explicitly distinguishes from siblings by naming recall and forget as partners, and the context of 'resolved ticker, target address, user preference' makes the purpose concrete.

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 guidance on when to use: 'Use when you discover something worth carrying forward...' and gives concrete examples. It also clarifies scope (across conversation/sessions), persistence differences for authenticated vs anonymous users, and pairs with recall/forget, effectively explaining usage vs 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?

Beyond the read-only/idempotent annotations, the description discloses that identifiers are labeled with their source, unresolved identifiers are explicitly returned under 'unresolved' rather than omitted, and GLEIF/OpenFIGI enrichment degrades gracefully if those services are unavailable. This provides significant behavioral context beyond the annotations.

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

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

The description is front-loaded with example queries and a clear purpose statement, then organized into supported types and behavior notes. While somewhat long, each section adds necessary detail for both entity types and graceful degradation. It is efficient but could be tightened without losing value.

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

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

With no output schema, the description appropriately explains what is returned (canonical identifiers with source labels, unresolved items explicitly listed) and covers fallback behavior for unavailable services. It is thorough for a two-type lookup tool, though it could specify exact response structure or error handling.

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

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

The input schema already has 100% coverage of both parameters with detailed descriptions (type enum and value format for company and drug). The description adds narrative about enrichment and ownership but does not meaningfully enhance the parameter semantics beyond what the schema states, so the baseline 3 applies.

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

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

The description clearly states the tool resolves user-spoken names to canonical identifiers, with specific examples ('ticker for...', 'CIK for...'). It distinguishes its purpose from sibling tools by noting it provides IDs needed by other tools. The verb 'resolve' and resource 'entity' are explicit and unambiguous.

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

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

The description explicitly instructs to 'Use FIRST whenever you have a name but need an ID', which is clear when-to-use guidance. It also explains that each call replaces 2-3 manual lookups, but does not explicitly name alternative tools or provide when-not-to-use conditions, so it falls 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context: it probes each entity with ai_visibility_check, ranks results, and returns a ranked list with score, confidence, and signal density. It also notes first entity is subject for narrative, which aligns with schema. No contradiction.

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

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

The description is three sentences, front-loaded with the core purpose. Each sentence adds value: mechanism, use case, and output format. No redundancy or fluff.

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

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

Given that the schema documents all parameters and the tool has no output schema, the description provides sufficient context: what it does, how it works, when to use it, and what the return looks like. It covers the essential information for an agent to select and invoke it 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 description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema: it references 'your brand + N competitors' but the schema already explains entities fully. No extra clarification for models, _apiKey, or context.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, specifically using ai_visibility_check and ranking by score. This distinguishes it from siblings like ai_visibility_check, which likely handles single entities, and compare_entities, which may be more general.

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 frames usage for competitive AI-marketing audits with an example ('does Claude know about us as well as our competitors?'). It implies using this when comparing multiple entities, but does not explicitly name alternatives or state when not to use it. Thus, clear context but no explicit exclusions.

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

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

The description discloses critical behavioral traits beyond the annotations: partial failures degrade gracefully, bundlephobia's first measurement can take 5-30s, and sources_failed will list timeouts. It also notes the NPM-only scope in v1. These are valuable operational details that annotations do not cover.

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 densely informative, with a logical flow: purpose, use cases, return value, scope, and failure behavior. It front-loads the core purpose and avoids fluff. Minor redundancy ('composite' and 'ONE call' repeated) but every sentence earns its place.

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

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

With no output schema, the description takes responsibility for explaining return values, and it does so thoroughly: lists all summary fields, per-advisory details, links, and recent versions. It also covers failure handling and latency, making it complete for a composite 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 both parameters are well-described in the input schema. The description adds some context about what 'version' means (via 'is_latest' and 'recent alternative versions') but does not materially enhance the schema's parameter explanations. Baseline 3 applies.

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

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

The description opens with a specific, concrete purpose: a composite check for deciding whether to add an npm package, aggregating data from deps.dev and bundlephobia. It clearly distinguishes this from sibling tools by naming the exact output (license, advisories, bundle size, etc.) and the NPM-only scope in v1.

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: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also provides an alternative for other ecosystems: 'PyPI / Maven / Cargo / Go fall under deps.dev:version directly'. This is unambiguous usage 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 readOnly/idempotent/non-destructive, so safety is covered. Description adds meaningful context: returns dataset metadata (not features), includes workflow hint to pass url to query_layer/layer_info, and scopes to City of Pittsburgh GIS open data. This goes beyond the annotation baseline.

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

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

Single sentence, front-loaded with the core action and resource, then cleanly lists returned fields and downstream usage. Every word earns its place; 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 no output schema, the description fully explains return values (name, summary, record_count, owner/org, url). It also provides cross-reference to sibling tools (query_layer/layer_info) for next steps, making it actionable and complete for a search/discovery 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 description coverage is 100%, so parameters are fully documented. The description does not add additional semantic meaning beyond what the schema provides (query keyword, optional org override). 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 uses specific verb 'Search' with resource 'City of Pittsburgh GIS open geospatial datasets' and lists what is returned (name, summary, record_count, owner/org, Feature Service url). It clearly distinguishes from sibling tools like query_layer/layer_info by stating the returned url should be passed to those tools.

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

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

Provides clear context: use for keyword search of Pittsburgh GIS datasets and then pass the returned url to query_layer/layer_info. It scopes usage to open geospatial datasets but does not explicitly mention when not to use or alternatives beyond the downstream tools, so not a 5.

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

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

Beyond the readOnly/idempotent annotations, the description reveals the embedding model (BGE-base-en), windowing (500-char overlapping), offset and similarity score returns, and the 200K char truncation with flagging. This gives the agent an accurate mental model of the tool's behavior 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?

Four focused sentences: the first defines the action, the second explains the use case, the third pairs it with a sibling, and the fourth discloses technical constraints. No filler or repetition of schema field names.

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

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

Given there is no output schema, the description compensates by describing the return value (top-N passages with character offsets and similarity scores) and the truncation flag. The pairing with ask_pipeworx_grounded and the explicit 200K cap make it self-sufficient 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?

Schema coverage is 100%, so the baseline is 3. The description adds light context by calling text 'the text you already pulled' and providing query examples, but the schema already documents both params thoroughly; no meaningful new semantic information is added.

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 'Semantic search INSIDE a fetched record,' clearly specifying the verb (search) and resource (record). It distinguishes from siblings by explicitly pairing with ask_pipeworx_grounded and positioning itself as a sub-document search tool, unlike broader query tools.

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

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

States 'Use when the record is too big to cram into the prompt,' giving a concrete trigger. Also advises pairing with ask_pipeworx_grounded and describes the workflow: 'fetch with the gateway, ground over the relevant passages instead of the whole document.' This effectively differentiates from alternative tools.

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

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

Beyond the annotations (which only indicate mutating, idempotent, non-destructive), the description discloses meaningful behavior: requires Pipeworx OAuth (anonymous/BYO cannot persist), phone must be verified, SMS has a 10/day cap, webhook auto-disables after 10 consecutive failures, and the signing secret is returned only once. No contradiction with annotations.

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

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

The description is dense and long, but every sentence carries useful detail about auth, types, delivery, and caveats. It front-loads the main purpose and then layers specifics; a bit more structure (e.g., line breaks) would improve scannability, but it is not redundant.

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 parameters, nested objects, and no output schema, the description is complete: it explains supported types, parameter shapes, auth requirements, optional vs. always-on delivery, webhook signing, limits, and the fact that the subscription id is returned. An agent can invoke this tool without guessing.

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 covers all parameters at 100%, so the baseline is 3. The description adds real value by giving concrete examples (items:['5.02'] = officer change; params:{topic:'fed'}) and reminding that the response includes a one-time webhook secret. It does not fully replace the schema, but enhances it.

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 'Create a proactive monitoring subscription to a live-data event stream' — a specific verb and resource, distinct from sibling tools like list_subscriptions or unsubscribe. It also states the return value (new subscription id), making its purpose unmistakable.

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

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

It provides clear context for when to subscribe: it is for proactive monitoring of live-data streams, with supported subscription types and delivery channels. It does not explicitly name alternatives (e.g., use recent_alerts to view fired events), but the context is sufficient for an agent to choose it over list/unsubscribe tools.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds beyond that: explains return content (category buckets, live catalog, exact tool+argument shape) and the no-args vs. topic-focused behavior. 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 longer than typical but every sentence contributes: example questions, purpose, return details, and usage guidance. It is front-loaded with familiar query phrasings and structured logically from purpose to invocation. 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?

The tool has only one optional parameter, no output schema, and rich annotations. The description fully covers what it returns (category buckets with tool+argument shape), when to use it, and how to invoke it, making it complete for an agent to select and call 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% and the schema already describes the 'topic' parameter with valid focus areas. The description repeats the examples ('finance', 'pharma', 'betting') but does not add new semantic meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific purpose: returns category-bucketed example questions with exact tool and argument shape, serving as the onboarding entry point. It clearly distinguishes itself from sibling tools by instructing to use it FIRST before meta-tools like ask_pipeworx and entity_profile.

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

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

Explicitly provides when to use: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' It also explains call patterns (no args vs. topic focus) and implies alternatives (meta-tools for actual queries).

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 important behavioral details beyond annotations: the row is deactivated (not deleted) and historical events remain available via recent_alerts. This complements the destructiveHint=false and idempotentHint annotations without contradicting them.

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

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

Two sentences, front-loaded with the action, and every sentence provides useful context 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?

For a single-parameter tool with no output schema, the description covers the action, ownership constraint, and the deactivation side-effect. It could mention error behavior, but the description is sufficiently complete for its complexity.

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

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

The input schema already fully describes the 'id' parameter (uuid returned by subscribe) with 100% coverage. The description merely says 'by id', adding no new semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description states 'Cancel a subscription by id', a specific verb and resource, and distinguishes this 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?

It clearly explains ownership enforcement and that only own subscriptions can be cancelled, providing context for when this tool is appropriate. It also notes the deactivation behavior. However, it doesn't explicitly name alternatives or state when not to use it.

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

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description reveals important behavioral traits: the two routing paths, the meaning of each verdict, and especially the critical caveat that 'could_not_verify means the check did not happen... and must not be shown as one.' This is exactly the kind of edge-case transparency that helps an agent act correctly, and it does not contradict any annotation.

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 well-organized: it starts with trigger examples, then usage, then the two-path logic, then return values, then critical caveats, and ends with a performance note. Every sentence carries substantive information, and the most important operational warning (about 'could_not_verify') is set off with 'IMPORTANT for callers.'

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

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

Despite no output schema, the description lists all possible verdicts and explains the difference between 'could_not_verify' and 'unsupported.' It specifies the data sources, the tolerance-based grading, and the citation format (pipeworx://). For a tool with only two parameters and read-only semantics, this is remarkably complete—an agent can confidently invoke and interpret results.

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

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

Schema coverage is 100%—both 'claim' and 'tolerance_pct' have clear descriptions with examples and defaults. The tool description itself does not add direct parameter detail beyond mentioning 'exact percent-delta math' and 'tolerance implied by wording,' which is light. Since the schema already provides robust semantics and the baseline for full coverage is 3, this is appropriate, though the description could have reinforced the role of tolerance_pct more explicitly.

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 concrete trigger phrases ('Is it true that…', 'fact check', 'verify the claim') and states the core function: natural-language claim verification against authoritative sources. It sharply distinguishes this tool from generic research/query siblings by specifying two distinct pipelines (SEC EDGAR for company-financial claims, grounded pipeline for everything else) and enumerates the exact verdict types returned.

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

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

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct,' which is a clear when-to-use directive. It also clarifies that company-financial claims go through a fast path and any other factual claim uses the grounded pipeline, effectively covering all factual claims. However, it does not name alternative tools or state when NOT to use it (e.g., for open-ended research), though the context implies this.

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