Udbud Dk

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 critical behavioral details: default model (Workers AI Llama-3.3-70b, free), cost implications for Anthropic (BYO key), and output structure (per-model {score, confidence, signals, raw_response} + combined view). This fully informs the agent.

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

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

The description is three sentences, front-loaded with the primary purpose, and every sentence adds value. No redundant or filler content. Efficient and well-structured.

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

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

Despite lacking an output schema, the description enumerates return fields per model and a combined view. It covers key nuances: optional parameters, cost implications, and use cases. The tool is complex (multiple models, optional keys), and the description is complete enough for correct invocation.

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

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

Schema coverage is 100% (all four parameters have descriptions). The description adds value beyond the schema by explaining the 'context' parameter's role in disambiguation and clarifying that 'models' array supports specific strings. This goes beyond baseline 3.

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

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

The description clearly states the tool probes LLMs for brand visibility and scores it, with a specific verb ('probe') and resource ('LLMs for what they know'). However, it does not explicitly distinguish from sibling tools like 'deep_research' or 'scan_competitor_ai_presence', so it falls short of a 5.

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

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

The description provides clear usage context: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It explains when to use the _apiKey parameter for Anthropic. It does not state when not to use the tool or give alternatives, but the context is sufficient.

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

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

Annotations already establish readOnly, openWorld, and idempotent behavior. The description adds useful behavioral context: internal routing across many tools, automatic argument filling, and citation URIs in the response. There is no contradiction with annotations, though it does not discuss failure modes, rate limits, or response 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 long but information-dense and front-loaded: the web-search preference, scope, routing behavior, trigger phrases, examples, and sibling alternatives are ordered sensibly. It could be tightened slightly, but each sentence contributes decision-relevant guidance.

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

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

With no output schema, the description carries responsibility for explaining return behavior; it does so by mentioning structured answers and stable citation URIs. It also covers triggers, sources, routing, and alternatives. It stops short of describing the exact response shape or failure behavior, but it is strong enough for an agent to select and invoke the tool.

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

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

Schema coverage is 100%, with all six parameters documented as aliases for the natural-language question. The description reinforces that input is a natural-language question and that the tool fills arguments, but it does not add meaning 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 a specific behavior: routes questions to one of 5,798 tools across 1,517 verified sources, fills arguments, and returns structured answers with stable pipeworx:// citation URIs. It also distinguishes itself from siblings like ask_pipeworx_grounded and deep_research, so an agent can select it confidently.

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 instructs 'PREFER OVER WEB SEARCH' and states when to use it: factual questions about real-world entities, events, numbers, or current/historical data. It also gives clear alternative routing: ask_pipeworx_grounded for single/direct/definitive facts, deep_research for broad/multi-part questions, and notes how breaking-news requests are handled.

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

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

The description goes well beyond the provided annotations by disclosing that candidate routing improvements may be enabled live, that no candidate is currently active, and that this is a full working router with no fallback. It also explains that results are compared against the stable router to inform merges. This gives an agent a rich understanding of the tool's experimental and mutable behavior.

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

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

The description is somewhat long but each sentence adds necessary context about the beta status, current candidate state, and relationship to ask_pipeworx. Key information is front-loaded with 'Beta version of ask_pipeworx' and the identical-router statement. Minor redundancy exists in emphasizing 'full working router' after already saying it is identical, but the extra clarification supports safe use.

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

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

Given the tool's complexity as a beta alias, the description covers what it is, how to use it, current behavioral state, and what distinguishes it from the stable router. It also references the same response shape as ask_pipeworx, compensating for the absence of an output schema. An agent has enough information to invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents all six parameters, with question as the required field and five aliases described. The description adds only that the arguments are identical to ask_pipeworx, which does not materially deepen parameter understanding. Since the schema carries the semantic load, a baseline of 3 is appropriate.

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

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

The description clearly identifies this as the beta version of ask_pipeworx, an identical universal router with the same tools, arguments, and response shape. It differentiates itself from the stable ask_pipeworx through its experimental routing, which is sufficient for an agent to understand what it does. However, the core user-facing function—answering natural-language questions—is implied rather than explicitly stated.

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

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

The description gives explicit usage guidance: 'Use it exactly like ask_pipeworx when you want the newest routing.' It also clarifies the current state (no candidate active, so it matches ask_pipeworx exactly), helping an agent decide when to invoke it. It does not explicitly state when not to use it or name a stable alternative as the safer choice, but the intended selection criterion is clear.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds substantial behavioral detail beyond that: hallucination resistance, explicit refusal reasons, exact success and refusal return shapes, and the extra LLM call cost. It also reveals the internal routing over 5,798 tools, which is not available in annotations or schema.

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

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

Four dense sentences, front-loaded with the primary purpose, then mechanism, return/refusal contract, and usage guidance with cost. Every sentence contributes distinct, decision-relevant information with no filler or redundancy.

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

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

With no output schema, the description fully specifies the success return shape and the explicit refusal contract with all possible refusal_reason values. It also covers when to use vs avoid, the cost implication, and the behavioral guarantee. Nothing essential is missing for an agent to decide whether to call it and interpret the result 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%: all six parameter properties are aliases for 'question' with a clear natural-language description. The description adds no parameter-level semantics beyond noting the tool fills arguments internally, which is a routing behavior rather than input guidance. Per the calibration baseline, a 3 is appropriate when the schema does the heavy lifting.

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

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

The description opens with 'Hallucination-resistant answer mode for high-stakes reads' and immediately explains it routes to the right tool, fetches data, and extracts an answer using only the tool result. This clearly distinguishes it from ask_pipeworx and other siblings by specifying the grounded, evidence-based mode. The verb, resource, and scope are all explicit.

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

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

It explicitly says to use this mode 'whenever an answer will be quoted, cited, or acted on' and gives concrete high-stakes examples. It also names the alternative ask_pipeworx and instructs to prefer it for casual lookups, citing the cost tradeoff of one extra LLM call. This is exactly the when/when-not guidance an agent needs.

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

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

Annotations already indicate readOnly, idempotent, openWorld. Description adds extensive behavioral details: response shapes, match confidence, edge cases (closed markets, wide spreads), resolution-rule risk, and safety mechanisms, far exceeding what annotations provide.

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

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

The description is very long (~500 words) and dense, but structured with sections and front-loaded with a clear purpose. While informative, it could be more concise without losing essential details, given the tool's complexity.

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

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

Despite no output schema, the description thoroughly details response shapes, resolver contract, parent event extraction, news fields, and safety mechanisms. It covers all practical aspects an agent needs for correct invocation and interpretation.

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 parameters (100% coverage). The description adds value by explaining the market parameter accepts slug, URL, or text, and implicitly clarifies depth and include_raw through examples and fan-out descriptions, going beyond schema details.

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 researches a Polymarket bet by pulling Pipeworx data, with specific usage examples ('should I bet on X'). It distinguishes from sibling tools like polymarket_edges by focusing on evidence packet and market-vs-model comparison.

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

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

The description provides explicit use cases and conditions like low-confidence matches and closed markets. It lacks direct comparison with alternatives but offers sufficient context for 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavioral context: for company type, pulls latest 10-K financials from SEC EDGAR/XBRL with off-calendar year handling; for drug type, pulls FAERS, FDA counts, trial counts. Also mentions result sorting and citation URIs. No contradictions.

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

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

The description is front-loaded with common query examples and the key instruction to prefer this tool. It is somewhat lengthy but each sentence adds value. Could be slightly more concise by compressing some details, but overall well-structured and readable.

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

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

For a tool with two parameters and no output schema, the description covers input constraints (2-5 entities, company or drug), data sources, fiscal year handling, result ordering, and output format (paired data + citations). It is fully complete given the tool's complexity and the richness of annotations.

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

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

Schema description coverage is 100% with enums and descriptions. The description adds examples (tickers for company, drug names) and explains what data is fetched per type. This adds meaning beyond the schema, justifying a score above baseline 3, but not a 5 as the schema already covers basic 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 uses specific verbs like 'compare', 'rank', 'head to head' and clearly states the resource: side-by-side comparison of 2–5 companies or drugs. It distinguishes from sibling tools (e.g., entity_profile) by emphasizing parallel batch comparison over sequential 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?

The description explicitly instructs 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and provides example queries. It does not explicitly state when not to use, but the scope (2-5 entities, company or drug) is implied. Clear context with no exclusions.

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

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses account requirements, paid-tier limits, expected latency, no-fabrication behavior, gaps[], contradictions[], citation_uri resolvability, and semantic excerpting of large records. These are valuable behavioral traits not inferable from annotations alone.

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

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

The description is long but densely packed with non-obvious operational details: auth, alternatives, latency, citation behavior, gap handling, and depth semantics. It is front-loaded with the most critical blocking information (account required) and then flows logically from core behavior to output details to performance expectations.

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 present, the description fully describes the return packet: verbatim evidence, confidence, source, fetched_at, pipeworx:// citation, gaps[], contradictions[], and hop/citation_uri fields. It also covers auth, depth modes, alternatives, and timing, so an agent has everything needed 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?

Although schema coverage is 100%, the description adds significant operational meaning to the depth parameter: quick=3 facets/single hop, standard=3 facets with gap recovery and contradictions, thorough=6 facets with lead-chasing and paid requirement. It also clarifies that the question parameter is natural language and that multi-part questions are expected.

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 names a specific operation: grounded multi-source research across Pipeworx's 1517 structured data sources in a single call, explicitly contrasting with open-web search. It also gives concrete example questions and distinguishes itself from the sibling ask_pipeworx by scope and use case.

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

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

The description gives explicit when-to-use guidance: best for broad/multi-part questions over structured data, and explicitly says to use ask_pipeworx for a single lookup or when not signed in. It also clarifies depth-mode tradeoffs, including the paid requirement for 'thorough'.

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. The description adds that results are 'ready to call directly, no second schema lookup needed,' which is a behavioral promise. No contradictions.

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

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

The description is a single paragraph but packs essential information: purpose, use case, domains, return format, and call timing. It is efficient though slightly dense; no redundant sentences.

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

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

Without an output schema, the description explains return format (names, descriptions, schemas with examples). It covers what the tool does, when to use, and what to expect. Missing are details on error cases or edge limits, but for a discovery tool it is adequate.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions 'query' implicitly via 'natural language description' and 'top-N' hints at 'limit', but does not add significant extra meaning beyond what the schema already provides. It does not elaborate on parameter syntax or examples beyond the schema's examples.

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

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

The description uses a specific verb ('Find tools by describing') and resource ('discover_tools'), lists concrete domains (SEC filings, FDA drugs, etc.), and distinguishes itself by stating 'Call this FIRST' when many tools are available. It effectively differentiates from sibling tools like deep_research or specific data 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 explicitly states when to use ('Call this FIRST when you have many tools available and want to see the option set') and provides context (not just one answer). It does not explicitly state when not to use, but the guidance is clear enough for an AI agent.

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

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

Annotations already show readOnlyHint, idempotentHint, and openWorldHint. The description adds that the tool returns a shaped summary and the complete notice text, including language and character limit options. No contradictions, and it enhances understanding of behavior 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 concise, front-loaded with purpose, and structured as a single clear paragraph. Every sentence adds value without redundancy.

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

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

With 5 parameters and no output schema, the description compensates by detailing the output fields (title, buyer, etc.) and explaining the language and character count parameters. It also ties to sibling tools, making it fairly complete for a fetch operation.

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 description adds context that parameters come from search results and provides an example. However, it does not add significant new semantic meaning beyond the schema.

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

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

The description clearly states the tool fetches a Danish public-procurement notice in full detail, listing specific fields (title, buyer, CVR, etc.) and the source (udbud.dk). It distinguishes itself from sibling tools dk_tender_search and dk_tender_recent by requiring their output.

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 explains that the tool requires notice_id, notice_version, and publication_number exactly as returned by dk_tender_search or dk_tender_recent, providing clear prerequisites. It does not explicitly list when not to use or alternatives, but the context is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context: returns shaped notices newest-first, includes fields like buyer with CVR, CPV, DKK value, and mentions the source udbud.dk. 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 a single focused paragraph that front-loads the primary action. Every sentence adds value, covering purpose, use case, optional filters, and output fields without waste.

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

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

Given no output schema, the description thoroughly explains the return format (fields like notice id, title, buyer with CVR, CPV, DKK value, deadlines, URL). It also provides context about coverage of national below-EU-threshold notices, making it fully self-contained for a list tool.

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

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

Schema description coverage is 100% (all 5 parameters documented). The description merely restates the option to restrict by notice type or status, adding no new semantic meaning beyond the parameter descriptions. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists the latest Danish tenders from udbud.dk within N days. It specifies the content (awards, direct awards, deadlines) and explicitly distinguishes itself from TED, making its purpose unique and distinct from siblings like dk_tender_search.

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

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

The description explains it is great for monitoring new notices and includes national below-EU-threshold udbud. It implies use for time-bound recent listings but does not explicitly exclude alternative use cases or compare to sibling dk_tender_search.

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 as true. The description adds value by detailing return format (newest-first, specific fields), free-text search behavior, and the scope of coverage. It does not contradict annotations.

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

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

The description is well-structured: it opens with purpose, then usage preference, coverage, parameter hints, and return format. It is slightly verbose but every sentence adds information appropriate for a complex tool.

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

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

Given the tool has 10 parameters, no output schema, and moderate complexity, the description is thorough. It explains the tool's scope, preference over web search, parameter usage, and return structure, leaving no major gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds contextual meaning beyond the schema, such as 'Danish terms work best' for query and guidance on obtaining CVRs from prior search results. These enrich parameter understanding.

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

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

The description clearly states the verb 'Search' and the resource 'Danish government public-procurement notices on udbud.dk'. It specifically covers all notice types for Danish tenders. While it doesn't explicitly differentiate from sibling tools like dk_tender_detail or dk_tender_recent, the scope is distinct enough to imply usage.

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 recommends preferring this tool over web search for Danish public tenders, listing covered categories. However, it does not provide guidance on when to use this tool versus sibling tools (dk_tender_detail, dk_tender_recent), which are present in the sibling list.

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

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

Beyond the readOnly/idempotent annotations, the description discloses substantial behavior: parallel fan-out across sources, return shape highlights, fallback chains, soft-fail behavior for patents, and explicit 'resolved:false' handling for private companies. It also explains that sources_failed indicates real absences, not bugs, which is highly useful operational context.

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

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

The description is long but every clause adds functional detail: trigger phrases, input forms, source fan-out, return keys, fallback behavior, and failure semantics. It is front-loaded with the core purpose and usage guidance. Slightly dense and run-on, but not padded.

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

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

There is no output schema, so the description carries the full burden of explaining return values — and it does, enumerating cik, resolved_to/from, recent_filings URIs, fundamentals, and each source section. It covers inputs, outputs, failure modes, and acceptance criteria, leaving little ambiguity for a complex multi-source 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 already 100%, and the description goes further by giving concrete example values, explaining that type accepts 'company' or 'ticker' interchangeably, and detailing how values resolve via SEC EDGAR company-name matching. This meaningfully enriches the schema's bare parameter descriptions.

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

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

Clearly states this is a 'full cross-source profile of a US public company in ONE parallel call' and grounds the purpose with concrete user phrasings like 'Tell me about X' and 'brief me on Tesla'. It distinguishes itself from single-pack SEC/XBRL/news lookups and names the output domains, making the tool's role unmistakable among siblings.

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

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

Provides explicit when-to-use guidance: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also clarifies edge-case behavior for private companies and explains that empty sections are expected rather than failures, which prevents misinvocation.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds context about clearing sensitive data and that the memory was saved earlier, which is helpful but not extensive. No contradiction with annotations.

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

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

Three concise sentences: first states the action, second gives use cases, third relates to siblings. No redundant information, 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?

Given the simplicity of the tool (delete by key), the description covers purpose, usage scenarios, and relationship to siblings. Annotations cover destructiveness and idempotency. No output schema needed for a delete operation.

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

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

Schema coverage is 100% with a clear description for the key parameter. The description does not add additional meaning beyond what the schema provides, so score is at baseline.

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

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

The description clearly states the tool deletes a previously stored memory by key, specifying the verb ('Delete') and the resource ('memory'). It also mentions pairing with remember and recall, which distinguishes it from siblings that store or retrieve memories.

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

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

Explicitly provides when to use: 'when context is stale, the task is done, or you want to clear sensitive data'. Also pairs with remember and recall, giving context about alternative tools.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by explaining the process (fetch, extract, emit) and output format, providing behavioral context beyond what annotations offer. No contradictions.

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

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

The description is very concise at three sentences, with the purpose stated first, followed by process and use cases. No superfluous words; every sentence earns its place.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers purpose, process, output format, and use cases. It does not mention error handling or response structure details, but for a read-only, idempotent tool, this is nearly 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%, but the description adds meaningful details: default and max for 'max_links' parameter (default 25, max 50) and clarifies that 'url' can be a full URL or specific landing page. This goes beyond the schema's basic descriptions.

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

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

The description clearly states the tool generates a llms.txt file for a URL, specifying the verb 'generate', the resource 'llms.txt file', and the output format. It distinguishes from siblings like 'ai_visibility_check' by focusing on the specific action of creating the file.

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

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

The description lists explicit use cases (client sites, own projects, competitor auditing) which help the agent decide when to use it. However, it does not explicitly exclude cases or name alternatives among siblings, so it lacks direct 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. Description adds value by specifying default behavior (active only) and the specific fields returned, which is useful 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?

Two sentences: first clearly states action and return fields, second provides usage guidance. No unnecessary words, front-loaded with core purpose.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description covers purpose, returned fields, and usage adequately. Annotations provide safety profile, making this 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% for the single parameter 'include_inactive' with a description. The tool description implies the default behavior (active only) but does not add additional syntax or format details beyond what the schema already provides, so baseline 3 is appropriate.

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

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

Description clearly states the tool lists the caller's active subscriptions, specifies returned fields (id, type, params, created_at, last_fired_at, fire_count), and distinguishes from sibling tools like subscribe and unsubscribe by focusing on read-only listing.

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

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

Explicitly gives two use cases: review before adding more subscriptions and find an id to cancel. Provides clear context, though does not explicitly mention when not to use or list alternatives beyond the implied counterparts.

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 all set to false, the description carries the full burden and excels: it discloses rate limiting (5 per identifier per day), free usage (doesn't count against quota), the claim_token mechanism for follow-up, and the daily review process. This goes far beyond what annotations provide and gives the agent a complete behavioral picture.

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

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

The description is front-loaded with the core purpose and usage conditions, then progressively covers exclusions, content guidelines, the claim_token workflow, and operational facts. Every sentence earns its place; the paragraph is dense but not bloated, and the logical flow from 'when to use' to 'when not to use' to 'how it works' makes it easy to scan.

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

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

Given the tool's moderate complexity (4 params, nested context object, no output schema), the description fully compensates for the missing output schema by explaining the claim_token return mechanism and how to follow up. It also provides sufficient context about rate limits, cost, and feedback impact, making the tool self-contained for correct invocation and expectation-setting.

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

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

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds valuable semantic guidance beyond the schema, such as instructing not to paste the end-user's prompt, specifying that the claim_token should be passed alone to read a prior report, and clarifying the message should be in terms of Pipeworx tools/packs. This extra context justifies a score above baseline.

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

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

The description opens with a specific verb phrase, "Tell the Pipeworx team something is broken, missing, or needs to exist," which clearly defines the tool's purpose. It also enumerates the four categories (bug, feature, data_gap, praise) and distinguishes this tool from siblings like ask_pipeworx or discover_tools by positioning it as the reporting channel for Pipeworx service issues.

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: when a tool returns wrong data (bug), when a desired tool is missing (feature/data_gap), or for praise. It also gives a clear exclusion, telling users NOT to report issues for tools from other MCP servers and directing them to file with that server instead, which is an explicit 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 readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds valuable context: data source ('CF analytics-engine'), lack of PII, caching behavior (5min-1h), and exact return content ('(pack, tool, count)'). This goes beyond annotations, though some details like rate limits are absent.

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

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

The description is well-structured with a clear lead sentence followed by bullet points. Every sentence adds value, though it could be slightly more compact. The front-loading is effective.

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

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

Despite no output schema, the description explains return values (top tools, packs, volume) and notes caching and data origin. For a simple one-parameter read-only tool, this is sufficient. No major gaps identified.

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

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

Schema coverage is 100% with one parameter described. The description adds semantic guidance on window selection ('shorter windows surface what's hot right now; longer windows show steady-state demand'), which is not in the schema enum descriptions.

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

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

The description clearly states the verb ('Returns') and the resources ('top tools, top packs, and total call volume'). It also specifies the window parameter, distinguishing this tool from siblings like 'ask_pipeworx' or 'discover_tools' which serve different 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?

Three explicit use cases are listed, covering discovery, validation, and alignment. The window choice guidance ('shorter windows surface what's hot right now; longer windows show steady-state demand') adds actionable context. However, it does not explicitly state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, etc., and the description adds rich behavioral context: semantic anchor (Jaccard similarity >=0.30), partition filter (placeholder slugs), fill check against live CLOB depth, realizable edge vs theoretical edge. 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 detailed and front-loaded with key info, but somewhat lengthy. Every sentence adds value given the complexity; minor restructuring could improve conciseness.

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

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

No output schema, so description explains return values thoroughly (opportunities array with fields, partition_check in event mode, fill check details). Covers all modes and edge cases (e.g., placeholder filter, similarity threshold). Complete for a complex tool.

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

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

Schema coverage is 100%, but the description greatly expands meaning: explains event slug format, that full URLs accepted, topic seed question examples. Also describes how each parameter triggers specific algorithms and output structures.

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

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

The description clearly states the tool finds arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes three modes (no-args, event, topic) and is distinct from sibling tools like polymarket_edges or polymarket_fill_risk.

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

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

Explicitly tells when to use each mode: no args for trending scan, event for specific market (recommended), topic for cross-event scanning. Also advises when to use another tool: 'For custom sizing use polymarket_fill_risk.'

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

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

The description extensively details behavioral traits beyond annotations: caching (1h at KV level), the three response segments (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, CONCENTRATED_LONGSHOT), diagnostics for empty segments, and the 24h-move warning. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, and the description adds rich context without contradiction.

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

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

The description is long but well-structured and front-loaded with purpose. It efficiently covers complex details (model families, response structure, diagnostics) without redundancy. Slightly verbose for a concise ideal, but justified by the tool's complexity.

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

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

Given 9 parameters and no output schema, the description thoroughly explains the response top-level structure, diagnostics, edge cases (Fed bets, empty segments), and caching. It provides complete contextual information for an AI 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 baseline is 3. The description provides high-level context for the knobs (e.g., 'Tradeable-edge filters') but does not add new meaning beyond the schema descriptions. The schema already fully documents each parameter, so the description's marginal value is limited.

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

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

The description clearly states the tool scans top Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It specifies the verb 'scan' and resource 'Polymarket markets', and distinguishes from siblings like polymarket_arbitrage by focusing on edge opportunities from Pipeworx models.

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

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

The description explicitly states the tool is 'built for what should I bet on today' and that agents discover opportunities without paging hundreds of markets. It provides context for when to use it, though it does not explicitly list alternatives or when not to use it. The tradeable-edge knobs and Fed bets exclusion give clear usage guidance.

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

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

Annotations declare readOnlyHint=true, and the description adds extensive behavioral details: how snapshots are written (cache-miss), the computation of trend and decay, limits (60-day TTL, daily closes), and gaps in data. No contradiction with annotations.

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

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

The description is dense but front-loaded with the core purpose. It efficiently covers args, response structure, and limits without unnecessary verbiage. Slightly wordy but each sentence adds value.

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

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

Despite having no output schema, the description provides a complete explanation of the response format, including all fields (tracked, expired, snapshot_dates) and edge cases (snapshot gaps, TTL, median lifespan). Enough for an agent to use 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?

Both parameters are described in the input schema (100% coverage). The description restates default values and adds a max clamp for days, but adds minimal new meaning beyond the schema.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily polymarket_edges snapshots. It answers the question 'how long has this edge existed and is it shrinking?', distinguishing it from sibling tools like polymarket_edges that provide raw edge data.

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

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

The description implies usage context by framing the tool as answering a specific question about edge aging. While it does not explicitly compare to alternatives or state when not to use, the purpose is clearly communicated, allowing an agent to infer appropriate scenarios.

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 details the tool's behavior beyond annotations (readOnlyHint, idempotentHint): it walks the order book ladder, returns metrics like top_of_book, vwap_fill_price, slippage_pp, and a verdict (clean|degraded|cannot_fill). It also warns about risks of partial fills and unhedged directional positions. No contradiction with annotations.

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

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

The description is well-structured with separate sections for each mode and usage guidance. It is slightly lengthy but each sentence adds value. Front-loaded with purpose and mode requirements.

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 comprehensively lists return values for both modes, including verdict, capture_ratio, profit_usd, thin_legs, and forced_directional_risk. It covers prerequisites, mode selection, and practical risks, making it complete for a complex tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that size_usd in basket mode is settlement notional (shares per leg) and side defaults to auto based on partition sum. This clarifies behavior 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 specifies the tool's purpose clearly: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It distinguishes between single-market and basket modes, and differentiates from sibling tools like polymarket_arbitrage and polymarket_edges by focusing on fill risk assessment.

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

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

Explicit guidance is provided: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It explains the rationale—theoretical overround on thin books is not capturable and partial fills cause directional risk—which helps the agent decide when to invoke this tool.

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

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

The description goes far beyond the annotations, disclosing compatibility warnings and codes, per-pair flags, the fact that unclassified legs are never paired, the null-meaning of temporal_alignment, the gross-not-net fee limitation, and skipped comparison counters. It also reinforces the readOnly/idempotent annotation by framing the tool as an analytic lookup, with no contradiction.

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

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

The description is long, but it is densely informational and well-labelled with TWO MODES, RESPONSE, and SAFETY FIELDS. Every block serves a purpose, especially because there is no output schema to otherwise document the return contract.

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

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

Given the tool's complexity and the absence of an output schema, the description is remarkably complete: it covers invocation modes, response contents, warning semantics, matching limitations, fee caveats, and diagnostic counters. The only minor omission is the no-arguments default, but with zero required parameters and clear examples, the definition is still sufficient for correct invocation.

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

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

Even though the schema covers 100% of parameters, the description adds crucial meaning: the 10 exact topic values, that explicit ticker/slug override the topic-mapped side, and that both invocation modes run identical matching logic. This is precisely the kind of behavioral parameter context that a bare schema cannot convey.

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

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

The description immediately pins down the tool's purpose: computing the cross-venue spread between Kalshi and Polymarket for the same resolving question, with Kalshi-minus-Polymarket spread semantics. It also distinguishes itself from Polymarket-only sibling tools by emphasizing the cross-venue nature and the matching of equivalent bet shapes.

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

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

It clearly explains when to use `topic` shortcuts versus explicit `kalshi_event_ticker` + `polymarket_event_slug` pairings, and states both modes run the same matcher. It warns that pre-mapped topics often are not tradeable, but it never names a specific sibling tool as the better alternative for a given case.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds scoping information ('Scoped to your identifier - anonymous IP, BYO key hash, or account ID'), which is not in annotations. No contradictions.

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

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

Three sentences, front-loaded with the essential purpose. Every sentence adds value (purpose, usage, scoping, pairing). No redundancy.

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

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

Given a simple tool with rich annotations and clear schema, the description provides complete context: purpose, usage, scoping, and relationship to siblings. No output schema needed for such a 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 has 100% coverage (one param with description). Description adds behavior for omitting the key parameter ('omit the key argument to list all saved keys'), which is not in the schema description, thus adds 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?

Description uses specific verbs 'Retrieve' and 'list' with clear resource ('value previously saved via remember' and 'all saved keys'). Explicitly distinguishes from sibling tools 'remember' and 'forget' by naming them.

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

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

States clear use cases: 'look up context the agent stored earlier ... without re-deriving it from scratch.' Mentions pairing with remember/forget. Does not explicitly state when not to use or list alternatives beyond the sibling context, but is sufficient.

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

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

Annotations already indicate readOnlyHint=true, so the description adds value by detailing the returned data (source, citation_uri, payload) and the mark_read side effect. 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 concise, front-loaded with purpose, and every sentence adds meaningful information without redundancy.

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

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

Given no output schema, the description adequately describes the return values and covers all parameters. Combined with rich annotations, the tool is fully documented for an agent to use correctly.

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

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

All 5 parameters are documented in the schema (100% coverage). The description adds helpful context beyond the schema, e.g., explaining mark_read behavior and that since expects an ISO timestamp, justifying a score above baseline.

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

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

The description clearly states the tool 'pull fired events from your subscription feed,' specifying both the action and resource. It distinguishes itself from sibling tools like list_subscriptions or subscribe by focusing on alert retrieval.

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 guidance on filters (type, since), the mark_read parameter for read tracking, and notes that polling works and that the same feed is accessible via a direct URL for scripts/dashboards. It does not explicitly state when to avoid this tool, but the context is sufficient.

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

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

Annotations indicate readOnlyHint, idempotentHint, and non-destructive, which the description reinforces and expands upon by disclosing parallel fan-out, fallback mechanisms, and soft-fail for USPTO. It also describes output structure (changes[], total_changes, citation URIs).

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 yet comprehensive, using a single paragraph with no redundant sentences. It is front-loaded with example queries and efficiently covers all essential details.

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

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

Despite lacking an output schema, the description explains the return structure and covers all relevant aspects of the tool's behavior, including multiple data sources, fallbacks, and date parsing. It provides complete context for an AI agent to use 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%. The description adds meaningful context: explains 'since' accepts ISO or relative shorthand and recommends typical values, clarifies 'value' accepts ticker or CIK, and notes that 'type' is currently limited to 'company'.

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

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

The description clearly states the tool's purpose: providing a change feed for a company within a specified time window. It gives specific use-case examples ("What's new with X") and explicitly distinguishes itself from the sibling tool 'entity_profile' for static profiles.

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

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

The description provides explicit when-to-use scenarios (e.g., 'latest on Y') and when-not-to-use (static profile via entity_profile). It also details fallback behavior (GDELT to GNews) and date format options.

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 include idempotentHint, destructiveHint, readOnlyHint. Description adds scoping by identifier, persistence differences for authenticated vs anonymous (24h). No contradictions.

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

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

Concise, front-loaded with purpose. Every sentence adds information 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?

Simple tool with 2 required params and no output schema. Description fully explains usage, storage behavior, and complementary tools. No gaps.

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

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

Input schema covers both key and value with descriptions. Description adds context (e.g., key examples like 'subject_property') but does not significantly exceed schema. Baseline 3 justified.

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

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

Clear verb+resource: 'Save data the agent will need to reuse later.' Distinguishes from siblings by naming recall and forget, and specifying key-value pair storage.

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

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

Explicitly says when to use: 'when you discover something worth carrying forward.' Recommends pairing with recall and forget, providing clear guidance on alternatives.

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

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

Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds substantial behavioral detail beyond that: internal cascading through multiple lookup endpoints, graceful degradation when GLEIF or OpenFIGI is unavailable, explicit handling of unresolved identifiers under an 'unresolved' field rather than omitting them, and clarification that non-equity instruments without tickers still resolve. 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?

Though long, the description is densely packed and every sentence earns its place: example queries, supported types, per-type identifier details, fallback behavior, and a final value-add statement about replacing manual lookups. It is organized with clear labels and front-loads the purpose before diving into specifics.

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 entity-resolution tool with no output schema, the description provides complete calling context: accepted input forms, per-type outputs and sources, ownership enrichment details, unknown-identifier behavior, and system-unavailable fallbacks. An agent has everything needed to invoke it correctly and interpret results.

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

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

Schema coverage is already 100%, with useful parameter descriptions. The description goes further by explaining exactly how to format 'value' for each type, giving examples (AAPL, 0000320193, ozempic), and warning against passing full noun phrases for bonds because trailing security-class words will match nothing. It also enriches the 'type' parameter by detailing what each enum value returns.

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 user-phrase examples and states the core operation: resolving a user-spoken NAME to canonical/official identifiers that other tools require as input. It is specific about supported types ('company', 'drug') and the identifiers returned (CIK, ticker, LEI, FIGI, RxCUI), making the purpose unmistakable even among a large sibling list.

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 guidance: 'Use FIRST whenever you have a name but need an ID.' It clearly establishes the intended context and even says it replaces 2-3 manual lookups. It does not explicitly name sibling alternatives or state when not to use it, but the use case is unambiguous enough to route an agent correctly.

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

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

Annotations already provide strong safety guarantees (readOnlyHint, idempotentHint, destructiveHint false). The description adds meaningful behavioral context: it explains the tool probes each entity with ai_visibility_check, ranks by score, and returns a ranked list with score, confidence, and signal density. This supplements the annotations without contradiction.

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

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

The description is concise (4 sentences) and front-loads the primary purpose. Each sentence adds essential information: what it does, how it works, when to use it, and what it returns. No extraneous words 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?

Given the tool has 4 parameters, 100% schema coverage, and rich annotations, the description provides sufficient context for an agent to understand the tool's behavior and output. It covers the core process and return format. Minor gaps (e.g., no definition of 'signal density', no entity count limits restated) but overall complete for expected usage.

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

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

Schema coverage is 100%, so each parameter already has a description. The tool description adds slight value: it notes the first entity is treated as the 'subject' for narrative and clarifies that omitting models defaults to workers-ai. However, it does not elaborate on parameter constraints or formats beyond what the schema provides, so the added value is modest.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, probes each with ai_visibility_check, ranks by score, and surfaces the most/least recognized. It provides a concrete use case ('does Claude know about us as well as our competitors?') and distinguishes itself from sibling tools like ai_visibility_check (single entity) and compare_entities (generic comparison).

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

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

The description explicitly states the tool is useful for competitive AI-marketing audits and gives an example scenario. While it implies when to use (comparing AI visibility of multiple brands), it does not explicitly state when not to use or mention alternatives beyond the sibling context. Still, the guidance 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?

Description discloses partial failures (bundlephobia timeout of 5-30s, sources_failed list), the fact that it fans out across two services, and the structure of the return (summary block, advisories, links, versions). Annotations already declare readOnly, openWorld, idempotent; description adds significant behavioral context without contradiction.

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

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

The description is a single well-organized paragraph that front-loads the main purpose. It uses inline lists to describe return fields and services concisely, with no unnecessary words. Every sentence adds value.

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

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

Given the tool's complexity (multiple data sources, partial failures, no output schema), the description is thorough. It covers return format, edge cases (timeouts, ecosystem limitation), and alternative approaches, making it complete for an AI agent to understand and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by clarifying that scoped packages (e.g., @types/node) are accepted for 'package' and reiterates default for 'version'. While helpful, the schema already covers basics, so this is a slight improvement.

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

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

The description clearly states the tool's purpose: a composite check for npm packages covering license, advisories, version history, and bundle size. It provides a specific verb ('scan') and resource ('dependency'), and distinguishes from sibling tools by focusing on npm dependencies and bundling multiple checks into one call.

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

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

Explicitly describes when to use (when agent asks about safety/popularity/size of an npm package) and what it returns. Also notes NPM ecosystem only in v1 and directs to deps.dev:version for other ecosystems, providing clear 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?

Discloses embedding model (BGE-base-en), window size (500-char overlapping), cosine similarity, character cap (200K chars), truncation behavior, and passage offset verification. Annotations confirm read-only idempotent behavior; description adds rich context 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?

Single paragraph of five sentences, front-loaded with core purpose, then usage, then technical details. No redundant words; every sentence adds value.

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

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

Covers purpose, when to use, behavioral details (embeddings, window, cap), parameter guidance, and output format (passages, offsets, scores). No output schema, but description adequately explains return values.

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

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

Schema coverage is 100% with parameter descriptions. The description adds examples for 'query', reinforces character limit for 'text', and implies limit default. Adds value beyond schema by connecting parameters to usage context.

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

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

The description clearly states the tool performs semantic search inside a fetched record, using specific examples (SEC 10-K, article, long tool result). It distinguishes itself from siblings by noting when to use it (record too big for prompt) and mentioning a paired tool.

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

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

Provides explicit when-to-use guidance ('when the record is too big to cram into the prompt') and mentions pairing with ask_pipeworx_grounded. Lacks explicit when-not-to-use, but positive guidance is strong.

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

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

Beyond annotations (readOnlyHint=false, idempotentHint=true, etc.), the description adds critical behavioral details: requires OAuth account, delivery channel constraints (email verification, SMS 10/day cap, webhook HMAC signing), and that webhook is auto-disabled after 10 consecutive failures. No contradictions.

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

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

The description is comprehensive but somewhat lengthy (approx. 200 words). It is well-structured with bullet points and examples, and the main purpose is front-loaded. Could be slightly more succinct without losing clarity.

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 params, nested objects, multiple subscription types, delivery options), the description covers all necessary aspects: purpose, requirements, type-specific filters, delivery channels with verification and rate limits, and return value. No output schema but return of subscription id is stated.

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

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

Schema coverage is 100%, but the description adds significant value by providing concrete examples for each type and params (e.g., sec_8k items codes, polymarket_edge topic, fred_series series_id) and clarifying constraints (e.g., clinical_trial requires sponsor or condition). This goes well beyond the schema descriptions.

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

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

The description uses a specific verb 'Create' and identifies the resource as a 'proactive monitoring subscription' to a 'live-data event stream'. It distinguishes from sibling tools like list_subscriptions, recent_alerts, and unsubscribe by focusing on creation and return of 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 clearly states the tool is for creating subscriptions and lists requirements (Pipeworx OAuth account) and supported types. While it doesn't explicitly state when not to use, the context of sibling tools provides cues; e.g., for listing use list_subscriptions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavioral context: returns category-bucketed example questions with exact tool+argument shape, draws from a live catalog, allows no-args or topic focus. No contradictions.

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

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

The description is informative but slightly lengthy. It starts with clear purpose and quickly lists categories. Each sentence adds value, but some redundancy ('What can I ask Pipeworx?' could be condensed). Still efficient.

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

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

For a simple single-param tool with no output schema, the description provides full context: purpose, output structure, parameter usage, and when to call. Annotations cover safety. Nothing missing.

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

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

Schema coverage is 100% with a description of the topic parameter. The description adds semantics: gives example topic values (finance, pharma, betting) and explains omission yields a cross-category spread, which goes beyond the schema.

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

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

The description clearly states the tool is an onboarding entry point that returns example questions about what Pipeworx can do. It lists specific categories and mentions focusing by topic. This distinguishes it from siblings like ask_pipeworx or discover_tools.

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

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

The description explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' It gives clear context for when to use, but does not specify when not to use or name explicit 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?

The description adds critical behavioral context beyond annotations: it explains that the row is deactivated, not deleted, and that historical events remain accessible via 'recent_alerts'. It also reveals the ownership enforcement. This fully aligns with annotations (destructiveHint=false, idempotentHint=true).

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

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

The description consists of two sentences, each adding essential information without redundancy. It is front-loaded with the core operation and efficiently covers ownership and side effects. No unnecessary words.

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

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

For a simple tool with one parameter, the description covers purpose, usage rule, behavioral side effect, and data persistence. Annotations provide additional hints. No output schema is needed, and the description is complete for effective agent use.

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

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

The schema covers 100% of the single parameter 'id' with a clear description. The tool description adds minimal additional meaning ('by id'), which is largely redundant. Given high schema coverage, a baseline score of 3 is appropriate.

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

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

The description explicitly states 'Cancel a subscription by id', which clearly identifies the tool's purpose with a specific verb and resource. It distinguishes this from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

The description provides clear guidance on usage constraints: 'Ownership is enforced — you can only cancel your own subscriptions.' This helps the agent decide when to use this tool, though it does not explicitly mention when not to use or suggest alternative tools.

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

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

Beyond annotations (readOnly, idempotent), the description reveals critical behavior: the SEC EDGAR fast path vs. grounded fallback, the specific verdict list, and the vital distinction between 'could_not_verify' (check did not happen) and 'unsupported' (no source covers it). This is actionable behavioral transparency that prevents misuse.

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

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

The description is dense and front-loaded with purpose and examples, then flows into operational details and caveats. Every sentence earns its place, especially the 'IMPORTANT for callers' note. It is long but justified by the tool's complexity; a 4 reflects that it is appropriately sized, not excessively padded.

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

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

With no output schema, the description must explain return values; it names all verdicts, the evidence with pipeworx:// citation, and reasoning. It also covers the two-path architecture, the tolerance override, and efficiency gains. This is as complete as needed for a tool of this complexity.

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

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

Schema description coverage is 100%: both `claim` and `tolerance_pct` have thorough schema descriptions, including the example, the 0.5–50 range, the override semantics, and the hallucination-detection hint. The tool description adds no meaning beyond the schema, so the baseline 3 applies.

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

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

Description states a specific verb+resource+scope: 'natural-language claim verification against authoritative sources', with examples of user phrasings and a clear focus on fact-checking. It distinguishes itself from sibling research tools by narrowing to 'check whether something a user said is factually correct' rather than general research.

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

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

The description gives an explicit trigger: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also carves out two distinct internal routes (company financials vs. anything else). However, it does not explicitly name alternative sibling tools or state when not to use it, so it stops short of a 5.

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