Arcgis Cumberland

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context: the default model (Workers AI Llama-3.3-70b) is free, Anthropic requires a BYO key and direct payment to Anthropic, and the return structure includes per-model {score, confidence, signals, raw_response} plus a combined view. This goes beyond the annotations and clarifies cost and response expectations.

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

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

The description is three sentences, front-loaded with the core action and result, followed by key defaults and use cases. Every sentence adds distinct value with no redundancy or fluff.

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

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

For a read-only probing tool with fully documented parameters and no output schema, the description adequately covers what is returned (per-model fields + combined view) and how to use the optional Anthropic model. It is complete enough 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 is 3. The description adds semantic meaning by noting the default model is free and that passing _apiKey incurs direct Anthropic charges, which is not fully captured in the schema. This enriches the parameter understanding beyond the raw field descriptions.

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

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

The description clearly states the tool's function: 'Probe one or more LLMs for what they know about a business / brand / product / topic and score visibility (0-100) per model.' This specifies both the action (probe and score) and the resource (LLMs), making it distinct from sibling tools like scan_competitor_ai_presence or compare_entities.

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

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

The description provides explicit use cases: 'Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also explains the optional Anthropic model via _apiKey, but does not explicitly mention when to use an alternative tool or when not to use this one.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context: it routes to thousands of tools, fills arguments, returns structured answers with pipeworx:// citation URIs, works on every tier, and is a fast default entry point. 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 longer than average but every sentence earns its place: it leads with a clear directive, provides concrete examples, outlines alternative tools, and explains the return format. There is no repetition of schema information or filler content.

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

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

For a tool with no output schema, the description adequately explains the return value (structured answer with citation URIs), lists domains and example queries, and situates the tool among alternatives. It is fully complete for a complex entry-point 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 covers all 6 parameters, including 5 aliases for the 'question' property, with 100% description coverage. The description itself does not add parameter-specific syntax or semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states the tool routes questions to one of 5,462 tools across 1,419 verified sources and returns structured answers with citation URIs. It clearly distinguishes itself from sibling tools like ask_pipeworx_grounded and deep_research by describing their specific purposes.

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

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

Explicitly says 'PREFER OVER WEB SEARCH' and 'START HERE for most questions', with detailed examples and clear direction on when to use alternatives: 'for a hallucination-resistant single answer... use ask_pipeworx_grounded; for a broad/multi-part question... use deep_research'. This provides complete when/when-not 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?

Discloses key behavioral traits beyond annotations: it may have candidate routing improvements enabled live, currently no candidate is active, and it is a fully working router, not a fallback. This adds valuable context about its experimental and time-varying nature, complementing the readOnly and openWorld 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?

Three dense sentences deliver purpose, current state, and usage in a front-loaded manner. Every sentence earns its place with no filler or redundancy.

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

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

The description fully explains what the tool does, its relationship to the stable version, and its current operational state. Since it references the same response shape as ask_pipeworx, it inherits that tool's documentation for output, which is adequate in this context.

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

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

Schema coverage is 100% with all parameters documented as aliases for 'question'. The description adds no parameter-specific meaning beyond what the schema already provides, so it neither enhances nor detracts from the schema's clarity.

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 a beta version of ask_pipeworx, an identical universal router with the same tools, arguments, and response shape. It distinguishes itself from the stable sibling by being the experimental edge with candidate routing improvements.

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

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

Explicitly states to use it exactly like ask_pipeworx when wanting the newest routing and that results are compared against the stable router. It gives clear context for experimental use, though it could more explicitly state when NOT to use it (e.g., when stability is required).

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/openWorld/idempotent annotations, it discloses that extraction uses only tool output, returns structured refusal reasons for non-answer cases, and costs an extra LLM call. This is rich behavioral context that helps an agent predict side effects and failure modes.

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?

Though fairly long, every sentence carries essential information: return shape, refusal reasons, use cases, and cost comparison. It is front-loaded with the core purpose and structured logically.

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 fully specifies both success and refusal response shapes, explains routing, cost, and failure conditions, and provides enough context for an agent to invoke correctly without additional lookups.

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 all six parameters are documented aliases for the same 'question' field. The description adds no extra parameter meaning beyond what the schema already states, 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 states a specific purpose: a 'hallucination-resistant answer mode' that routes through Pipeworx and extracts answers only from tool results. It clearly distinguishes itself from sibling ask_pipeworx by emphasizing grounded extraction and explicit refusal behavior.

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

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

Explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on...' and when not to use: 'prefer ask_pipeworx for casual lookups.' It also names the alternative tool and provides a cost tradeoff.

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. The description adds extensive behavioral detail: low-confidence short-circuits, status codes like 'low_confidence_match', 'market_closed_or_inactive', wide-spread illiquidity notes, cancellation-rule parsing, and news fallback flags. 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 extremely long (roughly 900 words) and densely packed. It is organized with mini-headings (CLASSIFIERS, FAN-OUT EXAMPLES, etc.) and every sentence carries value, but the overall size is excessive for a 3-parameter tool and could be trimmed for readability without losing critical information.

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

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

With no output schema, the description thoroughly documents the return shapes (result.market, result.analysis, result.evidence), the resolver contract (match confidence, score, alternatives, suggestions), parent_event fields, news fallback fields, and blocking statuses. It also addresses safety and cancellation-rule risks, making it fully self-sufficient.

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

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

The schema description covers 100% of the three parameters, including formats, defaults, and size implications. The description adds examples and fan-out contexts but repeats schema details rather than introducing new parameter meaning. 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 action: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It also lists concrete use cases ('should I bet on X', 'what does the data say about Y') and describes the unique fan-out mechanism, distinguishing it from sibling tools.

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

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

The description explicitly states when to use the tool with usage examples and even includes a directive to check cancellation rules before sizing sports bets. It does not name specific alternatives or exclusions, but the context is clear and actionable.

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 idempotentHint=true, but the description goes far beyond: it discloses data sources (SEC EDGAR/XBRL, FAERS), handles off-calendar fiscal years correctly, sorts by primary metric, and returns paired data with citation URIs. It also outlines what metrics are pulled for each entity type, exceeding the safety profile provided 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 long but every sentence earns its place: example queries, explicit preference rule, type-specific data details, fiscal year handling, sort behavior, return format, and performance gain. It is front-loaded with usage triggers and well-structured with separators. No filler or redundancy.

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

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

For a two-parameter tool with no output schema, the description is remarkably complete. It covers what data is pulled, how results are sorted and formatted, and why parallel comparison is better. The absence of an output schema is compensated by describing the return value ('paired data + citation URIs'). There are no major gaps 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 coverage is 100%, so the baseline is 3. The description adds significant meaning beyond the schema: for type='company' it lists exact financial fields pulled (revenue, net income, cash, long-term debt), for type='drug' it lists FAERS counts, FDA approvals, and trial counts, and it gives example value formats ('AAPL','MSFT'). This enriches parameter understanding beyond the enum and item 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 is highly specific: it defines the tool as a side-by-side comparison of 2–5 companies or drugs, with clear verb ('compare') and resource ('entities'). It distinguishes itself from siblings by explicitly stating it is preferred over sequential single-pack lookups, and breaks down behavior by type ('company' pulls 10-K financials, 'drug' pulls FAERS/FDA/trial counts).

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 guidance: 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and 'Replaces 8–15 sequential lookups.' It lists concrete example queries ('Compare X and Y', 'which is bigger') and clarifies when to use each type. This is exactly the kind of when-to-use instruction expected.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context beyond annotations: parallel decomposition across 5,462 tools, findings packet structure, gaps[] never invented, contradictions[] for standard/thorough, semantic excerpting, latency expectations, hop field, and citation_uri fetchability. No contradiction with annotations; in fact, openWorldHint aligns with the note about not being open-web search (it uses structured sources).

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 information-dense, with every sentence earning its place (account requirements, use cases, exclusions, internal mechanics, latency). It is front-loaded with the account note and core purpose, and structured with clear separations. Slightly long but justified for a complex tool; no wasted words.

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

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

Despite no output schema, the description fully explains return structure: findings packet with verbatim evidence, confidence, source, fetched_at, stable citation, gaps[], hop field, contradictions[], and citation_uri resolvability. It covers latency, auth, rate/plan constraints, and comparisons to alternatives. Complete for a tool with 2 params and 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 baseline is 3. The description adds meaningful semantics beyond the schema: depth values ('quick=3', 'standard=5', 'thorough=8') are explained in behavioral terms (gap recovery, contradiction scan, iterative hops), and question is described as accepting broad/multi-part natural language. It doesn't add syntax/format details, but the schema already covers parameter names and enum values.

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

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

The description states a specific verb+resource ('grounded multi-source research across Pipeworx's 1419 STRUCTURED data sources') and clearly distinguishes from siblings by explicitly noting it is NOT open-web search and comparing to ask_pipeworx. It provides concrete use cases like 'compare X and Y's regulatory + financial exposure'.

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

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

Provides explicit when-to-use guidance ('Best for broad/multi-part questions...'), when-not-to-use ('For BREAKING or colloquial CURRENT-NEWS... prefer ask_pipeworx'), and names alternatives directly (ask_pipeworx). Also explains depth tiers and account requirements, giving clear context for selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, but the description adds meaningful behavior: it returns top-N relevant tools with full schemas and curated examples, ready to call without a second schema lookup. This informs the agent what to expect beyond safety.

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 primary purpose, then usage, then output details. Every sentence contributes distinct information with no redundancy.

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

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

For a simple discovery tool, the description covers purpose, usage context, output format, and integration with subsequent calls. It lacks error handling or edge-case behavior, but those are not critical given the simple input and rich annotation 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% with well-documented params (query with multiple aliases, limit). The description reinforces that query is a natural-language description of data or task but adds no new parameter syntax or 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 opens with 'Find tools by describing the data or task', clearly identifying the tool's function. It lists supported domains and distinguishes it from siblings by noting it returns full schemas and is meant to be called first when exploring the option set.

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 text explicitly states 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available and want to see the option set (not just one answer),' giving clear when-to-use guidance. It doesn't name specific alternatives but implies direct tool calls are the alternative.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, but the description adds valuable context beyond these: it fans out across multiple sources in parallel, returns up to 5 filings with specific URIs, and discloses that the USPTO PatentsView API sunset causes a soft-fail until reactivated. This goes well beyond the annotation baseline.

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

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

The description is a single dense paragraph, but it is front-loaded with example queries and uses semicolons to separate return fields, making it scannable. Every sentence contributes substantive information, though formatting could be slightly improved with line breaks for readability.

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 high complexity (multi-source fan-out) and absence of an output schema, the description thoroughly covers all return values (CIK, filings with URIs, fundamentals, patents, news, LEI), input constraints, and known limitations (patents soft-fail, names unsupported). It also cross-references resolve_entity for name resolution, completing the decision context.

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

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

Schema coverage is 100% with both parameters fully described. The description adds extra value by providing concrete examples (ticker 'AAPL' and zero-padded CIK '0000320193') and explicitly restating that names are unsupported, reinforcing and elaborating on the schema guidance without redundancy.

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

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

The description opens with concrete example queries and explicitly states the tool's function: 'full cross-source profile of a US public company in ONE parallel call.' It clearly distinguishes itself from sibling tools by advising preference over chaining single-pack lookups and directing name-based queries to resolve_entity first.

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

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

Provides explicit when-to-use guidance ('when user asks for a holistic view'), a direct preference directive over chaining single-purpose tools, and a clear exclusion: names are not supported and resolve_entity should be used instead. This leaves no ambiguity about appropriate invocation.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, which cover the core safety profile. The description adds the 'sensitive data' rationale and the association with remember/recall, but does not disclose additional behavioral traits such as irreversibility or effects on active context. Since annotations carry the main burden, this is adequate but not enhanced.

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

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

The description is two sentences long, front-loaded with the action, followed by concise usage guidance and sibling pointers. Every sentence earns its place with no redundancy.

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

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

For a simple one-parameter tool with no output schema, the description covers the purpose, when to use it, and how it relates to siblings. It lacks mention of return values or error handling, but given the simplicity and strong annotations, 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 schema has 100% parameter coverage with a clear description for the 'key' parameter ('Memory key to delete'). The description simply reiterates 'by key', adding no new semantic detail beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states 'Delete a previously stored memory by key' with a specific verb (delete), resource (memory), and scope (by key). It also distinguishes itself from sibling tools like 'remember' and 'recall' by mentioning pairing with them, making the 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?

The description provides explicit 'Use when' scenarios (stale context, task done, clearing sensitive data) and suggests pairing with 'remember' and 'recall', offering clear usage context. It does not explicitly state when not to use it, but the given conditions are 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds process context: 'Fetches the page, extracts title/description/key links, and emits the standard llms.txt markdown format.' It also specifies output as 'a single text blob ready to drop at site-root/llms.txt', which gives practical deployment context. 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 action, followed by process details, then use cases. Every sentence adds value with no redundancy. It is well-structured and 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?

The tool is simple with only 2 parameters, rich annotations, and a clear output description ('single text blob ready to drop at site-root/llms.txt'). No output schema is present, but the description adequately explains the return value. The use cases further complete the context, making the description 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 coverage is 100%: both url and max_links have detailed descriptions in the input schema. The description itself only reinforces the url usage ('for any URL') without adding new semantics. Since the schema already carries the parameter meaning, 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 states a specific verb ('Generate') and resource ('llms.txt file for any URL'), and specifies the output format ('standard llms.txt markdown format'). It distinguishes itself from sibling tools like scan_competitor_ai_presence by focusing on generating the file rather than scanning presence, and mentions AI crawlers (ChatGPT, Claude, Perplexity) for additional clarity.

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: 'getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor.' This gives clear context for when to use the tool, though it does not explicitly mention when not to use it or name alternatives. The sibling list offers alternatives like scan_competitor_ai_presence, but the description itself lacks direct 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, lowering the burden. The description adds meaningful behavioral context by specifying exactly what data is returned (fields, geometry type, record count, capabilities), which goes beyond the annotations. However, it does not mention potential network latency or rate limits for external URLs.

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, front-loaded sentence that conveys the action, target, and key output components without unnecessary words or repetition. Every part of the sentence earns its place.

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

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

With a single parameter, strong annotations, and no output schema, the description fully covers what the agent needs to know: inputs (url) and outputs (fields, geometry type, record count, capabilities). It is complete for an information retrieval tool.

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

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

Schema coverage is 100% and the url parameter already has a clear description with an example. The tool description only restates 'by url' without adding new parameter semantics. Thus, the description adds no value beyond the schema.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource (ArcGIS Feature/Map Service layer's schema) and the scope (fields, geometry type, record count, capabilities). It distinguishes itself from sibling tools like query_layer by focusing on metadata retrieval rather than data queries.

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

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

The description implies the tool is for retrieving schema/metadata via URL, but it does not explicitly state when to use this tool versus alternatives like query_layer or search_within. No exclusions or alternative references are provided, so usage context is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, so safety is clear. The description adds value by disclosing the full set of returned fields and the intended use case. It does not hide any side effects, and the 'active' scope plus the include_inactive parameter context are conveyed.

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: the first states the action and return format, the second gives usage guidance. No wasted words; information is front-loaded and easily scanned.

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 list tool with full annotation coverage and a self-explanatory parameter, the description is complete. It covers purpose, return fields, and usage, which 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%, and the parameter 'include_inactive' is fully explained in the schema. The description adds no additional semantic detail about the parameter beyond the schema, which is the baseline expectation.

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 ('List') and resource ('the caller's active subscriptions'), and distinguishes itself from sibling tools like subscribe and unsubscribe. It also lists the exact fields returned, leaving no ambiguity about what the tool does.

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

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

The description explicitly advises when to use this tool: to review current monitoring before adding more subscriptions, or to find an id to cancel. It provides clear context, though it does not explicitly mention alternatives or 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?

Even though annotations only provide false flags, the description reveals key behaviors: filing returns a `claim_token`, the token can be used later to check resolution status, rate limit is 5 per identifier per day, and it's free and doesn't count against tool-call quota. No contradiction with annotations was found.

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 earns its place: purpose, use cases, exclusions, content guidance, token flow, roadmap impact, rate limit, and cost. It is front-loaded with the core action and maintains the reader's attention with specific, actionable details.

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

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

For a feedback tool with no output schema and only false annotation flags, the description is remarkably complete. It covers what to report, when not to report, how to structure the message, what the token means, rate limiting, and expected impact. Agents can correctly select and invoke this tool without additional context.

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

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

Schema coverage is 100% and each parameter already has a clear description. The tool description adds extra meaning by explaining the `claim_token` round-trip workflow (filing without account returns it, pass it back later), and by clarifying message content ('don't paste the end-user's prompt'). This goes beyond the schema without being redundant.

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: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly scopes the tool to feedback on this Pipeworx connection and explicitly distinguishes it from sibling tools by stating which tools are in scope and which are not.

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: bug, feature/data_gap, praise, and even 'other.' It also provides a clear exclusion: if the tool came from a different MCP server, don't file it here—file it with that server instead. This is model-level guidance with alternatives.

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

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

Beyond the annotations, the description adds valuable behavioral context: data provenance ('derived from CF analytics-engine'), privacy ('no PII'), output specificity ('just (pack, tool, count)'), and caching behavior ('Cached 5min-1h depending on window'). This significantly enhances transparency well beyond the readOnly/destructive hints.

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

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

The description is four sentences, each adding distinct value: purpose, return contents, use cases, and technical details. It is well-structured and front-loaded, with no filler or redundancy.

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

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

For a simple read-only tool with no output schema, the description covers return values, data source, privacy, caching, and usage scenarios. It is sufficiently complete for an agent to select and invoke the tool correctly.

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

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

The input schema already provides full coverage (100%) for the single 'window' parameter with enum values and a clear description. The tool description merely repeats the window options without adding new semantic meaning, so the baseline score of 3 applies.

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

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

The description clearly states what the tool does: 'Returns the top tools, top packs, and total call volume' over a recent window. It uses a specific verb ('Returns') and resource ('Pipeworx trending'), and it is distinct from sibling tools like discover_tools or search_datasets.

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 ('Useful for:') that guide when to apply the tool, such as discovering hot data sources or confirming canonical tools. It lacks explicit exclusions or comparisons to alternatives, which would earn a 5, but the clear context justifies a 4.

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 substantial context beyond these: default scanning behavior for top ~200 markets, partition filter that drops placeholder slugs and returns null above 20% threshold, Jaccard similarity guardrail, and the fill_check pricing against live CLOB depth. It even reveals the tool's internal decision threshold (deviations >3pp trigger signals) and the warning that realizable_edge_pp ≤ 0 means the edge is not in the book. This is rich transparency that annotations alone could not 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 but every section earns its place: mode selection, semantic filtering, partition filter, response shape, and fill-check safety. It is front-loaded with the core purpose and the no-args default. Clear all-caps section labels (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK) help an agent parse the dense information. No filler or repetition.

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

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

Without an output schema, the description fully discloses the response structure: opportunities[] with gap_pp, suggested_trade, reasoning, and monotonicity context; partition_check fields including placeholders_filtered; and fill_check fields including theoretical_edge_pp_at_book and realizable_edge_pp. It also explains edge cases (null arb signal, skipped_low_similarity) and gives a concrete safety warning. For a tool with two modes and complex internal logic, 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% and both event and topic have solid schema descriptions. The tool description goes far beyond that: it provides concrete examples ('fed-decision-may-2026' or 'when-will-bitcoin-hit-150k'), explains the semantic anchor threshold (≥0.30 Jaccard similarity), describes how event mode walks child markets, and notes that full Polymarket URLs are accepted. This materially enhances an agent's ability to choose and format parameters correctly.

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

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

The description opens with a specific, actionable statement: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' This clearly distinguishes it from sibling tools like polymarket_edges (edge-focused) and polymarket_fill_risk (sizing-focused). The verb 'Find' plus the resource 'Polymarket' and method 'monotonicity violations + partition-sum checks' makes the purpose unmistakable.

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

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

The description gives explicit when-to-use guidance: no args for trending_scan, 'event (recommended for a specific market)', and 'topic (for cross-event scanning)'. It also names an alternative: 'For custom sizing use polymarket_fill_risk,' and warns 'do not trade it' when realizable_edge_pp ≤ 0, providing a clear when-not-to-act condition.

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 readOnly/idempotent annotations by explaining response segmentation (by_segment), the 24h-move warning, diagnostics for empty segments, the Fed candidates exclusion with reasoning, and caching behavior ('Cached 1h at the KV level keyed on all knobs'). 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 long but extremely well-structured with clear topic separators (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT, TRADEABLE-EDGE KNOBS, RESPONSE TOP-LEVEL) and a front-loaded purpose sentence. Every sentence carries substantive detail, though it could be considered dense for a quick scan.

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

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

Given the tool's complexity (3 model families, 9 parameters, no output schema), the description covers all critical aspects: response structure, diagnostics, knob effects, and even edge cases like stale markets and placeholder filters. It gives callers enough information to understand both output and failure modes.

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

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

Despite 100% schema coverage, the description adds substantial meaning to parameters. For example, it explains why min_partition_leg_kelly exists (parent-level kelly_fraction_half is always 0 for partition arbs) and gives real-world context for slippage_pp (Polymarket fee-free but bid/ask typically 20-50bp). This enhances the schema's technical descriptions with operational rationale.

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

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

The description opens with a clear verb and resource: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' It explicitly ties the tool to everyday bet discovery ('what should I bet on today'), which distinguishes it from sibling tools like polymarket_arbitrage or polymarket_edge_tracker that focus on different aspects.

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 strong usage context ('agents discover opportunities without paging hundreds of markets') and even explains when to adjust knobs (e.g., bump slippage for thin books or set min_liquidity to drop thin-book opportunities). However, it does not explicitly name alternatives or state when NOT to use this tool versus sibling tools, so it stops short of a 5.

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

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

With annotations already declaring a safe read-only/idempotent operation, the description goes further to disclose critical behavioral details: the 60-day TTL bound, snapshot gaps on cache-miss, and that decay is computed from daily closes rather than intraday. These are non-obvious traits that materially affect interpretation of results.

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 its core question, then systematically covers arguments, response shape, and operational limits. Though verbose, every sentence serves a purpose—especially the response breakdown and limits, which are essential for a multi-part telemetry 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?

Since there is no output schema, the description fully specifies the return values (tracked, expired, snapshot_dates) and explains data-quality caveats (TTL, gaps). It is complete enough for an agent to invoke the tool and interpret results correctly without additional context.

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

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

Schema coverage for both parameters is 100%, including defaults, valid values, and clamping. The description recap adds no new meaning—it simply restates the lookback and 'snapshot family' concept already present in the schema, and omits the min clamp, so the incremental value is minimal.

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 tracks 'edge persistence and decay telemetry' from daily polymarket_edges snapshots, answering the specific question 'how long has this edge existed and is it shrinking?'. This distinct focus on historical time-series behavior separates it from siblings like polymarket_edges (current edges).

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

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

The description establishes a clear use case: evaluating whether an edge is fresh or decaying, with context that a wide edge that's persisted for weeks is a different trade. It does not explicitly name alternatives or exclusion criteria, but the context is sufficient for an agent to infer when this tool is appropriate.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses detailed behavior: walking the order book ladder, returning specific fields, interpreting size_usd differently per mode, and warning about partial basket fills and forced directional risk. This goes far beyond the annotations.

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

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

The description is long but dense and well-structured using uppercase mode markers (SINGLE-MARKET, BASKET, USE THIS). It front-loads the core purpose and every sentence carries substantive information. Minor readability improvements (e.g., bullet points) could help, but for the tool's complexity, it is appropriately crafted.

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

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

Since there is no output schema, the description carries the full burden of explaining return values. It enumerates all output fields for both modes, explains the interpretation of size_usd, describes the verdict options, and provides risk context (partial fills, thin legs, forced directional risk). This is fully complete 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?

While the schema has 100% coverage, the description adds meaningful interaction context: the conditional requirement of exactly one of market/event, the mode-dependent default for side ('auto from partition sum'), and the nuanced interpretation of size_usd ('max spend vs target proceeds' in single-market, 'settlement notional' in basket). This enriches the parameter understanding beyond the schema.

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

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

The description clearly states the tool's function: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It specifies two distinct modes (single-market and basket) and differentiates itself from sibling tools like polymarket_arbitrage and polymarket_edges by explicitly positioning as a pre-trade risk check.

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 guidance: 'REQUIRES one of market or event' and 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It names alternative tools and gives a concrete threshold, making the when-to-use context unambiguous.

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

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

Annotations already declare readOnly, idempotent, and openWorld, but the description adds extensive behavioral context: SAFETY FIELDS explain compatibility_warning conditions, temporal_alignment meaning, and skipped_cross_type/subtype semantics. It also clarifies when spreads are meaningless, which is critical for interpreting results.

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 it is well-structured with MODES, RESPONSE, and SAFETY FIELDS headers, making the dense information navigable. Every section contributes necessary details for a complex cross-venue tool, though some sentences pack multiple nuances (e.g., compatibility_warning cases) that could be split for readability.

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

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

With no output schema, the description compensates by explicitly describing the response shape: leg-by-leg raw probabilities, matched spread[].top_spreads_pp, and the meaning of safety fields. It covers edge cases (no matched pairs, temporal misalignment, skipped cross-type/subtype) and practical caveats, leaving little ambiguity for an agent invoking the tool.

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

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

The schema already covers 100% of parameters with clear descriptions and examples, so the baseline is met. The description adds value by explaining how the parameters interact: topic auto-fetches matching events, kalshi_event_ticker and polymarket_event_slug override the topic-mapped side, and the pre-mapped list is emphasized with a caveat against assuming tradeability.

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 'Cross-venue spread between Kalshi and Polymarket' and specifies that it compares pricing for the same resolving question, with details on modes and response structure. This clearly distinguishes it from venue-specific tools and other siblings by focusing on cross-venue spreads with compatibility validation.

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 explains two input modes (topic shortcuts vs explicit event identifiers) and when each is appropriate, including examples like 'fed' and 'KXFED-26OCT'. It warns that 'pre-mapped ≠ tradeable' and that most topics return compatibility_warning, giving practical guidance on real-world use. It does not explicitly name alternative tools, so it lacks explicit exclusion guidance.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds that it 'Returns attribute rows (and geometry)' and clarifies the SQL-like query capabilities, which is useful behavioral context beyond the annotations.

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

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

The description is two sentences, front-loaded with the main verb and resource, followed by a compact parameter list and a useful tip. Every sentence contributes value with no redundancy.

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

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

The description covers the tool's purpose, input source, return content, and offers a usage tip. It could mention pagination details or error handling, but given the schema and annotations, the description is sufficiently complete for a query tool.

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

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

Schema coverage is 100% with clear parameter descriptions. The description adds minimal extra meaning—mainly the sampling tip and the connection to search_datasets—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 states the tool's specific purpose: 'Query an ArcGIS Feature Service / Map Service layer by its url (from search_datasets).' It identifies the resource type and the origin of the URL, which distinguishes it from sibling tools. The parameter list further clarifies the scope.

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 context by stating the URL should come from search_datasets and provides a practical tip for sampling ('Use where="1=1" + out_fields="*" to sample.'). However, it does not explicitly name alternative tools or exclusion criteria, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond that: the scoping mechanism ('Scoped to your identifier (anonymous IP, BYO key hash, or account ID)') and the dual-mode behavior (get a single key or list all keys). This is useful non-obvious information.

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

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

The description is three sentences with the action front-loaded. Every sentence adds value: the core retrieval behavior, practical use cases, and scoping/pairing with related tools. No waste or redundant content.

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

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

For a simple tool with one optional parameter and no output schema, the description fully covers purpose, usage scenarios, scoping, and sibling relationships. It is complete enough for an agent to understand and invoke correctly without further clarification.

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

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

Schema coverage is 100% and the schema already describes the 'key' parameter with the same 'omit to list all keys' semantics. The description reinforces this but does not add additional parameter-level detail or syntax, so baseline 3 is appropriate.

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

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

The description clearly states the action: 'Retrieve a value previously saved via remember, or list all saved keys (omit the key argument).' This specifies the verb, resource, and conditions, and explicitly distinguishes from the sibling tools remember and forget.

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

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

The description provides clear context on when to use: 'Use to look up context the agent stored earlier — the user's target ticker, an address, prior research notes — without re-deriving it from scratch.' It also mentions the scoping (anonymous IP, BYO key hash, or account ID) but does not explicitly state when not to use it or name alternatives beyond remember/forget.

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 explicitly describes a state mutation via mark_read: 'Set mark_read:true to flag returned events read so the next call only shows newer ones.' This contradicts the annotation readOnlyHint: true, which indicates the tool should not modify persistent state. Therefore, the description is contradictory to the annotations, and the transparency score must be 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 three sentences, front-loaded with the primary purpose, and contains only relevant information: return format, filtering, mark_read behavior, polling, and an alternative endpoint. No word is wasted.

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

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

The description covers the return payload (source, citation_uri, raw event), filtering options, mark_read semantics, and alternative access. This is complete for a read-oriented tool. However, the contradiction between mark_read and the readOnlyHint annotation undermines the accuracy of the context, so it falls just short of a 5.

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

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

Input schema coverage is 100%, so the baseline is 3. The description adds a concrete type example ('sec_8k') and explains the behavioral effect of mark_read, which provides some context. However, it does not substantially extend the meaning of parameters beyond what the schema's descriptions already 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 opens with 'Pull fired events from your subscription feed,' which precisely identifies the resource (subscription feed) and the action (pull fired events). This clearly distinguishes it from sibling tools like list_subscriptions (which lists subscriptions) and recent_changes (which tracks changes).

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

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

The description provides clear usage context: you can filter by type or since, poll repeatedly, and mark events read. It also mentions an alternative access method (the GET URL) for scripts/dashboards. However, it does not explicitly name alternative MCP tools or state when not to use this tool, so a 4 is appropriate rather than 5.

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

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

Beyond the read-only and idempotent annotations, the description discloses important behavior: parallel fan-out, GDELT-to-GNews fallback on rate limits or 5xx, and USPTO soft-failure due to PatentsView API sunset. These are non-obvious and valuable for an agent deciding to invoke the tool.

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

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

The description is dense but well-structured: it front-loads user intents, then explains sources, fallback logic, parameter specifics, and the alternative tool. Every sentence contributes essential context, and length is appropriate 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?

With no output schema, the description explicitly states the return shape: structured changes[] grouped by source, total_changes count, and pipeworx:// citation URIs. It also covers source fallbacks, parameter formats, and alternative usage, making it complete for a read-only, idempotent tool.

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

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

Schema coverage is 100% with detailed descriptions for all three parameters. The tool description repeats the same parameter semantics (e.g., ISO/relative `since`, ticker/CIK `value`) without adding new meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly defines the tool as a change feed for a company over a time window, listing specific sources (SEC EDGAR, GDELT/GNews, USPTO) and returning structured changes. It distinguishes itself from sibling entity_profile by explicitly noting the static profile alternative.

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

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

The description provides explicit when-to-use guidance with example queries, and states when not to use it: 'Use entity_profile instead when you want the static profile.' This directs the agent to the correct alternative.

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

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

Annotations already indicate idempotent and non-destructive behavior. The description adds valuable context beyond annotations: scoping by identifier, persistence differences for authenticated vs anonymous users (24-hour retention). It does not mention overwrite semantics, but idempotency covers that.

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, well-structured, and front-loaded with the core action. Each sentence adds distinct information (purpose, usage, storage, persistence, complementary tools) without redundancy.

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

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

For a simple key-value store with no output schema, the description covers all essential context: what to save, when to use, persistence behavior, and how it relates to recall and forget. It is complete for the tool's complexity.

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

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

Schema has 100% coverage for both parameters. The description enhances this by giving concrete examples of keys ('resolved ticker', 'target address') and value types ('any text'), helping the agent choose appropriate values beyond the schema's basic definitions.

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 with a specific verb ('Save') and resource ('data the agent will need to reuse later'). It differentiates from siblings by mentioning key-value storage and pairing with recall/forget.

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

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

Provides explicit use cases ('when you discover something worth carrying forward') with concrete examples, and directs to complementary tools ('Pair with recall to retrieve later, forget to delete'). No ambiguity about when to use.

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

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

Beyond the annotations (readOnly, idempotent), the description discloses internal cascading through multiple lookup endpoints, specific data sources (SEC EDGAR, RxNorm), auto-disambiguation, and output citation URIs. This adds valuable behavioral context about what happens under the hood.

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

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

The description is well-organized with a clear structure: example queries, core purpose, usage instruction, and supported types with details. It is slightly longer than necessary but every sentence contributes useful information, earning its place.

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

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

Given there is no output schema, the description thoroughly explains return values for each type (ticker, CIK, RxCUI, citations). It also covers the use case and internal behavior. It lacks failure-handling details but is otherwise complete for a lookup 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 both parameters, including examples (ticker, CIK, name; brand/generic). The description reiterates the parameter formats but adds little new meaning beyond the schema. It does mention output details, but that is not parameter semantics.

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

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

The description clearly states the tool resolves user-spoken names to canonical identifiers (ticker, CIK, RxCUI) required by other tools, with explicit examples of user queries. It distinguishes itself from siblings by positioning it as a prerequisite for other tools and noting it replaces 2-3 manual lookups.

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

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

It provides explicit when-to-use guidance: 'Use FIRST whenever you have a name but need an ID.' It also explains that other tools require these IDs, establishing context. However, it does not explicitly name alternative tools or state when not to use it, though that is 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavior beyond that: it explains that the tool probes with ai_visibility_check, ranks by score, and returns specific metrics (score, confidence, signal density). This gives the agent a clear picture of the operation's mechanics and output without contradicting annotations.

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

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

Three sentences, front-loaded with the core purpose, followed by method, use case, and return value. Every sentence earns its place with no fluff or repetition of schema details.

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

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

No output schema exists, but the description explicitly lists the return elements (ranked list with score, confidence, signal density). It covers the main behavior and use context. It doesn't discuss edge cases or cost/time implications, but given the strong annotations and moderate complexity, this 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?

Schema description coverage is 100%, so the baseline is 3. The description itself does not add parameter semantics beyond what the schema already provides (e.g., entities role, context purpose, model options). No extra value is contributed here.

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: 'Compare AI visibility across multiple entities side-by-side.' It clearly distinguishes this from the sibling ai_visibility_check (which likely checks a single entity) and compare_entities (generic comparison) by focusing on AI recognition and ranked scoring.

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 a clear use case: 'Useful for competitive AI-marketing audits' with an example query that illustrates when to use it. However, it doesn't explicitly name alternatives or state when not to use it, leaving the differentiation to sibling names and context rather than explicit 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 readOnlyHint, the description discloses important behavioral details: 'Partial failures degrade gracefully — bundlephobia's first measurement on a new version can take 5-30s; sources_failed will list it if it times out, the rest still returns.' It also outlines the return structure and ecosystem limitations, going well beyond annotations.

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

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

The description is front-loaded with purpose, followed by usage, return details, and failure behavior. Every sentence provides distinct value, and the structure flows logically from what the tool does to when to use it to what to expect.

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

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

Given the tool's complexity and the absence of an output schema, the description compensates thoroughly by listing exact summary fields (is_latest, license, published_at, advisory_count, bundle_kb_min, bundle_kb_gz, dependency_count, has_esm, tree_shakeable), per-advisory details, links, recent versions, and timeout behavior. It also scopes ecosystem support clearly.

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

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

The input schema already covers both parameters (package name and version) with 100% description coverage. The tool description adds no substantive additional semantics beyond restating that package is an npm package and version defaults to latest, which the schema already states. Thus the description does not improve upon schema-driven understanding.

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

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

The description clearly states this is a composite check for 'should I add this npm package to my project' and names the exact data sources (deps.dev for license/advisories/version history, bundlephobia for bundle size/dependency count/ESM support). This distinguishes it from siblings by its specific composite nature and resource scope.

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

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

It explicitly says 'Use whenever an agent asks is X safe / popular / small or what does adding lodash cost me' and provides a clear exclusion with an alternative: 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly.' This gives both when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the concrete return shape (name, summary, record_count, owner/org, and url) and the intended downstream usage, going beyond the structured annotations. 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 two sentences, front-loaded with the purpose, and includes return info and next steps with zero waste. Every word earns its place, making it highly concise and well-structured.

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

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

For a search tool with three optional parameters and no output schema, the description covers the main use case, return fields, and the recommended follow-up action (query_layer/layer_info). It doesn't discuss result limits or edge cases, but the simple tool scope and strong annotations mean this 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 covers all three parameters (limit, query, org_id) with descriptions, giving 100% schema coverage. The description adds context about keyword search and the url output but doesn't elaborate parameter syntax or constraints beyond the schema. Baseline 3 is appropriate since the schema handles parameter documentation.

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 'Search Cumberland County GIS open geospatial datasets... by keyword', identifying a specific resource and action. It also lists the return fields and names the downstream tools query_layer/layer_info, which differentiates its role. This is specific, unambiguous, and distinguishes it from siblings.

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

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

The description provides clear context that this tool is for discovering datasets and then instructs 'pass that url to query_layer / layer_info', which implies when to use it. It doesn't explicitly state exclusions or alternatives, but the downstream guidance serves as practical usage direction. This is clear context without formal when-not language.

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?

Despite having annotations for readOnly, openWorld, and idempotent hints, the description adds valuable behavioral details: BGE-base-en embeddings, cosine over 500-char overlapping windows, a 200K char cap with truncation flagging, and character offsets for quote verification. These go beyond the annotation baseline and meaningfully inform the agent of edge cases.

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

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

The description is three dense sentences with no filler. It front-loads the core action, then logically builds to use cases and technical constraints. Every sentence earns its place, and the structure is easy to parse.

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 discloses the return format (top-N passages, character offsets, similarity scores) and the truncation flag. It covers the tool's purpose, usage mode, technical limits, and pairing behavior, making it fully self-contained 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%, so the schema already documents each parameter. The description's mention of "text you already pulled" and "natural-language query" restates the schema's intent rather than adding new parameter-level semantics. Baseline of 3 is appropriate.

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

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

The description clearly states a specific action: "Semantic search INSIDE a fetched record." It distinguishes itself from siblings by describing the post-fetch passage retrieval workflow and explicitly pairing with ask_pipeworx_grounded. The purpose is unambiguous and well-scoped.

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

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

The description gives explicit usage context: "Use when the record is too big to cram into the prompt." It also names the alternative workflow with ask_pipeworx_grounded, explaining the division of labor between fetching and grounding. This clearly answers when to use the tool over alternatives.

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

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

Beyond the annotations (readOnly=false, destructive=false, idempotent=true), the description adds detailed behavioral context: OAuth account requirement, anonymous/BYO restriction, email/SMS verification, 10/day SMS cap, webhook HMAC signing, and auto-disabling after 10 failures. 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 front-loaded with the core purpose. Every sentence contributes, though the long paragraph on delivery channels could benefit from bullet points. Still, no fluff or repetition.

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

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

Despite lacking an output schema, the description covers the return value ('Returns the new subscription id') and critical delivery behaviors. It addresses authentication, supported types, channel options, and failure handling, 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?

While the input schema already provides 100% coverage, the description significantly enriches parameter understanding with concrete examples: 'items:["5.02"] = officer change', 'topic:"fed"', and delivery constraints like 'phone must be verified at /account first'. It explains the webhook signing secret and auto-disable rule, adding value beyond the schema.

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

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

The description opens with a specific verb and resource: 'Create a proactive monitoring subscription to a live-data event stream.' It clearly distinguishes this tool from siblings like list_subscriptions and unsubscribe by focusing on creation and returning a new subscription id.

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 for when to use the tool, including account prerequisites and delivery channels. It references recent_alerts as the pull mechanism for the always-on feed, implying the complementary use of subscribe with that tool. However, it does not explicitly name 'when not to use' or alternatives beyond the feed consumption hint.

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

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

Annotations already cover read-only and idempotent behavior. The description adds valuable context about the return value (category-bucketed example questions with exact tool+argument shape) and that data comes from the live catalog, going beyond the safety annotations.

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

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

The description is front-loaded with example queries and efficiently organized, but it is somewhat dense. Each sentence earns its place, though a slightly more compact structure could improve readability.

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

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

Despite having no output schema, the description fully explains the return structure (categories, tool+argument shape), parameter variations, and use context. It is complete for a simple meta-tool with one optional parameter.

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

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

The schema already has 100% coverage for the 'topic' parameter, including allowed values and omit behavior. The description mostly reiterates this with examples, adding no significant new meaning.

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

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

The description clearly states the tool's purpose as an onboarding entry point for discovering what Pipeworx can do, with specific examples of user queries. It distinguishes itself from siblings by explicitly saying 'Use this FIRST' and referencing meta-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?

It provides explicit when-to-use guidance ('Use this FIRST when you do not yet know what Pipeworx can do for you'), explains optional topic filtering, and mentions alternative meta-tools for continued learning.

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 key behavioral traits beyond annotations: ownership enforcement, deactivation rather than deletion, and that historical events remain accessible. This complements the annotations (destructiveHint=false, idempotentHint=true) 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 extremely concise: two sentences, front-loaded with the action, no wasted words. Every sentence adds value (ownership, soft-delete behavior).

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

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

Given the low complexity (single parameter, no output schema, no nested objects), the description is sufficient: it explains the action, ownership, and side effects. No significant gaps.

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

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

The schema provides 100% coverage for the single parameter 'id' with a description. The tool description adds only that it must be 'your own subscription,' which is more of a behavioral constraint than parameter syntax. Baseline 3 is appropriate.

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

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

The description clearly states the specific action: 'Cancel a subscription by id.' It names the resource (subscription) and the verb (cancel), and implicitly distinguishes from siblings like subscribe and list_subscriptions.

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

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

The description provides clear context about when to use the tool: to cancel a subscription, with the ownership caveat that you can only cancel your own. It doesn't explicitly name alternatives, but the soft-delete behavior implies when not to use it (if permanent deletion is desired).

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. The description adds valuable context: the two-path pipeline (SEC EDGAR + XBRL vs. grounded evidence), the verdict categories, citation format, and performance benefit (replaces sequential calls). 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 well-structured, opening with trigger phrases and then progressively detailing pipeline, outputs, and benefits. Every sentence adds substance, though slightly longer than average. It is appropriately sized for the tool's complexity.

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

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

With no output schema, the description covers return values (verdict categories, actual value, citation, reasoning). It also explains the two routing paths. Minor gaps remain (e.g., error handling, latency) but annotations cover safety, making this reasonably complete 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 covers 100% of parameters, but the description adds significant meaning beyond the schema: it explains how tolerance_pct overrides claim wording, provides a default cap of 5, and suggests using 1–2 for hallucination detection. This goes beyond mere 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 explicitly states the tool performs natural-language claim verification, with a clear verb ('validate') and resource (factual claims). It includes user-phrase examples and distinguishes itself from siblings by noting it replaces 4–6 sequential calls.

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

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

It clearly states 'Use whenever the agent needs to check whether something a user said is factually correct.' It also differentiates the structured SEC path vs. the grounded fallback, providing clear conditional usage. It does not explicitly name sibling tools as alternatives, but the guidance is specific enough.

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