Arcgis Kamloops

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: the default model (Workers AI Llama-3.3-70b) is free, while probing Anthropic requires a BYO key with direct payment to Anthropic. It also discloses the return shape per model. 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 three sentences, front-loaded with the core purpose, followed by default/cost details, output format, and use cases. Every sentence adds distinct value; no fluff or repetition of schema/annotations.

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

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

For a tool with no output schema, the description clearly summarizes the return format (per-model fields + combined view). It also covers the default model, cost implications, and typical use cases. Given the moderate complexity (4 params, multiple model options), this is sufficient for an agent to select and invoke correctly.

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

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

The input schema covers all 4 parameters with descriptions (100% coverage), so the baseline is 3. The description adds the specific model name 'Llama-3.3-70b' and clarifies the cost/payment semantics of `_apiKey` ('you pay Anthropic directly'), which goes beyond the schema's generic note. This is modest but meaningful added value.

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 'Probe' and identifies the resource as 'one or more LLMs' with a clear scope ('what they know about a business/brand/product/topic') and concrete output ('score visibility (0-100) per model'). This distinguishes it from sibling tools like ask_pipeworx (which likely queries Pipeworx data) and scan_competitor_ai_presence, though the latter is not explicitly referenced.

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

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

The description states concrete use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') that tell an agent when to invoke this tool. However, it does not explicitly name alternative tools to use instead, or describe exclusions (e.g., 'for deep research, use deep_research'). This is clear context but not full alternative 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 mark this read-only and idempotent. On top of that, the description adds real behavioral detail: it routes to one of 5,596 tools, fills in arguments, and returns a structured answer with stable citation URIs. It does not discuss fallback behavior when no source matches, but given the annotation coverage, this is still a transparent and useful 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, well structured: it opens with the important behavioral preference (distinguishing it from web search), explains the internal mechanism in one sentence, gives trigger phrasing, supplies diverse examples, and closes with an actionable 'START HERE.' Every sentence earns its place, and the text is front-loaded with the most important selection 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?

There's no output schema, but the description clarifies that the tool returns a structured answer with usable pipeworx:// citation URIs and that it can answer across multiple domains. The only gap is not specifying behavior if the request doesn't map to any of the 5,596 tools, or whether more than one source could be returned. That gap is minor given the tool's design and the rest of the coverage.

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 for parameter semantics is 3. The description nonetheless enriches the input contract by showing example questions and by stating the kind of natural-language content that makes the parameter work ('factual question about real-world entities, events, or numbers'), compensating for the schema's minimal 'alias for question' descriptions.

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

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

The description states the concrete verb and resource: it routes a natural-language question to the right tool among 5,596 tools, fills arguments, and returns a structured answer with stable pipeworx:// citation URIs. It is clearly distinguished from web search by its 'prefer over web search' stance, so the agent knows exactly what capability it provides.

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 trigger phrases and cases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), emphasizes that this should be chosen even when web search could answer, and ends with 'START HERE for most questions.' It does not, however, mention when to prefer sibling tools like ask_pipeworx_grounded, deep_research, or the beta variant, so the when-not side is incomplete.

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 discloses that behavior may vary live when a routing candidate is under test, that no candidate is currently active (retired 2026-07-26), and that it now matches ask_pipeworx exactly. It also explicitly says 'falls back to nothing' — meaning it is a fully functional router, not a stub — which is valuable behavioral context annotations could 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 and well-ordered: identity and current status come first, followed by usage guidance and final assurance about the router being complete. It repeats 'identical' twice and restates the 'matches ask_pipeworx' fact, but those redundancies are small enough to keep the description at 5 minus a bit.

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 100% schema coverage and no output schema, the description covers the essentials: what it routes, how it differs from stable, the current inactive candidate state, and the response-shape compatibility with ask_pipeworx. The main gap is that it does not specify what changes an agent should expect if a candidate is active, or contrast with ask_pipeworx_grounded, but nothing there is required for calling it correctly in the present state.

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

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

Schema description coverage is 100%, so the schema already documents the single semantic parameter (question) and its aliases in detail. The description adds only contextual color about the routing target (same 5,596 tools) rather than param-level detail, so it meets the baseline but does not exceed 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 identifies the tool as a beta variant of ask_pipeworx, a 'universal router' over the same 5,596 tools, same arguments, and same response shape, with routing decisions compared against the stable version. It explicitly distinguishes it from the stable ask_pipeworx and names a sibling context, so the agent knows what it is and is not before opening the schema.

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 gives explicit situational guidance: 'Use it exactly like ask_pipeworx when you want the newest routing', and explains that results are evaluated against the stable router for merge decisions. It stops short of a full when-not-to-use list, such as contrasting with ask_pipeworx_grounded, so the alternative-routing guidance is present but not exhaustive.

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?

Annotation already declares readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to repeat those. It goes further by revealing the exact refusal reasons—'not_in_source', 'no_tool_match', 'tool_error', 'data_truncated', 'llm_error'—and the return payload fields. This transparently supports hallucination-resistant behavior beyond what annotations 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 efficiently structured: it opens with the core concept, then explains the routing behavior, return shape, refusal semantics, use cases, and the tradeoff against the sibling tool. Every sentence carries critical information; no filler or repetition. It is longer than ideal but justified by the complexity of this answer mode.

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 that returns rich structured output yet has no output schema, the description explains the full output format with each field and enumerates the possible refusal reasons. The annotation (readOnlyHint, idempotentHint) captures safety, and the description covers behavioral triggering, cost, and comparative guidance. An agent has everything needed to decide invocation 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 description coverage is 100%, with clear descriptions for the only required parameter, 'question'. The tool description does not add param-specific meaning, and no param is undocumented, so baseline 3 is appropriate. The description's examples about high-stakes use cases indirectly clarify what kinds of questions to ask, but the schema already does the heavy lifting.

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 says this is a 'hallucination-resistant answer mode for high-stakes reads' and explains it extracts answers only from tool results and returns explicit refusals. It names the sibling tool ask_pipeworx and points out the difference in behavior, so an agent can distinguish them without needing to inspect the schemas.

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 an explicit condition: use whenever an answer will be quoted, cited, or acted on and the agent must not invent facts, with examples (financial verdicts, legal claims, medical lookups, public statements). It also states the direct alternative 'ask_pipeworx' and says to prefer it for causal lookups, plus cites the extra LLM call cost for this mode.

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 (readOnly, idempotent, destructive=false) by detailing the resolver contract (confidence levels, alternatives, suggestions), status codes (low_confidence_match, market_closed_or_inactive), safety short-circuiting, wide-spread illiquidity handling, and cancellation-rule risk. It also describes the fan-out parallelization and news fallback behavior. This is exceptional transparency.

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

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

The description is long but well-structured with labeled sections (CLASSIFIERS, FAN-OUT EXAMPLES, RESPONSE SHAPES, RESOLVER CONTRACT, etc.). The first sentence front-loads the purpose. While every sentence adds value, the sheer length could be trimmed; however, the complexity of the tool justifies the detail. It earns a 4 rather than 5 due to its length.

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

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

With no output schema, the description carries the full burden of explaining return values. It covers result.market, result.analysis, result.evidence, result.parent_event, news fields, status codes, and cancellation-rule fields. It also explains edge cases like blocking routes and safety suppression. This is a thorough contextual map for a complex tool.

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

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

The input schema already provides 100% coverage for all three parameters, with descriptions for market, depth, and include_raw. The description reinforces accepted market formats (slug, URL, question text) and gives examples, but adds little semantic meaning beyond the schema. As per rubric, baseline 3 is appropriate when schema coverage is high.

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+resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It clearly distinguishes this from sibling tools by focusing on Polymarket bet research with fan-out to data packs, and it provides concrete examples of supported input formats.

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

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

Explicit usage guidance is provided: 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"' and the fan-out examples illustrate appropriate use cases. It also gives procedural guidance for low-confidence matches and closed markets. It does not explicitly state when not to use it or name alternative tools, but the context is clear.

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

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

The description goes well beyond the read-only/idempotent annotations by specifying data sources (SEC EDGAR/XBRL, FAERS, FDA), handling of off-calendar fiscal years, sorting by primary metric, and returning paired data with citation URIs. These behavioral details are valuable and not present in 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 somewhat long with multiple trigger phrases, but every sentence provides actionable information: triggers, usage preference, type-specific behavior, sorting, output format, and efficiency gain. It is well-structured and front-loaded, though slightly redundant with the two mentions of sequential lookups.

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 comprehensive for the tool's complexity: it covers two entity types, their data sources, fiscal-year handling, result sorting, output format, and efficiency advantages. Even without an output schema, the return behavior is clearly described.

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

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

Although the schema covers both parameters, the description adds substantial meaning: it explains what type='company' pulls (latest 10-K revenue, net income, etc.) and what type='drug' pulls (FAERS counts, trials), plus examples and the 2-5 constraint. This far exceeds the baseline for 100% schema coverage.

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

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

The description explicitly states it performs side-by-side comparisons of 2-5 companies or drugs, lists multiple natural-language query triggers, and contrasts itself with sequential single-pack lookups. This clearly differentiates it from sibling tools like 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?

It provides an explicit directive: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' It also clarifies when to use each type (company vs. drug) and mentions it replaces 8-15 sequential lookups, giving clear contextual guidance.

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

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

The annotations already carry readOnlyHint, openWorldHint, and destructiveHint=false, and the description adds substantial behavioral detail beyond them: parallel facet decomposition, routing across tools, findings with verbatim evidence and confidence, always-fetchable citation URIs, never-invented gaps[], contradiction scanning for standard/thorough, semantic not head-truncated excerpting, and expected latencies. This is far more than 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 long and information-dense with almost no filler; every sentence contributes behavioral or selection value. The biggest weakness is the run-on, semicolon-heavy structure that makes it a little harder to parse quickly, but it is elegantly organized by account, alternative, core behavior, return value, timing, and depth semantics.

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

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

There is no output schema, so the description compensates thoroughly by specifying what the findings packet contains (evidence, confidence, source, fetched_at, citations), the guaranteed citation_uri behavior, the gaps[] export, the contradictions[] field, hop semantics, large-document excerpting, and latency expectations. An agent has what it needs to call this tool 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?

The schema is informative, so the baseline is 3, but the description adds meaning beyond it: 'standard' implements gap recovery, 'thorough' adds lead-chasing and contradiction scanning, and the depth choices are tied to response-time and paid expectations. It also tells agents that question should be naturally phrased, broad, and multi-part, which is genuinely useful for choosing how to invoke the tool.

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 verb and resource: 'Grounded multi-source research across Pipeworx's 1465 STRUCTURED data sources' in one call. It also distinguishes the tool from open-web search and from ask_pipeworx, so an agent can tell what this tool uniquely does without opening the schema.

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

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

The description gives explicit when-to-use guidance: best for broad/multi-part questions over structured data, single lookups should use ask_pipeworx, current-event and colloquial topics should prefer ask_pipeworx, and signed-out users should use ask_pipeworx instead. This is clear selection guidance with named alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavior beyond annotations: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly, no second schema lookup needed.' It also includes 'Call this FIRST,' which is a behavioral/orchestration trait not captured by 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 rich but every sentence adds value: it front-loads the main purpose, scopes the tool with domain examples, describes the return format, and gives orchestration advice. The length is justified given the need to convey the broad applicability and the direct-callable nature of results.

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 adequately explains the return value: 'Returns the top-N most relevant tools with names, descriptions, and full input schemas... each result ready to call directly.' It also covers when to use it and what to expect, making it complete for an agent to decide and invoke.

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

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

Schema description coverage is 100% with each parameter documented, so the baseline is 3. The description adds minimal extra meaning beyond the schema—it reinforces that 'query' is a natural language description and mentions aliases, but these are already in the schema. The description does not clarify parameter semantics significantly beyond what structured fields provide.

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

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

The description clearly states 'Find tools by describing the data or task' with specific verb and resource, and distinguishes itself from sibling tools by being a meta-tool for discovery. It enumerates a broad scope of domains (SEC filings, financials, FDA drugs, etc.), making its purpose unambiguous.

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

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

Explicitly states when to use: 'Use when you need to browse, search, look up, or discover what tools exist for...' and advises 'Call this FIRST when you have many tools available and want to see the option set.' This provides clear context and orchestration guidance, though it does not explicitly mention when not to use it, which is acceptable.

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 discloses important behaviors: parallel fan-out across sources, specific return fields with URI formats, patents API sunset with soft-fail, and GDELT→GNews fallback. This adds valuable operational context.

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

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

The description is dense but front-loaded with examples and covers a complex tool efficiently. Some slight redundancy exists (e.g., 'names not supported' mentioned twice), but each sentence provides relevant detail; it is long yet structurally organized.

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

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

For a complex multi-source tool with no output schema, the description is remarkably complete: it lists all return components (CIK, filings with URIs, fundamentals, patents, news, LEI), notes fallbacks and limitations, and clarifies input prerequisites. This enables correct invocation without further research.

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

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

Schema coverage is 100% and already thoroughly documents the type and value parameters, including enum, ticker/CIK formats, and the name restriction. The description repeats this information with examples but does not add new semantic meaning beyond the schema.

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

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

The description clearly states the tool's purpose: 'full cross-source profile of a US public company in ONE parallel call.' It provides multiple example user queries and explicitly differentiates from chaining multiple single-pack lookups, making it distinct among siblings.

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

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

It gives explicit when-to-use triggers (e.g., 'Tell me about X', 'research Acme'), a clear preference rule ('ALWAYS PREFER over chaining... when user asks for holistic view'), and a specific alternative for name-only inputs ('use resolve_entity first').

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 convey destructive, idempotent, and non-read-only behavior. The description adds context by specifying that the deletion targets a memory saved earlier by the agent, and highlights clearing sensitive data as a use case. No contradiction with annotations.

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

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

The description is three concise sentences, each providing value: action, usage scenarios, and relationship to sibling tools. It is front-loaded and free of 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 single-parameter destructive tool with no output schema, the description covers what, when, and related tools. Combined with strong annotations, no critical information is missing.

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

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

The schema already fully documents the single 'key' parameter with a description ('Memory key to delete'), and schema coverage is 100%. The description reinforces that the key identifies a previously stored memory but does not add syntax or format details beyond the schema.

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

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

The description clearly states the action ('Delete') and the resource ('a previously stored memory by key'), which is specific and distinguishes it from sibling tools like remember and recall. The verb is direct and unambiguous.

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

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

The description provides explicit use cases ('when context is stale, the task is done, or you want to clear sensitive data') and mentions complementary tools ('Pair with remember and recall'). This gives clear guidance on when to use this tool versus alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: it fetches the page, extracts title/description/key links, emits standard llms.txt markdown, and returns a single text blob. This helps the agent understand the process and output without contradicting 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 concise and front-loaded with the main action. It states the process in one sentence, the output format in another, and lists use cases in a clear comma-separated list. Every sentence adds value with no redundancy or filler.

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

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

The description explains the input (any URL), the process (fetch, extract, emit), the output (single text blob for site-root/llms.txt), and the intended use cases. With only 2 parameters, no output schema, and informative annotations, this coverage is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description mentions 'any URL' and 'max_links' implicitly via the output format, but it does not add details about parameter syntax or defaults beyond what the schema already documents. The schema alone is sufficient for parameter understanding.

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

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

The description opens with 'Generate a production-ready llms.txt file for any URL' – a specific verb, resource, and clear output. It distinguishes from sibling tools like 'ai_visibility_check' or 'scan_competitor_ai_presence' by focusing on generating the actual llms.txt file rather than just assessing visibility.

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 'Useful for:' section lists three concrete scenarios (client site indexing, personal project drafting, competitor auditing), giving clear context for when to invoke the tool. It does not explicitly name alternative tools or provide 'when not to use' exclusions, so it stops 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 readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the expected output components but does not mention potential rate limits, authentication needs, or other behavioral quirks. It adds some value beyond annotations but not rich context.

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

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

The description is a single, well-structured sentence that front-loads the verb and resource. It includes all essential details without extraneous words, earning a perfect score.

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 one-parameter, read-only tool with full schema coverage and strong annotations, the description is complete. It states both the input (URL) and the output components. Given the tool's simplicity, it does not need to explain return formats or error conditions.

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

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

Schema description coverage is 100%, with the single 'url' parameter clearly described as a Feature/Map Service layer URL. The description adds minimal meaning beyond the schema, 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 uses a specific verb ('Get') and a precise resource ('ArcGIS Feature/Map Service layer's schema') and enumerates key outputs (fields, geometry type, record count, capabilities). It clearly distinguishes from sibling tools like query_layer, which likely queries features rather than schema.

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 usage (for schema lookups) but does not explicitly state when to use it versus alternatives such as query_layer or search_within. No exclusions or alternative tool names are provided, but the purpose is clear enough that an agent can infer usage.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false, establishing the safety profile. The description adds context about 'caller's' and 'active' subscriptions, which is useful, but it does not disclose additional behavioral traits like pagination or error conditions. This is adequate but not rich.

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: purpose, return format, and usage guidance. Every sentence is informative and non-redundant, with key information 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?

For a simple listing tool with no output schema, the description compensates by listing all return fields and providing clear usage scenarios. With annotations covering safety, this is complete for the tool's complexity.

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

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

The only parameter, include_inactive, is fully described in the schema with 100% coverage. The description's mention of 'active subscriptions' aligns with the default behavior but adds no new information. The schema carries the semantic load.

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 'List the caller's active subscriptions' with a specific verb and resource, and enumerates the return fields, making its function unmistakable. It differentiates from siblings like subscribe/unsubscribe and other listing tools by specifying the caller's own 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 gives explicit use cases: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This provides clear context for when to use the tool, but it does not mention when not to use it or name 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?

Annotations are all false, so the description carries the full burden. It discloses the claim_token flow for anonymous follow-up, the 5-per-day rate limit, that it is free and does not count against quota, and that the team reads digests daily. These are meaningful behavioral details beyond the structured fields.

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

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

The description is front-loaded with purpose and contains rich guidance without excessive padding. A few clauses are slightly redundant ('Pipeworx tool names are the ones this connection lists') but overall every sentence contributes to effective use.

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

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

Despite having no output schema, the description explains the primary return artifact (claim_token), how to use it later, rate limits, and scope boundaries. It gives enough context for an agent to decide when to call 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the claim_token round-trip ('Filing without an account returns a claim_token; pass it back later') and instructing users to frame feedback in terms of Pipeworx tools/packs rather than pasting user prompts, which is not fully in the schema.

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

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

The first sentence clearly states the tool's purpose: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It is a specific verb ('tell') plus resource (Pipeworx team) and distinguishes itself from sibling Q&A/research tools by focusing on feedback about Pipeworx tooling.

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 (bug, feature/data_gap, praise) and provides a clear exclusion: do not use it for tools from other MCP servers, and instead 'file it with that server.' This prevents misrouting and gives actionable direction.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable context beyond annotations: it is self-aggregating, derived from CF analytics-engine, contains no PII, and is cached 5min–1h depending on window. This fully discloses the behavioral profile.

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

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

The description is well-structured and front-loaded: it starts with what the tool does, then lists use cases, and ends with data provenance/caching. Every sentence contributes meaning without redundancy or fluff.

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

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

Despite having no output schema, the description clearly states the output components (top tools, top packs, total call volume, pack/tool/count). It covers key aspects like data source, privacy, and caching. For a simple tool with one optional parameter, this is 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% (the 'window' parameter's enum and effects are fully described in the schema). The description adds marginal semantic value by mentioning '24h, 7d, or 30d' and tieing to cache duration, but it does not go beyond what the schema already 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 uses a specific verb ('Returns') and clearly identifies the resource: top tools, top packs, and total call volume over recent windows. It distinguishes itself from siblings by focusing on aggregate AI-agent call activity, not individual searches or visibility checks.

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

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

The description provides three explicit use cases (discovering hot data sources, confirming canonical tools, aligning with agent needs). However, it does not explicitly name alternatives or state when not to use the tool, so it falls 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 readOnly/idempotent annotations, it details behavioral nuances: the 3pp signal threshold for partition deviations, the skipped_low_similarity counter, placeholder filtering rules, and the fill check that warns against trading non-realizable edges. This is rich behavioral disclosure with no contradiction to annotations.

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

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

The description is long but well-structured with section labels (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK) and a front-loaded purpose. Some sentences could be tightened, but the complexity justifies the length and it remains highly readable.

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

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

Despite having no output schema, the description explicitly lists response fields (opportunities[].gap_pp, partition_check, etc.) and integrates the fill-check flow. It also references polymarket_fill_risk for further risk assessment, covering the tool's full context 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?

Even though schema coverage is 100%, the description adds deep meaning: 'event' is explained with concrete slug examples and the associated partition_check logic, while 'topic' is clarified with seed questions and cross-event flattening behavior. This goes far beyond the schema's concise 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 opens with a specific verb and resource: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It clearly distinguishes two modes (event vs. topic) and references sibling tools like polymarket_fill_risk for custom sizing, making its unique role evident.

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 call with no args for a trending scan, pass 'event' for a single market, or 'topic' for cross-event scanning. It even recommends 'event' for specific markets and directs users to polymarket_fill_risk for custom sizing, providing clear when-to-use and alternative 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 indicate a safe read-only idempotent operation. The description adds substantial behavioral context: model families, response segments, per-opportunity fields, diagnostics for empty segments, caching behavior, and the Fed signal unreliability caveat. 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?

Well-structured with clear section headers and front-loaded purpose. It is lengthy (approx. 300 words) but densely packed with necessary details for the tool's complexity. Some technical specifics (FRED log-returns, GDELT ratios, per-sport α) could be considered over-detailed but are 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?

No output schema, so the description compensates by fully specifying response top-level structure, per-opportunity fields, diagnostics, and caching. Combined with rich schema and annotations, the description is complete for a complex tool.

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

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

Schema covers all 9 parameters with descriptions, so baseline is 3. The description adds value by explaining the overall purpose of knobs (e.g., 'TRADEABLE-EDGE KNOBS: min_liquidity / max_spread_pp drop opportunities where edge isn't realizable') and how min_partition_leg_kelly applies to per-leg Kelly. This goes beyond simple schema repetition.

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

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

The description uses a specific verb+resource+scope: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It clearly distinguishes itself from siblings like polymarket_arbitrage and polymarket_edge_tracker by being built for 'what should I bet on today' 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?

Clearly states the intended use case: 'Built for "what should I bet on today"' and 'agents discover opportunities without paging hundreds of markets.' It provides context on tradeable-edge knobs and Fed bets caveat, but does not explicitly name when-not-to-use alternatives, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral context: snapshot writes occur on cache-miss so gaps mean no scan that day, history is bounded by 60-day TTL and snapshot enablement, decay is computed from daily closes of edge_pp_net, and the interpretation of negative edge values (SELL YES) is explained. It also details the response structure including tracked, expired, and snapshot_dates. 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 more verbose than average but well-organized with explicit 'Args:', 'RESPONSE:', and 'LIMITS:' sections. The opening sentence captures the core purpose, and each subsequent section provides necessary details (parameters, response format, limitations) without significant redundancy. The 'nobody is willing to take' phrase is slightly colorful but reinforces the value of the tool. Overall, the length is justified by the complexity of the telemetry analysis and response structure.

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 there is no output schema, the description compensates thoroughly by enumerating the exact response fields (tracked, expired, snapshot_dates), their meanings (e.g., trend values, decay_pp_per_day computation, lifespan_days as competition clock), and key limitations (60-day TTL, cache-miss gaps, daily closes). It also covers both parameters and all relevant behavioral aspects, making the tool fully understandable for an agent to invoke and interpret results correctly.

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

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

Schema coverage is 100%, with both parameters fully described: days (lookback, default 14, clamp 2-30) and window (options: 24hr, 1wk, 1mo, default 1wk). The description repeats the defaults (days default 14, max 30; window default '1wk') but does not add new semantics beyond the schema. The schema already provides the necessary parameter meanings, so the description adds minimal value; 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 identifies the tool as providing edge persistence and decay telemetry built from daily polymarket_edges snapshots, with a specific question ('how long has this edge existed and is it shrinking?'). The phrase 'telemetry' and 'persistence' distinguish it from sibling tools like polymarket_edges (which likely provides current edges) by emphasizing historical tracking and trend 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 conveys when to use this tool: when you need historical edge persistence and decay analysis, and it highlights that a 3-week-old wide edge is a different trade than a fresh one. While it doesn't explicitly name alternatives or state 'use polymarket_edges for current edges', the context strongly implies this tool is for time-series/telemetry. It lacks explicit exclusions or alternative comparisons, but the intended usage is clear.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds substantial behavior context: walks the order-book ladder, returns specific metrics, handles two modes with different size semantics, identifies thin legs and forced directional risk, and warns about partial basket fills. No contradiction exists.

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

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

Although long, the description is dense and well-structured with clear SINGLE-MARKET and BASKET sections. It is front-loaded with the core purpose and each sentence contributes meaning—field lists, defaults, and risk warnings are all relevant. No padding.

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 for both modes: top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict, theoretical_sum, realizable_sum, capture_ratio, per-leg detail, thin_legs, and more. It also covers edge cases (partial fills, auto side selection) and the dominant loss mode. Complete for the tool's complexity.

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

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

Schema coverage is 100% with descriptions for all 4 parameters. The description adds significant meaning beyond schema: clarifies default values, distinguishes size_usd interpretation across single-market and basket modes (max spend vs target proceeds vs settlement notional), explains auto side selection, and mentions clamping range. This exceeds the baseline for full schema coverage.

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

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

The description opens with 'Realizable-vs-theoretical edge check against live CLOB order-book depth', a specific verb+resource statement. It clearly distinguishes single-market and basket modes, and the tool's purpose is differentiated from sibling tools like polymarket_arbitrage and polymarket_edges.

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

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

Provides explicit usage guidance: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. Explains the rationale (thin books make theoretical overround uncapturable) and the risk of partial fills. This is clear when-to-use and references 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?

With annotations already declaring readOnlyHint, openWorldHint, and idempotentHint, the description adds substantial behavioral context: two modes, response structure, compatibility warnings, temporal alignment checks, and skipped_cross_type counters. This goes far beyond the annotations and fully discloses edge cases and limitations.

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 dense, useful information about modes, safety fields, and warnings. It is front-loaded with the core purpose. Minor redundancy exists (e.g., explaining compatibility_warning in detail), but overall the structure is logical and appropriately detailed for a complex tool.

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

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

Given the tool has no output schema, the description fully explains the response format (leg-by-leg prices, top_spreads_pp) and safety fields. It also covers temporal alignment and skipped comparisons, making it complete for an agent to understand expected outcomes and edge cases. This is a very thorough description for a read-only cross-venue 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?

The schema already covers 100% of parameters with clear descriptions. The description adds value by explaining how parameters interact (topic auto-fetch, overrides) and the semantic meaning of the two modes. It reinforces but also enriches the schema, meriting 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: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It specifies the resource (spread between two venues) and scope (same resolving question), and distinguishes itself from sibling tools like polymarket_arbitrage by focusing on cross-venue comparison.

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

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

The description provides explicit usage modes (topic shortcuts vs. explicit tickers) and clear when-not-to-use guidance via compatibility_warning for non-equivalent bet shapes. It also warns that pre-mapped topics are not always tradeable. However, it does not explicitly name an alternative tool for cases where this tool is unsuitable.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior, reducing the burden on the description. The description adds value by noting that it 'Returns attribute rows (and geometry)' and providing a sampling tip. This 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?

The description is two sentences and efficiently packs core functionality, parameters, return type, and a usage tip. Every clause earns its place with no filler.

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

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

The tool is a simple read-only query with a complete schema and clear annotations. The description covers the main behavior, return format, and source of the url. It lacks explicit pagination details (though offset is in schema) and error handling, but for this complexity level it is sufficiently 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 has 100% coverage with detailed descriptions for all 6 parameters, so the description does not need to compensate. The description reinforces the parameter names (where, out_fields, order_by, limit, offset) and adds 'SQL-like' context, but provides no additional semantic detail 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 function: 'Query an ArcGIS Feature Service / Map Service layer by its url'. It uses a specific verb ('Query'), identifies the resource (Feature/Map Service layer), and distinguishes itself from siblings like layer_info by focusing on data retrieval. The mention of '(from search_datasets)' ties it to a specific workflow.

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 some usage context by indicating the url comes from search_datasets, and offers a practical sampling tip ('Use where="1=1" + out_fields="*" to sample'). However, it does not explicitly state when to use this tool over alternatives like layer_info or search_within, so it lacks 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?

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context about scoping ('Scoped to your identifier') and the listing behavior when key is omitted, 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?

Two well-structured sentences deliver the essential information without redundancy. The primary action is front-loaded, and the description is appropriately sized for the tool's simplicity.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the purpose, usage, scope, and relationship to other tools. The return behavior (value or list) is implied clearly enough for an agent.

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

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

Schema description coverage is 100% (the 'key' parameter is described in the schema). The description adds semantic value by giving concrete examples of key content and explicitly clarifying that omitting the key lists all keys, reinforcing the schema's 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 states a specific verb+resource: 'Retrieve a value previously saved via remember, or list all saved keys'. This clearly distinguishes it from sibling tools like remember and forget, and provides concrete examples of intended use (ticker, address, research notes).

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 when to use the tool ('Use to look up context the agent stored earlier... without re-deriving it from scratch') and mentions the paired operations 'remember' and 'forget', making the usage context and alternatives clear.

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

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

The description goes beyond annotations by disclosing that mark_read:true mutates read state and affects subsequent calls, and by describing event contents (source, citation_uri, raw payload). It also reveals the feed is a persisted feed written by the evaluator, adding valuable context not present in the readOnlyHint 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 concise and front-loaded, with every sentence providing meaningful information. It covers purpose, returned data, filtering, state mutation, and an alternative access URL without unnecessary fluff.

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

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

Given the tool has 5 optional parameters and no output schema, the description adequately explains the return payload contents and the feed's persistence. It also covers behavioral nuances like mark_read and offers an external endpoint for the same data, making the tool fully understandable.

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

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

The input schema already provides complete descriptions for all 5 parameters, so the baseline is 3. The description adds useful examples and clarifications, such as filtering by type with a sample value and explaining the practical effect of mark_read, which raises it to 4.

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

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

The description opens with a specific verb+resource combination ('Pull fired events from your subscription feed'), clearly identifying what the tool does and its scope. It distinguishes from sibling tools like list_subscriptions and recent_changes by focusing on the fired-events feed and includes details about event payloads.

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 that polling is fine and the feed is also available at a public URL for scripts/dashboards, giving an alternative access method. However, it doesn't explicitly name sibling tools to avoid or state when not to use this tool.

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

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

Annotations already indicate a read-only, idempotent, non-destructive operation. The description adds rich behavioral detail: exact data sources, GDELT→GNews fallback, USPTO soft-fail due to API sunset, date format handling, and return structure with citation URIs. No contradictions with annotations.

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

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

The description is dense but every sentence adds value: query examples, source list, fallback behavior, date formats, return shape, and alternative tool. It front-loads usage intent and remains appropriately organized 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?

Without an output schema, the description fully explains the return (changes[] grouped by source, total_changes count, pipeworx:// URIs). It covers all relevant behavior: multi-source fan-out, fallbacks, soft-fail conditions, parameter semantics, and the sibling alternative. No gaps remain for a tool of this complexity.

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

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

Schema coverage is 100% and each parameter is already described clearly in the schema (type enum, since format, value ticker/CIK). The description mostly restates these details with examples, adding only minor practical guidance (e.g., 'Use 30d or 1m for typical monitoring') already present in the schema's since 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 specifies a clear verb and resource: a change feed for a company over a time window, fanning out to SEC, GDELT/GNews, and USPTO. It distinguishes itself from entity_profile by explicitly noting when to use that sibling instead.

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

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

It provides explicit when-to-use context via query examples ('What's new with X') and states the tool is for change feeds in a single parallel call. It also names an alternative (entity_profile) for static profiles, giving clear 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?

Beyond the annotations, the description adds valuable context: memory is scoped by identifier and retention varies (persistent for authenticated users, 24 hours for anonymous). This goes beyond the basic write hint, though it doesn't mention key-overwrite behavior, which is a minor gap for a key-value store.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by usage guidance and storage details. Each sentence provides useful information without redundancy, making it concise and scannable.

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 the essential context: when to use, persistence behavior, and how it pairs with recall and forget. While it does not mention overwriting an existing key or any limits on value size, these are minor omissions for a simple store operation, and the absence of an output schema is not problematic here.

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 thorough descriptions for both key and value (100% coverage). The description adds context about the purpose (e.g., storing resolved tickers or preferences) but does not fundamentally enhance parameter semantics beyond what the schema already states, so a baseline score 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 identifies the action ('Save data') and the resource (key-value pair scoped by identifier). It distinguishes itself from siblings by referencing recall and forget, making its role in the memory lifecycle 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 you discover something worth carrying forward') and explains persistence differences based on authentication. It names complementary tools (recall, forget) for retrieval and deletion, aiding the agent in choosing among alternatives.

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

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

Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds critical behavioral context: it cascades through multiple lookup endpoints internally, degrades gracefully (if GLEIF or OpenFIGI is unavailable, EDGAR identifiers still return), and each identifier is labelled with its source. It also states that unresolved identifiers are explicitly stated under 'unresolved'. No contradictions with annotations.

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

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

The description is quite long and contains a lot of detail. It is front-loaded with example queries, which is good, but the subsequent block on supported types is verbose and could be streamlined. Some information (e.g., the ISIN-to-LEI mapping explanation) might be more appropriate in supplementary documentation. While thorough, it sacrifices conciseness.

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

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

Given the tool has no output schema, the description must explain return values, and it does so comprehensively. For company type, it lists the identifiers (CIK, ticker, LEI, FIGI), source labelling, and unresolved handling. For drug, it specifies RxCUI, ingredient, brand, and citation. It also covers graceful degradation and internal cascading. The description is complete for an agent to understand the tool's full behavior.

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

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

The input schema has 100% coverage with descriptions for both parameters. The description goes far beyond the schema: it explains the two entity types in detail, lists accepted input formats for company (ticker, CIK, ISIN, name) and drug (brand or generic), and describes what each type returns. This enriches the semantic understanding significantly, especially for the 'value' parameter which accepts multiple formats.

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

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

Description clearly states the tool resolves user-spoken names to canonical/official identifiers required by other tools. It provides multiple example queries ('What's the ticker for…', 'find the CIK for…') and explicitly says 'Use FIRST whenever you have a name but need an ID.' This distinguishes it from sibling tools like compare_entities or entity_profile by positioning it as the primary lookup step.

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 includes strong guidance: 'Use FIRST whenever you have a name but need an ID.' It lists specific query patterns that trigger this tool. While it does not explicitly list when not to use it or name alternatives, the context of siblings and the phrase 'replaces 2-3 manual lookups' implies efficient usage. Slightly more explicit exclusions would push to 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, openWorldHint, idempotentHint, and non-destructive. The description adds behavioral detail beyond annotations: it reveals that each entity is probed with ai_visibility_check, results are ranked by score, and output includes score, confidence, and signal density. This exceeds annotation-only knowledge.

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, followed by mechanism, use case, and return value. Every sentence earns its place, with no fluff or repetition of schema content. Highly efficient.

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

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

Given the tool's complexity (multi-entity comparison), the description covers inputs, behavior, output, and real-world use case. The schema and annotations are rich, so the description doesn't need to explain return formats extensively. The only missing piece is edge-case behavior (e.g., invalid entity counts), but that's not essential.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds some semantic context (e.g., 'your brand + N competitors' and the narrative role of the first entity), but most parameter-level meaning is already in the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Compare AI visibility across multiple entities side-by-side.' It clearly states the tool's function (probing entities, ranking by score, surfacing most/least recognized), which distinguishes it from sibling tools like ai_visibility_check (likely single-entity) and compare_entities (generic comparison).

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

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

The description gives clear context: 'Useful for competitive AI-marketing audits' with an illustrative quote. It implies you'd use this when comparing multiple entities, but it does not explicitly name alternatives or when-not-to-use. This is a clear contextual guideline, though not a full exclusion list.

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, and the description adds rich behavioral context: composite fan-out, graceful partial failure, 5-30s possible delay on first bundlephobia measurement, and the sources_failed field. It also notes the NPM-only scope. 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 front-loaded with purpose, then gives usage, return format, and caveats in a logical order. Although it is longer than average, every sentence adds essential information without redundancy or filler.

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

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

Without an output schema, the description fully specifies the return fields (summary block, per-advisory details, links, recent versions) and failure behavior. It also addresses non-NPM alternatives and version limitations, making it complete for a tool of this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add new parameter-level details beyond what the schema already states (package name, version defaults), so no extra credit is needed or given.

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

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

The description clearly states a specific verb+resource: it is a composite 'should I add this npm package' check that fans out to deps.dev and bundlephobia. It distinguishes itself from generic scanning tools by naming the exact use case and the two data sources.

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

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

Explicit guidance is given: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also states an exclusion (non-NPM ecosystems fall under deps.dev:version directly), effectively naming an alternative approach.

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 clear. The description adds value beyond annotations by specifying the return fields (name, summary, record_count, owner/org, Feature Service url) and the follow-up action, providing useful behavioral context.

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

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

The description is extremely concise: two sentences, the first stating purpose/scope, the second stating return value and chaining. No wasted words 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?

The description fully covers what the tool does, what it returns, and how to use the results. Combined with the rich annotations and 100% schema coverage, the agent has all necessary information. The lack of an output schema is compensated by listing the return fields explicitly.

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 for all three parameters, each with explanations and examples. The description's 'by keyword' adds little beyond the schema's own 'Keyword(s)' description. Thus 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 it searches City of Kamloops GIS open geospatial datasets by keyword, listing example categories (parcels, zoning, etc.). It also distinguishes from sibling tools by explaining that the returned URL is intended for query_layer/layer_info.

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

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

The description provides clear context for when to use the tool: to discover datasets by keyword and get their metadata and URL. It explicitly instructs the agent to pass the URL to query_layer/layer_info for further operations, effectively outlining a workflow. It does not explicitly state when not to use it or name alternatives, but the usage scenario is well implied.

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 important behavioral details beyond the annotations: use of BGE-base-en embeddings, 500-char overlapping windows, 200K char cap with truncation flagging, and character offsets for verifiability. These details give the agent a clear model of how the tool operates and what to expect, complementing the readOnly and idempotent hints.

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

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

The description is dense but every sentence contributes: purpose, usage, return format, integration, and technical behavior. It is front-loaded with the core action and avoids fluff, making it efficient for an agent to parse and act on.

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

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

Despite lacking an output schema, the description covers return values (top-N passages with offsets and scores), parameter semantics, use-case guidance, and limitations (truncation). Given the tool's moderate complexity, this is a complete and self-sufficient description.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra context for the 'text' parameter (examples of already-fetched content) and for 'query' (natural-language examples), enhancing the schema's dry definitions. The 'limit' parameter is fully covered by the schema, so the description's marginal value is modest but present.

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

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

The description clearly states the tool performs semantic search inside a provided text, with specific examples (SEC 10-K, article) and a clear distinction from sibling tools. It explicitly names a companion tool (ask_pipeworx_grounded), differentiating its role as a passage-level search rather than document-level grounding.

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 the record is too big to cram into the prompt' and explains the benefit (saves context, returns only relevant passages). It also provides workflow guidance by pairing with ask_pipeworx_grounded, offering a clear alternative integration path.

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?

Annotation contradiction: the tool's idempotentHint is true, but the description 'Returns the new subscription id' and 'Create a proactive monitoring subscription' imply a new resource is created each call, which is non-idempotent. The description does add useful context (OAuth requirement, phone verification, caps, webhook signing secret), but the contradiction forces 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 long but tightly structured: purpose is front-loaded, then supported types, then delivery channels. Every sentence contributes unique information. The density is justified by the tool's complexity, with no repetition of schema content that adds no 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?

Despite having no output schema, the description explains the return value (new subscription id), authentication requirements, all subscription types, delivery channels, verification steps, rate limits, and webhook signing details. For a tool with nested objects and multiple modes, this is highly 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 the baseline is 3. The description adds value beyond the schema by providing concrete examples (e.g., items:["5.02"], topic:"fed"), explaining operational constraints (10/day SMS cap, verified phone), and clarifying the always-on feed delivery. This meaningfully supplements the structured 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+resource: 'Create a proactive monitoring subscription to a live-data event stream.' It clearly distinguishes from sibling tools like list_subscriptions, unsubscribe, and recent_alerts. The supported types and delivery channels are enumerated, making the tool's scope unambiguous.

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

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

The description provides clear context for when to use the tool, including the prerequisite 'Requires a Pipeworx OAuth account (anonymous + BYO cannot persist subscriptions)' and explains delivery alternatives (feed always on vs optional email/sms). It does not explicitly name alternative tools or state when not to use it, but the context is strong enough to guide 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context beyond these, explaining that the output is 'category-bucketed example questions' with 'the exact tool + argument shape that answers it,' drawn from 'a live catalog of thousands of tools.' It also describes the no-args vs. topic behavior, which is more than the basic 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 longer than typical but front-loaded with relatable example queries followed by a clear purpose statement. Each sentence contributes meaningful information—output structure, invocation options, and onboarding context—so it is not padded or 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's simplicity (one optional parameter, no output schema), the description is comprehensive. It covers the output content (category-bucketed questions with tool shapes), the two usage modes, and the onboarding role. It also ties into the broader tool catalog by mentioning meta-tools, leaving no significant gaps for an agent to understand when and how to use it.

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

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

The schema already provides 100% coverage of the 'topic' parameter, including allowed values and the 'Omit for a cross-category spread' behavior. The description adds example values like 'finance', 'pharma', and 'betting', but these are illustrative rather than new semantic information, so the value added is marginal.

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: 'the onboarding entry point for an agent that just connected and wants to know what is worth asking.' It distinguishes itself from siblings by specifying it returns category-bucketed example questions with exact tool and argument shapes, a unique offering among the listed tools.

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

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

The description provides explicit guidance: '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 the two invocation modes—no arguments for the full spread or a topic for focus—which is clear, actionable 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?

The description discloses that the row is deactivated rather than deleted, which is a behavioral trait not present in annotations. It also mentions ownership enforcement, adding safety-relevant context. Annotations already cover readOnly/destructive/idempotent hints, and the description aligns with them (non-destructive soft delete). It doesn't describe edge cases like invalid ids, but that's beyond scope.

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

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

The description is two sentences, with the primary action front-loaded ('Cancel a subscription by id'). Every sentence adds useful information—action, ownership, and deactivation behavior—with no redundancy or filler.

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

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

For a single-parameter mutation without an output schema, the description provides the essential information: what it does, who can use it (ownership), and the consequence (soft delete, history preserved). The annotations supply idempotency and non-destructive hints. Edge cases (e.g., invalid id) are not covered, but the description is comprehensive for typical use.

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

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

The schema fully describes the id parameter as a subscription uuid from subscribe (100% coverage). The description adds the semantic constraint that the id must belong to the caller ('ownership is enforced'), which is valuable information for using the parameter correctly.

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

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

The description uses a specific verb 'Cancel' and resource 'subscription', clearly distinguishing it from sibling tools like subscribe and list_subscriptions. It also specifies the scope ('by id') and adds ownership enforcement, which fully clarifies the tool's purpose.

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

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

The description provides clear context: it states ownership enforcement (only your own subscriptions) and explains the deactivation behavior (not deleted, history preserved via recent_alerts), implying when this should be used. It doesn't explicitly name alternative tools or when-not conditions, but the context is sufficient.

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 behavioral details: verdict categories, the meaning of 'could_not_verify' as a non-evidence error state, 'unsupported' as a coverage limitation, and the use of verbatim evidence with citations. It also explains the underlying pipelines and math, which is valuable context for the agent.

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

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

The description is lengthy but every sentence earns its place: it front-loads query examples, explains the two processing paths, enumerates return verdicts, and clarifies error semantics. Despite the density, it is well-structured and not redundant, fitting 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?

The description fully accounts for the tool's behavior, return values, and error handling despite lacking an output schema. It covers what happens for different claim types, the meaning of each verdict, and the circumstances for 'could_not_verify' and 'unsupported', making the tool self-explanatory for the agent.

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

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

The input schema already provides full descriptions for both parameters (claim and tolerance_pct), including examples and defaults. The description adds some nuance about tolerance_pct overriding implied wording and capping at 5, but this is minor extra value. With 100% schema coverage, a 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 identifies the tool's function: checking whether a factual claim is true or false using natural-language input. It provides vivid examples and distinguishes between company-financial claims and other factual claims, making the purpose unambiguous and distinct from sibling tools that likely do research or searches.

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

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

It explicitly states when to use the tool ('Use whenever the agent needs to check whether something a user said is factually correct') and describes two routing paths based on claim type. However, it does not explicitly name alternative tools or state when not to use it, though the 'Replaces 4–6 sequential calls' suggests it should be preferred over multi-step workflows.

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