Fda Devices

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

The description discloses behavioral traits beyond annotations: default model is Workers AI Llama-3.3-70b (free), Anthropic requires a BYO key and incurs direct costs, and it returns per-model results plus a combined view. Annotations already indicate readOnlyHint, idempotentHint, etc., and the description adds operational 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 concise (two sentences plus a brief list for return structure) and front-loaded with the primary action and default behavior. Every sentence serves a purpose: explaining the tool, how to extend it, and what results to expect. 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?

Given the tool's complexity (4 parameters, no output schema), the description provides sufficient information: it describes the return schema (per-model objects with score, confidence, signals, raw_response plus combined view), default model, and optional parameters. No output schema exists, so the description adequately compensates. The agent has enough context to select and invoke the tool correctly.

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

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

The input schema has 100% description coverage for all four parameters. The tool description adds value by explaining the role of each parameter in context: `entity` is the thing to ask about, `models` lists which to probe, `_apiKey` is optional for Anthropic, `context` helps disambiguate. This exceeds the baseline of 3 for high coverage, earning a 4.

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

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

The description uses specific verbs ('probe', 'score') and identifies the resource ('LLMs for what they know about a business / brand / product / topic'). It clearly distinguishes from sibling tools like 'ask_pipeworx' which likely answer questions rather than score visibility. The return structure (score, confidence, signals per model) further clarifies the tool's purpose.

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

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

The description explicitly states use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also provides guidance on optional parameters (e.g., `_apiKey` required for Anthropic, `context` for disambiguation). While it doesn't explicitly state when not to use, the context of sibling tools implies alternative functions. A score of 4 reflects clear, actionable guidance.

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

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

Annotations already mark the tool read-only, open-world, idempotent, and non-destructive. The description adds behavior beyond annotations: it routes to one of 5,798 tools across 1,517 sources, fills arguments, and returns structured answers with stable pipeworx:// URIs. It does not contradict annotations and adds useful context about the tool's meta-routing nature.

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

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

The description is structured well: opening preference rule, mechanism, trigger phrases, examples, and a closing directive. It is front-loaded with 'PREFER OVER WEB SEARCH'. The only issue is a slight redundancy at the end ('START HERE for most questions — for most questions'), and the long list of domains could be tightened, but all content is functional.

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

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

For a single-parameter tool with large scope, the description is thorough: it states what kind of questions to ask, gives examples, explains the routing/citation behavior, and tells the agent to start here. It does not detail the exact output shape beyond citation URIs, but there is no output schema and the description covers the core interaction sufficiently.

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

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

Schema coverage is 100%: the required 'question' parameter has a full description, and all aliases (query, q, prompt, text, input) are documented. The description itself does not discuss parameter syntax, but examples of natural-language questions serve as usage illustrations. The schema carries the parameter semantics, so baseline 3 is appropriate.

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

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

The description clearly identifies ask_pipeworx as a natural-language router that answers factual questions using verified structured data, and explains what it does: routes to one of 5,798 tools, fills arguments, and returns answers with pipeworx:// citation URIs. It distinguishes the tool from web search by explicitly saying to prefer it, but it does not differentiate it from closely named siblings like ask_pipeworx_beta or ask_pipeworx_grounded.

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?

Gives explicit when-to-use guidance: 'PREFER OVER WEB SEARCH', 'Use whenever the user asks...', 'START HERE for most questions', plus a list of example questions. It names web search as the alternative and says to prefer this tool even when web search could answer. The trigger phrases and 'any factual question' scope make the usage criteria very clear.

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

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

The description adds substantial behavioral context beyond the readOnly/openWorld/idempotent annotations: candidate routing improvements are only live while under test, no candidate is active as of a specific date, and the tool is a full working router with no fallback rather than a stub. This is unusually transparent about the tool's experimental status and current parity with the stable version.

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

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

The description is front-loaded with the beta identity and including the same-tools/same-arguments/same-response-shape summary early. It is a bit longer than necessary due to the dated retirement detail, but each sentence contributes operational context and none is misleading or redundant.

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

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

For a beta variant of a known parent tool, the description covers identity, current behavior, parity with the stable router, usage conditions, and the absence of a fallback. Since the tool is explicitly defined in terms of ask_pipeworx, the 'same response shape' statement is sufficient even without an output schema.

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

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

Schema description coverage is 100%, with every parameter documented as an alias or the required question field, so the schema carries the parameter meaning. The description only adds that the arguments are the same as ask_pipeworx, which is consistent but does not elevate meaning beyond the 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 states a specific function: it is a beta version of ask_pipeworx, a universal router with the same 5,798 tools, arguments, and response shape. It clearly distinguishes this tool from the stable ask_pipeworx by positioning it as the experimental routing edge. This goes well beyond restating the title.

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

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

The description explicitly says to use it like ask_pipeworx when you want the newest routing, and explains that current behavior matches the stable router because no candidate is active. It identifies the stable router as the comparison baseline, so the alternative is clear. It stops short of an explicit 'do not use when you need stable production behavior,' but the beta/experimental framing implies it.

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

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

Annotations already mark readOnly/openWorld/idempotent/non-destructive, and the description adds refusal behavior with exact refusal_reason values, evidence as a verbatim quote, and the constraint that answers are extracted 'using ONLY what the tool result contains.' No contradiction exists.

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

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

Every sentence earns its place: definition, routing process, success/refusal returns, use cases, and cost/alternative tradeoff. The key differentiator is front-loaded in the first clause, making the description efficient and scannable.

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

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

Since there is no output schema, the description fully covers both success fields and refusal cases, so an agent knows exactly what to expect. Combined with rich annotations and explicit usage guidance, nothing needed to invoke the tool correctly is missing.

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

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

Schema coverage is 100%, and the question parameter with aliases is already fully documented. The description adds that the input is a natural-language request that gets routed and decomposed, but it does not introduce new parameter meaning beyond what the schema provides.

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

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

The opening phrase 'Hallucination-resistant answer mode for high-stakes reads' names a specific verb, mode, and target use, and 'Same routing as ask_pipeworx' defines what it shares with its closest sibling. It clearly separates this grounded mode from the casual ask_pipeworx sibling without requiring schema inspection.

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

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

Explicitly states use 'whenever an answer will be quoted, cited, or acted on' and gives the cost tradeoff with 'prefer ask_pipeworx for casual lookups.' It provides concrete when/when-not guidance with the sibling 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 indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description goes far beyond, detailing fan-out behavior, response shapes, resolver contracts, parent-event extraction, news fallbacks, and safety checks (low-confidence, closed markets, wide spreads, cancellation rules). 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 well-structured with labeled sections (RESPONSE SHAPES, RESOLVER CONTRACT, etc.). It front-loads the main purpose and progressively adds details. Every sentence provides necessary context; no wasted words.

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

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

No output schema exists, so the description compensates by detailing result fields (market, analysis, evidence), resolver contract (match confidence, alternatives), parent_event, news fields (fallbacks), and edge cases. It covers all likely agent queries for a complex research 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%. The description adds significant meaning: for 'market' it explains slug, URL, or question text with examples; 'depth' explains quick vs thorough with default; 'include_raw' explains purpose and impact on response size. Adds value beyond 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 researches a Polymarket bet by pulling Pipeworx data. It specifies inputs (slug, URL, question text) and actions (resolve, classify, fan out, return evidence + comparison). It distinguishes from siblings like polymarket_arbitrage by focusing on comprehensive 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 explicitly recommends use for 'should I bet on X', 'what does the data say about Y', or 'is there edge in Z'. It provides detailed usage examples and classifier options. However, it could more explicitly state when not to use it or when to prefer sibling tools like polymarket_edges.

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds context about data sources (SEC EDGAR/XBRL, FAERS), handling of off-calendar fiscal years, sorting by primary metric, and return format with 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?

Description is packed with useful information in a single paragraph. It includes examples and clear directives. Slightly long but still concise for the amount of detail. Could benefit from bullet points for readability but not detrimental.

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 2 params and no output schema, the description fully explains inputs, behavior, and output. Covers data sources, sorting, and return format. Adequate 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 coverage is 100%. Description explains 'type' enum values (company/drug) and what each pulls. Clarifies 'values' format (tickers for company, names for drug) and bounds (2–5). Adds meaning beyond 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?

Description clearly states the tool performs side-by-side comparison of 2–5 companies or drugs with specific verbs like 'compare', 'rank', 'head to head'. It distinguishes from sibling tool 'entity_profile' which is a single-entity lookup.

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 'ALWAYS PREFER over sequential single-pack lookups' and provides examples of when to use (comparing entities, ranking). Implies not to use for single entities. It replaces 8–15 sequential lookups, offering clear guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavioral context: auth prerequisites, latency expectations (15-60s, thorough ~90s), output contract (verbatim evidence + confidence + gaps[] + contradictions[]), citation resolvability guarantees, and semantic excerpting of long records. No contradiction with annotations.

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

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

The description is long and somewhat tangled (convoluted parentheticals, run-on sentences around 'hop' and 'citation_uri'), but nearly every sentence earns its place given the tool's complexity across depth tiers, auth, output contract, and alternatives. Critical constraints are front-loaded before the main description.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: findings packet contents, hop field, citation_uri resolvability, gaps[] honesty guarantee, contradictions[] behavior, depth semantics, auth, and latency. Complex tool, and the description covers everything an agent needs to call 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 baseline is 3. The description adds value beyond the schema by tying depth tiers to paid-plan access ('thorough' needs a paid plan), clarifying multi-step resolution behavior, and explaining the gaps[]/contradictions[] artifacts that differentiate the depth options. The question-parameter guidance (broad/multi-part is fine) also supplements 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?

States a specific verb (researches/decomposes/routes), a precise resource (Pipeworx's 1517 structured data sources), and a distinct mechanism (parallel routing to 5,798 tools) with an explicit contrast to open-web search. It also distinguishes itself from ask_pipeworx by scope, so an agent can tell the tools apart without opening their schemas.

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

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

Provides explicit when-to-use guidance ('Best for broad/multi-part questions over structured data'), a clear exclusion ('For a single lookup use ask_pipeworx instead'), and a conditional alternative ('If you are not signed in, use ask_pipeworx instead'). Nothing is left to inference.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds that the tool returns 'top-N most relevant tools with names, descriptions, and full input schemas (with curated examples) — each result is ready to call directly.' This explains output format and readiness, adding value beyond 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?

The description is two sentences: first states purpose with domain examples, second explains output and usage timing. Every sentence adds value, no fluff, and front-loaded with key information. It's well-structured and concise.

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 presence of schema coverage (100%), the description covers what it returns (names, descriptions, schemas, examples) and that results are callable. No output schema exists, but the description explains output adequately. It does not mention pagination or error handling, but it is sufficiently complete for typical use.

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

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

Schema coverage is 100% with explicit descriptions for each parameter. The description mentions aliases (q, task, search, description) and the limit parameter, but does not add new semantics beyond what the schema already provides. Baseline 3 is appropriate since 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 clearly states the tool's purpose: 'Find tools by describing the data or task.' It provides a comprehensive list of domains (SEC filings, FDA, etc.) and distinguishes this tool from siblings by explaining it returns tool schemas ready to call. The verb 'discover' is specific to browsing/searching, which sets it apart clearly.

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

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

The description explicitly says when to use: 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available.' It does not explicitly state when not to use, but the context implies it's for tool discovery only. No alternatives are named, but the tool is meta, so the guidance is clear enough.

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

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

Beyond the read-only/idempotent annotations, the description discloses many behavioral traits: it fans out across multiple sources, returns sources_used/sources_failed, treats empty sections as real no-data rather than bugs, soft-fails for USPTO patents, and handles private companies with a resolved:false plus notes. This is rich, action-relevant context.

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

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

The description is dense and long, but every section adds operational value: trigger phrases, source list, return shape, failure semantics, and input forms. It is front-loaded with the core purpose and examples, and the detailed source/failure explanation is justified 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?

With no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: cik, company_name, recent_filings with URIs, fundamentals fields, per-source sections, sources_used/sources_failed, and resolved:false behavior for private companies. It also covers input normalization and expected empty results.

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

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

The input schema already documents the parameter meanings thoroughly, including accepted forms for value and interchangeability of type, so schema coverage is 100%. The description mostly restates and occasionally expands on that, such as noting private-company resolution behavior, but it does not add substantial new parameter semantics beyond the schema.

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

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

The description states a specific verb and resource: it produces a full cross-source profile of a US public company. It clearly distinguishes itself from single-pack SEC/XBRL/news lookups and from related profile tools by emphasizing the parallel, holistic nature of the 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?

It gives explicit trigger examples ('Tell me about X', 'research Acme', 'brief me on Tesla') and explicitly says to prefer it over chaining single-pack lookups when a holistic view is requested. It also clarifies how to handle private companies — they will return resolved:false rather than succeeding, which is a de facto usage boundary.

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context that 'clearance means FDA found substantial equivalence; it is not an FDA approval or endorsement,' which clarifies the meaning of results beyond the annotations. 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?

Two concise sentences: the first covers the action and criteria, the second clarifies the regulatory meaning. No wasted 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?

The description, combined with a complete schema (100% coverage) and an existing output schema, provides sufficient context for a search tool. It clarifies the meaning of clearance, which is critical for correct interpretation of results.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description merely lists the searchable fields without adding new semantics or usage details beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the verb ('Search') and the resource ('FDA 510(k) premarket notifications'), and lists specific search criteria (device, applicant, product code, K number). It distinguishes from sibling tools like fda_device_pma_search by focusing on 510(k) premarket notifications.

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 implicitly suggests usage for searching 510(k) clearance data, but lacks explicit guidance on when to use this tool versus alternatives such as fda_device_pma_search or fda_device_adverse_events. No 'when not to use' or exclusion conditions are provided.

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, destructiveHint. The description adds critical behavioral context: MAUDE reports are unverified and cannot establish causation, incidence, prevalence, or comparative safety. This goes beyond annotations to set expectations about data reliability.

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

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

The description is two sentences: the first states the purpose and search criteria, the second adds a critical caveat. Every word earns its place; there is no redundancy or unnecessary detail.

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

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

Given 7 optional parameters and an output schema, the description covers the search space and data limitations. It does not mention pagination, ordering, or empty result behavior, but these are less critical with the output schema present. The caution about data quality adds completeness.

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

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

Input schema has 100% coverage with individual parameter descriptions. The description lists the same parameter categories (manufacturer, brand/device, product code, event type, PMA/510(k) number) but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool searches FDA MAUDE medical-device reports and lists specific search criteria (manufacturer, brand/device, product code, event type, PMA/510(k) number). It distinguishes from sibling FDA tools like fda_device_510k_search and fda_device_recalls by targeting adverse event reports.

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

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

The description provides a caution that MAUDE reports are unverified signals and cannot establish causation, which guides appropriate use. However, it lacks explicit when-to-use versus alternatives (e.g., fda_device_event_counts) or conditions for use beyond the data quality warning.

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, destructiveHint. The description adds valuable context: classification is for the category, not specific product clearance/approval, which is 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 with no redundant words. Front-loaded with action and resource, followed by a critical caveat. 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?

Given the presence of an output schema, the description need not cover return values. It sufficiently explains the tool's purpose, scope, and search criteria, providing complete context for a read-only lookup tool.

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

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

With only 25% schema coverage, the description compensates by listing the three main search parameters (product code, device name, regulation number) and their roles. It does not detail the limit parameter, but the schema already describes it.

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

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

The description clearly states the verb 'Look up' and resource 'FDA device classification', with specific search criteria (product code, device name, regulation number). It distinguishes from siblings by clarifying that it describes the product-code category, not a specific product's clearance or approval.

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 specifies when to use (look up classification by given criteria) and implicitly differentiates from sibling tools for specific searches like 510k or PMA. However, it lacks explicit when-not-to-use or alternative recommendations.

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 important behavioral caveats: imperfect name matching and that MAUDE counts are signals, not safety rates, which provides 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?

Two sentences: first states core purpose, second adds key caveats. No wasted words, front-loaded with action.

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 snapshot tool with output schema and clear annotations, the description covers purpose, datasets, and limitations. It could briefly mention how datasets are combined, but output schema likely provides structure.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds value by noting imperfect name matching for the 'company' parameter, implying fuzzy matching, which is not in the schema.

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

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

The description clearly states the verb 'Build' and resource 'FDA regulatory snapshot for one device company' across specific datasets (510(k), PMA, recalls, MAUDE). It distinguishes from sibling tools like fda_device_510k_search by focusing on a multi-dataset overview.

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

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

The description implies usage for an aggregated snapshot of one company, but does not explicitly state when not to use it or mention alternatives like individual dataset 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by disclosing that registration/listing does not imply FDA approval, which is critical for interpreting results. This goes beyond what annotations provide, though it omits details like pagination or result limit 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 consists of two concise sentences: the first states the action and parameters, the second provides a crucial disclaimer. Every sentence earns its place with zero redundancy or fluff.

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

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

Given the 5 parameters with 0% schema coverage, the description is minimally adequate but lacks details like pagination, parameter interaction, or response structure (though output schema exists). The approval disclaimer is valuable, but overall completeness is moderate.

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 0%, so the description must carry the burden. It explicitly lists 4 of 5 parameters (firm, registration_number, product_code, listing_number), which is helpful, but omits 'limit'. No details are provided on how parameters interact (e.g., combinability, partial matching), leaving gaps.

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 specifies the resource 'FDA device registration/listing data', listing specific search parameters (firm, registration number, product code, listing number). This differentiates it from sibling tools that search other FDA data (e.g., 510k, adverse events). The disclaimer adds context without obscuring purpose.

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

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

The description implies usage when searching by the listed parameters, but provides no explicit guidance on when to prefer this tool over siblings like fda_device_510k_search or fda_device_classification. No exclusions or alternatives are mentioned, leaving the agent to infer from the resource name alone.

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

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

Annotations already mark the tool read-only and idempotent. The description adds valuable interpretive context that counts reflect reporting/database artifacts and are not causal risk, which is beyond the structured hints. It doesn't over-explain return behavior, but the caveat is substantive.

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: the first states the action and grouping options, the second provides a crucial interpretive warning. Zero filler, front-loaded, every sentence earns its place.

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

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

For a simple aggregation tool with a rich input schema, output schema, and four annotations, the description is complete: it covers what is aggregated, by which dimensions, and warns about interpretation. No major gaps relative to 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% and the count_field enum includes detailed descriptions. The tool description's grouping dimensions loosely map to parameters but adds little beyond the schema, so the baseline 3 is appropriate.

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

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

The description uses a specific verb ('Aggregate') and names the resource (MAUDE reports) and grouping dimensions (event type, manufacturer, product code, receive date). It is clear but does not explicitly distinguish itself from sibling fda_device_adverse_events, which might also cover MAUDE 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—when aggregated counts by dimension are needed—and includes an important caveat about not comparing counts without denominators. However, it provides no explicit when-to-use/when-not-to-use guidance or mention of alternatives among the FDA sibling 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 indicate read-only, open-world, idempotent, non-destructive behavior. The description adds useful context: supplements may represent manufacturing/labeling changes, not new devices. This helps set expectations about the nature of results beyond 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?

Two efficient sentences: first states purpose and searchable fields, second adds a key nuance about supplements. No wasted words, front-loaded with essential information.

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

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

Given the presence of an output schema and 7 optional parameters, the description covers the core functionality and hints at result nuances. It is sufficiently complete for understanding how to use the tool, though could elaborate on default behavior (e.g., ordering, pagination) which is partially covered by the limit parameter description.

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

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

Schema coverage is 100% (all 7 parameters have descriptions). The description mentions some searchable fields (device, applicant, product_code, pma_number) but does not add semantic detail beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states that the tool searches FDA PMA decisions and supplements by specific criteria (trade/generic name, applicant, product code, PMA number). It is specific about the resource and action, but does not explicitly differentiate from sibling tools like fda_device_510k_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?

No explicit guidance on when to use this tool versus alternatives. The description implies usage for PMA searches but does not provide when-not or alternative tool recommendations.

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, etc. Description adds valuable caveat: 'MAUDE counts are not event rates', and notes dataset counts have different meanings. Complements annotations well.

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 concise sentences: first defines purpose and contents, second adds essential warning. No superfluous text; front-loaded with key information.

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

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

Given output schema exists, description is largely complete for a read-only snapshot tool. Covers core function and a key caveat, though could mention how results are combined.

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 0% description coverage. Description mentions 'one FDA product code' for product_code and 'bounded' for limit_per_dataset. Partially compensates but does not fully explain limit_per_dataset's role or format.

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 verb 'Build' and resource 'bounded cross-dataset snapshot for one FDA product code', listing included datasets. Distinguishes from sibling tools focused on single datasets.

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

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

Implicitly indicates use for cross-dataset overview but lacks explicit when/when-not or alternatives. Context shows many siblings, but description does not guide selection.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds meaningful context beyond annotations: recall records are correction/removal actions and do not alone prove patient harm. This is valuable interpretive context, though it doesn't disclose pagination or rate limits, which are largely covered by schema and output 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?

The description is two short sentences, clearly front-loaded with the core action and search fields, followed by a vital caveat. Every word adds value; there is no redundancy or fluff.

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

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

Given the tool has 7 parameters all fully documented in the schema, an output schema, and robust annotations, the description only needs to convey the high-level purpose and any interpretive caveats – both of which it does. It provides enough context for an agent to select it appropriately among many FDA device siblings.

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 each parameter described (e.g., 'Recalling firm substring', 'Product or reason text'), so the baseline is 3. The description lists the fields but does not add significant new meaning beyond what the schema already provides; it merely groups them into a readable summary, so no lift 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 starts with 'Search FDA medical-device recall records' – a specific verb and resource – and enumerates the searchable dimensions (firm, product, product code, K number, status, date). It clearly differentiates from sibling tools like fda_device_adverse_events and fda_device_510k_search by centering on recall records, and the additional sentence about correction/removal actions clarifies the domain.

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

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

The description gives clear context that this tool searches recall records, and the caveat 'does not by itself establish patient harm' implicitly tells users not to use this for harm claims. However, it does not explicitly name alternative tools or provide when-not-to-use exclusions, so it falls short of full explicit guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the tool is clearly a safe, read-only search. The description adds important behavioral context beyond annotations by warning that results do not imply current sales, clearance, or safety.

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

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

The description is two sentences long, front-loading the core purpose and adding a crucial disclaimer. Every sentence earns its place with 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?

An output schema is present, so return values need not be explained. The description covers the search intent and important disclaimers. It could mention that all parameters are optional, but given the presence of the schema and annotations, the description is reasonably complete.

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

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

With schema description coverage at only 20% (only 'query' has a description), the description should compensate. It mentions searchable fields ('brand, company, device identifier, or product code'), which aligns with the parameters 'query', 'company', 'primary_di', and 'product_code', but provides no details on the 'limit' parameter or input format. This adds moderate value beyond the schema.

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

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

The description clearly states 'Search FDA GUDID/UDI records by brand, company, device identifier, or product code,' specifying the verb 'search' and the resource 'FDA GUDID/UDI records.' It also distinguishes the tool from sibling FDA tools (e.g., 510k, adverse events) by clarifying that the returned UDI records do not establish sales, clearance, or safety.

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 context by stating what a UDI record represents and what it does not establish, helping agents avoid misinterpretation. However, it does not explicitly contrast this tool with siblings like fda_device_510k_search or give direct when-not instructions.

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 provide destructiveHint and idempotentHint. Description adds 'Delete' which aligns with destructiveHint but does not clarify behavior on missing key or idempotency. No contradiction as description omits detail but 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?

Two sentences, no waste. Purpose and usage are front-loaded. Every sentence earns its place.

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

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

For a simple delete operation with one parameter, no output schema, and comprehensive annotations, the description provides sufficient context including usage guidance and tool pairing.

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 'key' described as 'Memory key to delete'. Description adds no extra semantic value beyond the schema, so 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 clearly states 'Delete a previously stored memory by key' with specific verb and resource. It implicitly distinguishes from sibling tools 'remember' and 'recall' by naming them as counterparts.

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

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

Explicitly states when to use the tool ('context is stale, task is done, clear sensitive data') and mentions pairing with 'remember' and 'recall', providing clear guidance on context and alternatives.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable process details (fetches page, extracts title/links, emits standard format) and output nature. No contradictions.

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

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

The description is concise with about four sentences, front-loading the main action and listing use cases efficiently. No unnecessary information.

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

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

For a low-complexity tool (2 params, no output schema), the description fully covers purpose, usage, behavior, and output format, making it complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description doesn't add new meaning beyond schema descriptions for url and max_links parameters.

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 production-ready llms.txt file for any URL, using a specific verb and resource. It distinguishes itself from unrelated sibling tools.

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

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

The description provides explicit use cases (client indexing, own project, competitor audit) that clarify when to use the tool. It doesn't explicitly state when not to, but the tool's specificity makes that 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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds detail about the return fields but does not contradict annotations. No additional behavioral traits beyond what annotations convey.

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

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

Two sentences covering action, return fields, and usage guidance. Front-loaded with the core purpose, every sentence earns its place. No unnecessary text.

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

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

Given the tool's simplicity, no output schema, and rich annotations, the description is complete. It specifies returned fields, usage context, and works well with sibling tools for subscribe/unsubscribe.

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

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

The schema already describes the single parameter 'include_inactive' with 100% coverage. The description does not add extra meaning or usage details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action (list subscriptions) and the resource (caller's active subscriptions). It specifies the returned fields. While it doesn't explicitly differentiate from siblings, the mention of reviewing before adding or canceling implies it's for inspection, not mutation.

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: to review monitored items before adding more or to find an ID to cancel. This provides clear context for its usage, though it doesn't explicitly state when not to use it.

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

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

The description goes far beyond the annotations by disclosing rate limiting ('5 per identifier per day'), cost (free, doesn't count against quota), the claim_token behavior (returned without account, can be reused to check resolution), and team review cadence ('reads digests daily'). It also instructs on content hygiene ('don't paste the end-user's prompt'). No contradictions with annotations.

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

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

The description is longer than a single sentence, but every clause earns its place: usage criteria, exclusion scope, token mechanics, rate limits, and free-tier status. It is front-loaded with the core purpose and then expands into necessary operational details. While not as terse as the TDQS 4.3 example, the complexity of the tool justifies the length.

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

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

Given the lack of an output schema, the description adequately covers return behavior (claim_token, status updates), operational constraints (rate limit, quota), and domain scope (Pipeworx tools only). It also supplies clear context for the nested context parameter and message content. For a feedback tool with 4 parameters and no output schema, this is fully 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%, so a baseline of 3 applies. The description adds semantic value by explaining the claim_token lifecycle (returned when filing without an account, passing it later reads status) and by advising users on how to frame the message ('Describe the issue in terms of Pipeworx tools/packs'). This exceeds baseline, hence 4.

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

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

The description opens with a specific verb+resource ('Tell the Pipeworx team something is broken, missing, or needs to exist'), immediately distinguishing this as a feedback submission tool. It explicitly contrasts with siblings like ask_pipeworx and discover_tools by focusing on reporting bugs, feature requests, data gaps, and praise, rather than querying or discovering tools.

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

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

The description provides precise when-to-use guidance: bug reports for wrong/stale data, feature/data_gap for missing tools, and praise for positive experiences. It also gives a clear exclusion — only for tools served by this Pipeworx connection, not other MCP servers — and offers a disambiguation rule ('Pipeworx tool names are the ones this connection lists'). This is exemplary usage guidance.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable context: caching (5min-1h), data source (CF analytics-engine), and privacy (no PII). 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 paragraph with clear organization: definition, use cases, additional context. Each sentence adds value, though it could be slightly more compact 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?

No output schema is provided, and the description only vaguely mentions 'top tools, top packs, and total call volume' without specifying the exact return format (e.g., whether it returns arrays with counts). This leaves some ambiguity for the agent.

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

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

Schema covers 100% of parameters with enum and description. The description adds default value (24h) and explains the trade-off between shorter and longer windows, providing meaning beyond schema definitions.

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

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

The description clearly states it returns 'top tools, top packs, and total call volume' over configurable time windows. It distinguishes itself from sibling tools like 'discover_tools' by focusing on aggregated usage trends rather than exploration.

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

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

The description explicitly lists three concrete use cases (discovering hot data sources, confirming canonical tools, aligning with agent needs). It implicitly guides when to use but does not explicitly compare with alternatives like 'discover_tools' or state when not to use.

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

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

Annotations indicate read-only, open-world, idempotent. Description adds rich behavioral context: monotonicity violations, partition-sum checks, Jaccard similarity threshold, placeholder filtering, fill check against live CLOB depth. 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 thorough and well-structured, front-loading the core purpose and then detailing each mode. While slightly long, every sentence adds value and no trivial content is present.

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 all aspects: no-args trending scan, event mode, topic mode, semantic anchor, partition filter, fill check, response structure, and reference to sibling tool for custom sizing. No gaps given the complexity and absence of output schema.

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

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

Both parameters are fully described in the schema (100% coverage). The description adds context: explanations of event slugs, topic seeds, and how each mode works, providing examples and use cases 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 finds arbitrage opportunities via monotonicity violations and partition-sum checks. It distinguishes three modes (no args, event, topic) and differentiates from sibling tools like polymarket_edges and polymarket_edge_tracker by focusing on arbitrage detection.

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

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

Explicitly explains when to use each mode: 'Call with NO args for a trending_scan', 'pass event for the strongest per-event partition_check', 'pass topic for a themed cross-event scan'. Recommends event mode for specific markets and warns when not to trade based on fill check. Also references polymarket_fill_risk for custom sizing.

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

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

The description adds significant detail beyond annotations: model families, edge calculation, Kelly sizing, caching, and diagnostic info. Annotations already indicate read-only and idempotent, and the description is consistent.

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

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

The description is extremely long and dense with technical jargon, making it hard to parse quickly. While structured with sections, it lacks conciseness and is not front-loaded for an agent's efficient reading.

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 response structure (by_segment, fed_candidates, diagnostics) and what each opportunity contains. It covers filters and edge cases, making it complete for an agent to understand the tool's behavior.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds context (e.g., 'Tradeable-edge filters') and explains min_partition_leg_kelly nuance, but the schema already provides clear semantics for each parameter.

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 Polymarket markets for opportunities where Pipeworx data disagrees with market price, and positions it for daily discovery ('what should I bet on today'). This distinguishes it from siblings like polymarket_arbitrage or polymarket_edge_tracker.

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

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

The description implies usage for discovering edge opportunities and includes context like caching and segment diagnostics, but does not explicitly compare to sibling tools or state when not to use it.

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

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

The description goes far beyond annotations, explaining response structure (tracked, expired, snapshot_dates), limitations (60-day TTL, cache-miss gaps), and computational details (decay from daily closes, signed edge_pp_net). No annotation contradictions.

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

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

The description is relatively long but well-structured: purpose statement, args, response fields, and limits. Each sentence adds value. However, it could be slightly more concise by reducing redundancy in the response field explanations.

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

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

Despite no output schema, the description thoroughly explains all return fields and their semantics. It also covers limitations and operational details (cache-miss gaps, TTL). This gives the agent a complete understanding of what to expect.

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

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

Schema coverage is 100%, so both parameters are documented. The description adds context: default values (14 days, '1wk'), max for days (30), and explanation of 'window' as snapshot family. This adds 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 provides 'edge persistence and decay telemetry' and answers a specific question about edge duration and decay. The verb is implied (track/analyze), and the resource (polymarket edges over time) is clear. However, it does not explicitly differentiate from sibling tools like polymarket_edges, which likely focus on current edges without time-series.

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

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

The description provides a direct usage context: 'Answers how long has this edge existed and is it shrinking?' This tells the agent when to use this tool. It does not explicitly exclude other tools or state when not to use it, but the context is sufficient. No explicit alternatives are mentioned.

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 show readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds rich behavioral detail: walks the ladder, returns specific fields (top_of_book, vwap_fill_price, slippage_pp, shares_filled, verdict), and for baskets explains theoretical_sum vs realizable_sum, thin_legs, forced_directional_risk. 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?

Description is front-loaded with purpose and constraints, then uses clear section headers (REQUIRES, SINGLE-MARKET, BASKET, USE THIS) for scannability. Every sentence adds specific value; no redundancy. Length is justified by the tool's complexity.

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

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

No output schema, so description must explain return values. It does so thoroughly for both modes: lists all fields (top_of_book, vwap_fill_price, slippage_pp, shares_filled, verdict; theoretical_sum, realizable_sum, capture_ratio, profit_usd, thin_legs, forced_directional_risk). Also covers edge cases like partial fills and directional risk. Complete given 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%. Description adds meaning beyond schema: explains side defaults and auto-detection for baskets, size_usd interpretation (max spend vs target proceeds for single-market, settlement notional for basket), and clamp range. This compensates fully despite no output schema.

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

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

Description starts with a specific verb phrase 'Realizable-vs-theoretical edge check against live CLOB order-book depth', then clearly distinguishes two modes (single-market and basket). It explicitly links to sibling tools polymarket_arbitrage and polymarket_edges, stating when to use this tool instead, so purpose is unambiguous and differentiated.

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

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

Explicitly states when to use: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500'. It also explains the risk of not using it: theoretical overround not capturable and partial basket fills create unhedged directional positions. This provides clear context and exclusions.

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

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

The description goes far beyond the readOnlyHint/idempotentHint annotations, disclosing rich behavioral detail: compatibility warning/codes semantics, per-entry flags, gross-vs-net fee caveat, skipped comparison counters, and temporal alignment nuances. This transparently tells the agent what the tool will and will not do.

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 its core purpose, but it repeats the macro shortcut list that already exists in the schema's topic parameter description, and the long wall of parenthetical code explanations could be better structured with bullets. Every sentence contributes, but there is redundancy and readability cost.

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

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

Given there is no output schema, the description thoroughly covers return semantics: leg-by-leg prices, top_spreads_pp entries, safety fields, temporal_alignment behavior, fees_note, and skipped counters. An agent has enough detail to correctly interpret the response and act on caveats.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds value by clarifying the relationship between modes: topic auto-fetches on both venues, explicit ticker/slug overrides apply per side, and both modes run the identical token-overlap matcher. This is meaningful 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 first sentence defines the tool precisely: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' This is a specific verb+resource that immediately distinguishes it from siblings like polymarket_arbitrage or polymarket_edges, which target other comparisons or edges.

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

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

The description explains the two modes and warns that pre-mapped topics often return compatibility warnings, but it never names an alternative tool or states when NOT to use this tool. Usage context is clear, but exclusion guidance and sibling differentiation are absent.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context about scoping (anonymous IP, BYO key hash, or account ID) and pairing with remember/forget. No contradictions with annotations.

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

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

Two sentences that efficiently convey the tool's dual behavior and usage context. No wasted words; front-loaded with the primary action.

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

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

The description covers both operational modes (with and without key), scoping, and pairing with sibling tools. While there is no output schema, the description implies the return value (saved value or list of keys). It is complete for a simple retrieval tool with strong annotation support.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaning by explaining the optional key behavior ('omit to list all keys') and giving concrete examples of what keys store (ticker, address, notes), which is beyond the schema's basic description.

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

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

The description clearly states the tool retrieves a value saved via 'remember' or lists all keys when no key is provided. It distinguishes itself from sibling tools 'remember' and 'forget' by explicitly mentioning them, aligning with the specific verb-resource pattern.

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

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

The description explains when to use the tool (look up context stored earlier) and when to omit the key (list all keys). It implies appropriate usage contexts but does not explicitly state when not to use it, though sibling tools cover other operations.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. The description adds valuable behavioral details: returns specific fields (source, citation_uri, raw payload), explains mark_read side effect, and notes polling suitability. 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 and front-loaded with clear purpose, then brief details. Each sentence adds value: purpose, return fields, filters, mark_read, polling note, alternative endpoint. Slightly longer than minimal but 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?

Despite no output schema, the description adequately explains return fields (source, citation_uri, raw payload) and behavior (filtering, mark_read, polling). With rich annotations, this is fully sufficient for correct 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% with descriptions for all 5 parameters. The description adds context for type (example 'sec_8k'), since (ISO timestamp), and mark_read behavior, but does not significantly enhance meaning beyond schema. Baseline 3 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 'Pull fired events from your subscription feed' with specific verb and resource, and distinguishes itself from siblings like list_subscriptions and recent_changes by focusing on fired alerts from the subscription feed.

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

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

Provides explicit guidance on when to use: describes filtering by type and since, explains mark_read behavior for polling, and offers an alternative REST endpoint for scripts/dashboards. No exclusion of alternatives but clear context.

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

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

The description discloses behavioral traits beyond what annotations provide, including the fan-out to multiple data sources (SEC, GDELT→GNews fallback, USPTO), the soft-failure mechanism for USPTO, and the return structure (changes by source, count, citation URIs). No contradiction with annotations.

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

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

The description is well-structured, front-loaded with example queries, and every sentence adds value. It covers purpose, usage, internal behavior, parameter details, and alternatives 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 the tool's complexity (multiple data sources, no output schema), the description is fully complete. It explains what the tool does, how it works, parameter format, limitations (USPTO sunset), and alternatives. 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?

Although schema description coverage is 100%, the description adds significant value by providing concrete examples for `since` (e.g., '7d', '30d', '3m', '1y') and suggesting typical monitoring values. It also clarifies 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 explicitly states that the tool provides a change feed for a company over a time window, with clear example queries. It distinguishes itself from the sibling tool `entity_profile` by noting that `entity_profile` should be used for static profiles, regardless of time window.

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

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

The description provides explicit when-to-use guidance with example queries and also specifies when not to use it (i.e., use `entity_profile` for static profiles). It includes parameter usage recommendations, such as default `since` values.

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

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

Discloses key-value pair storage scoped by identifier and memory duration (24h for anonymous). Annotations confirm write, idempotent, non-destructive. Could add whether overwriting is allowed, but overall adequate.

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

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

Four focused sentences with no extraneous content. Information is front-loaded and efficiently 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?

Covers persistence, use cases, and pairing with siblings. No output schema, but description explains what is stored. Could mention size limits but not essential.

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

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

Schema covers both parameters with descriptions (100% coverage). Description adds example key names but no extra semantic detail beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Save data the agent will need to reuse later'. It specifies the verb 'save' and the resource 'data', and distinguishes it from sibling tools like recall and forget.

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

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

Explicit guidance on when to use: 'when you discover something worth carrying forward'. It also instructs to pair with recall and forget, and explains persistence differences between authenticated and anonymous sessions.

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 important runtime behavior: ambiguous matches return figi_candidates for disambiguation, unresolved identifiers are surfaced under unresolved rather than omitted, identifiers are labelled with their source, and GLEIF/OpenFIGI degradation still returns EDGAR identifiers. This is substantial transparency beyond 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 dense and front-loaded with examples and the core instruction. Some parenthetical chains are long and slightly awkward, and a few sentences are promotional or redundant, but nearly every clause carries useful operational detail, so the length is mostly earned.

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

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

With no output schema, the description carries the burden of explaining outputs, and it does: it lists returned identifiers, sources, candidate lists, unresolved fields, and graceful degradation. It also covers both supported entity types, input formats, and non-US/ISIN edge cases, making it complete for an agent to select and invoke correctly.

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

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

Although schema coverage is 100%, the description adds significant semantic value: accepted forms for value include ticker, CIK, ISIN, or company name; drug inputs accept brand or generic names; and it warns to pass the issuer name exactly as printed for bonds, never the full noun phrase. This materially reduces invocation errors.

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

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

The description states a specific verb and resource: it resolves user-spoken names to canonical/official identifiers required by other tools. It also maps concrete query patterns ('ticker for', 'CIK for', 'LEI for') to the tool's behavior, making the purpose unmistakable and differentiating it from downstream lookup 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 FIRST whenever you have a name but need an ID,' giving clear contextual guidance and implying it precedes tools like entity_profile or compare_entities. It does not name those alternatives explicitly or state when not to use the tool, but the usage context is still clear.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds operational details: it probes with ai_visibility_check, ranks, and returns a ranked list with score/confidence/signal density. No contradictions; it enhances understanding beyond annotations.

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

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

Two sentences, each earning its place. The first sentence states the core action, the second provides context and output format. No fluff, 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 tool's complexity (4 params, no output schema), the description adequately covers purpose, internal mechanism, and output structure. It could mention entity count range (2-8) but that is in the schema. Still complete enough for typical use.

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

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

Schema coverage is 100%, so the schema already describes all parameters. The description does not add significant new meaning beyond what is in the schema descriptions, but it hints at the internal use of models. 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 it compares AI visibility across multiple entities, using 'probes each entity with ai_visibility_check' and 'ranks by score'. It distinguishes itself from single-entity tools like ai_visibility_check by emphasizing multi-entity 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 says it is useful for competitive AI-marketing audits and gives a concrete example. While it doesn't list explicit alternatives, the context of comparing multiple entities implies when to use this over single-entity tools like ai_visibility_check.

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

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

Annotations already provide safety hints (readOnly, idempotent, non-destructive). Description adds critical behavioral context: fans out across two services, partial failures degrade gracefully, bundlephobia first measurement can take 5-30s, and sources_failed list is included. 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?

Single dense paragraph packs a lot of information efficiently. Could benefit from slight structuring (e.g., bullet points for return fields), but every sentence earns its place with no 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?

No output schema, so description fully covers return values: summary block fields, per-advisory detail, links, alternative versions. Also explains timeout behavior and partial failure handling. Extremely comprehensive for a composite tool.

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

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

Schema coverage is 100% with descriptions for both parameters. Description adds value by clarifying scoped packages are accepted for 'package' and providing an example version format ('18.3.1') for 'version'. Reinforces defaults behavior.

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

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

Description uses specific verb-resource combo ('scan dependency') and immediately explains it's a composite check for npm packages combining deps.dev and bundlephobia data. Clearly distinct from siblings like 'deep_research' or 'validate_claim'.

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

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

Explicitly states use cases: 'is X safe / popular / small' or 'what does adding lodash cost me'. Also specifies scope (NPM ecosystem only) and that other ecosystems should use deps.dev:version directly. Lacks explicit when-not-to-use, but context is clear given 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?

Annotations already indicate idempotent, read-only, open-world, non-destructive. Description adds critical behaviors: BGE-base-en embeddings, 500-char overlapping windows, 200K char cap with truncation flagging, and character offsets for verification. 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?

Single paragraph with good front-loading of purpose and use cases. Slightly verbose but no irrelevant information. Could be split for readability but remains clear and efficient.

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

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

Coverage is exemplary: purpose, usage, technical details (model, windowing, truncation), and workflow pairing. No output schema exists, so description fully compensates by explaining return values (passages, offsets, scores). Meets all completeness criteria for this complexity level.

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%. Description adds value beyond schema: explains text max size with truncation behavior, provides query examples, and shows limit default and range. Enriches all parameters with practical 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?

Clearly states it performs semantic search inside a fetched record, with specific examples (SEC 10-K, article). Distinguishes from sibling ask_pipeworx_grounded by explaining the workflow: fetch with gateway, then ground over passages.

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

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

Explicitly says 'Use when the record is too big to cram into the prompt', and pairs with ask_pipeworx_grounded. Provides clear when-to-use and alternative tool reference.

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 idempotency and non-destructive creation. Description adds details: account requirement, type-specific parameters, delivery constraints (SMS cap, webhook signing secret), and that subscriptions persist. 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?

Well-structured with key info upfront in first sentence, followed by organized details for types and delivery. While lengthy, it efficiently packs necessary complexity 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?

Covers all relevant aspects: purpose, required authentication, type selection with examples, delivery options with limitations, return value, and side effects. No output schema needed as description sufficiently explains behavior.

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

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

Schema coverage is 100%, but description enriches each parameter with concrete examples, type-specific filters, and delivery channel constraints that go well beyond the schema's brief 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 the verb (Create), resource (subscription to event stream), and outcome (returns id). Distinguishes from sibling tools like list_subscriptions and unsubscribe by focusing on creation and monitoring.

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

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

Specifies when to use (proactive monitoring), required account type, supported types, and delivery channels with constraints. Implicitly contrasts with pulling alerts via recent_alerts or API endpoint, but could explicitly compare to 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant context: returns category-bucketed example questions with exact tool and argument shape. 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 appropriately sized for an onboarding tool, front-loading the purpose and examples. Every sentence adds value, though it could be slightly more concise. Structure is clear with examples and parameter 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?

Despite no output schema, the description fully explains the return value: category-bucketed example questions with tool and argument shapes. It covers both no-argument and topic-focused calls. For an onboarding tool with many siblings, this is complete.

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

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

Schema coverage is 100% with one optional 'topic' parameter and description. The description adds meaning beyond the schema by listing specific topic values (finance, pharma, etc.) and stating that omitting it gives a cross-category spread, which helps the agent understand the parameter's effect.

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 for new users, listing example questions and what it returns. It distinguishes itself from siblings like ask_pipeworx and discover_tools by being the first thing to call when you don't know what Pipeworx can do.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and explains how to learn about meta-tools. Provides directive on when to pass 'topic'. However, it does not explicitly state when not to use it or offer alternatives beyond the listed siblings.

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 (destructiveHint=false, idempotentHint=true), the description discloses that the row is deactivated not deleted and that historical events remain via recent_alerts. 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?

Two sentences, first sentence states action, second sentence provides important behavioral detail. No wasted words.

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

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

Given no output schema, the description covers what happens (deactivation), ownership, and linkage to historical data. Sufficient for agent to understand outcome.

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 description for 'id' already provided in schema. The description adds no extra meaning beyond schema, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Cancel' and resource 'a subscription by id'. It distinguishes from siblings like 'subscribe' and 'list_subscriptions' by specifying cancellation via 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?

It explicitly states ownership enforcement, guiding the agent to only cancel own subscriptions. It does not name alternatives but the context is clear enough. A slight gap is not mentioning when not to use, but the enforcement handles misuse.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower, but the description goes well beyond: it explains the six verdict values, the critical distinction between 'could_not_verify' (check did not happen) and 'unsupported' (no source found), and that could_not_verify carries an error object. This is exactly the kind of nuanced behavioral disclosure that helps an agent interpret results correctly.

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

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

The description is long but information-dense, with a logical structure: example phrases, when-to-use, routing logic, return values, important caveats, and efficiency note. Every sentence contributes. It could be tightened (e.g., the 'Replaces 4–6 sequential calls' is nice but not essential), but it's still well-organized and front-loaded with the most relevant trigger examples.

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 full responsibility for explaining return values, and it delivers: it states exactly what verdicts are possible, that actual value comes with a citation, and the error semantics. It also covers edge cases (could_not_verify vs unsupported) and the internal fast-path/grounded routing. For a 2-param tool, this is exceptionally 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 both parameters (claim and tolerance_pct) with useful descriptions. The description adds value by explaining tolerance_pct semantics: it overrides the implied tolerance, is capped at 5 by default, and can be set to 1–2 for hallucination detection. This goes beyond the schema and aids invocation decisions.

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 natural-language trigger phrases and explicitly states 'natural-language claim verification against authoritative sources'. It names the action (verify/fact-check) and resource (claims) with specific detail, and clearly distinguishes itself from research/search tools by focusing on factual correctness checks.

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

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

The description explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' This is strong when-to-use guidance. It also differentiates between company-financial claims (SEC EDGAR/XBRL fast path) and all other claims (grounded pipeline). However, it stops short of naming alternative tools for when not to use it, so it misses the top score.

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