Kitsu

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds valuable context: it mentions the default free model, that Anthropic probing requires a BYO key with direct payment, and the exact return shape (per-model {score, confidence, signals, raw_response} + combined view). This goes beyond annotations.

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

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

Two sentences, front-loaded with the core action and output, then use cases. Every phrase earns its place—no fluff or repetition. Highly efficient.

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

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

No output schema exists, but the description explicitly describes the return format. It covers cost implications, default behavior, and typical use cases. This is sufficient for an agent to correctly select and invoke the tool.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds semantic nuance by explaining the default model selection (_apiKey only needed for Anthropic) and that context helps disambiguate common names. This enriches the schema descriptions.

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

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

The description opens with a specific verb+resource: 'Probe one or more LLMs for what they know about a business / brand / product / topic and score visibility (0-100) per model.' This clearly states the core function and distinguishes it from sibling tools like ask_pipeworx or scan_competitor_ai_presence by focusing on cross-LLM knowledge probing and scoring.

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

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

Provides explicit use cases: 'Useful for AI-marketing audits, pre-launch brand checks, competitive monitoring.' It also clarifies when to use the optional Anthropic model (when _apiKey is provided). It does not explicitly contrast with alternatives, but the application scenarios are clear enough to guide selection.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the return field details and the Kitsu source, but it doesn't disclose error handling, rate limits, or any fetch-specific pitfalls. This is minimal extra behavioral information.

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

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

One sentence that is front-loaded with the action and resource, followed by a concise list of return fields. No redundancy.

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

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

For a simple read-only fetch tool, the description covers what is fetched, by what identifier, and what is returned. Combined with the output schema and annotations, it forms a complete picture.

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 0% schema coverage, the description provides critical semantics: the id is a Kitsu numeric ID. This fully compensates for the schema's lack of parameter 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 uses a specific verb ('Fetch') and resource ('Kitsu anime entry'), and lists the returned fields. It clearly differentiates from sibling tools like search_anime and top_anime by specifying a numeric ID 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?

The description implies usage when a numeric Kitsu anime ID is known, which suggests it is for direct lookups rather than search. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose it over search_anime.

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. The description adds valuable behavioral context: it routes to multiple tools, fills arguments automatically, returns citation URIs, works on every tier, and is a single fast call. It does not mention failure modes or rate limits, but the annotation coverage raises the baseline.

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

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

The description is lengthy but well-structured and front-loaded with the most important message ('PREFER OVER WEB SEARCH'). Every section earns its place: use cases, examples, differentiation, and breaking-news note. Slightly verbose, but not wasteful.

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

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

For a tool without an output schema, the description explains the return format (structured answer with citation URIs) and provides rich context on scope, triggers, and alternatives. It lacks details about the exact answer structure or potential limits, but given the broad scope, it covers the selection and invocation needs well.

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 parameters are aliases for the same 'question' field, fully described in the schema. The description adds example question forms and usage context, but does not fundamentally extend parameter meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description explicitly states this tool answers factual questions about real-world data by routing to 5,529 tools, returning structured answers with citations. It uses strong verbs like 'routes' and 'returns', and clearly distinguishes from siblings like ask_pipeworx_grounded and deep_research.

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

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

The description gives explicit when-to-use guidance ('PREFER OVER WEB SEARCH', 'START HERE for most questions') and when-not-to-use guidance ('Step up only when needed' for grounded and deep_research). It also provides concrete examples and a list of trigger phrases.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: it is beta, may change live when candidates are under test, currently matches ask_pipeworx exactly, and is fully functional. 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 somewhat long but information-dense, with each sentence contributing essential context (beta status, current equivalence, usage guidance, experimental purpose). It is front-loaded with the key point and does not ramble, though it could be slightly streamlined.

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

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

Given the tool's complexity as a beta router, the description provides substantial context: identical functionality to ask_pipeworx, comparison against stable router, no active candidate, and full working status. While it lacks explicit response shape details, it references the same response shape as ask_pipeworx, which is sufficient for agents familiar with the stable 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%, including aliases for the single 'question' parameter. The description adds no parameter-specific semantics beyond saying 'same arguments' as ask_pipeworx, which doesn't enhance understanding since the schema already documents the field and aliases.

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

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

The description clearly states this is a beta version of ask_pipeworx, describing it as an 'identical universal router' with the same 5,529 tools, arguments, and response shape. It distinguishes from the stable ask_pipeworx by noting it is the experimental edge with candidate routing improvements.

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

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

Explicitly instructs when to use it: 'Use it exactly like ask_pipeworx when you want the newest routing' and clarifies that results are compared against the stable router to decide merges. It also corrects a potential misconception by saying 'Falls back to nothing — this IS a full working router,' providing clear usage context.

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

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

Beyond the annotations (readOnly, idempotent, openWorld), the description details the exact return format (answer, evidence, confidence, source, fetched_at, refusal_reason) and enumerates possible refusal reasons. It also discloses the extra LLM call cost. This adds significant behavioral context that annotations do not provide, with no contradiction.

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

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

The description is dense but well-structured: it starts with purpose, explains behavior, then usage guidance and cost trade-off. Every sentence adds value, though the length is substantial and could potentially be tightened without losing critical information.

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

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

There is no output schema, but the description compensates by specifying the exact return value structure and refusal modes. It also covers when to use the tool, its relationship to siblings, and its cost implication. This makes the tool's behavior fully predictable for an agent, especially in a high-stakes context.

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

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

The input schema already covers 100% of parameters, describing the 'question' field and all aliases clearly. The description adds no additional parameter-level semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description opens with a clear, specific statement: 'Hallucination-resistant answer mode for high-stakes reads.' It explains the tool's internal routing and extraction behavior, and explicitly distinguishes itself from sibling ask_pipeworx by adding a grounded extraction step and refusal modes. This fully clarifies what the tool does and how it differs from alternatives.

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

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

The description provides explicit guidance: use when an answer will be 'quoted, cited, or acted on' and in high-stakes domains (financial, legal, medical, public statements). It also tells the agent to 'prefer ask_pipeworx for casual lookups' due to the extra LLM call cost. This clearly defines when to use this tool versus the alternative.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description goes far beyond: it discloses the resolver contract with match confidence levels, the low-confidence short-circuit behavior that suppresses analysis, the closed/dead market status, wide-spread illiquidity flag, and cancellation-rule parsing. It also explains the blocking nature of error paths and the news fallback flags, providing exceptional transparency.

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

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

The description is long but front-loaded with the purpose and packed with dense, non-redundant details for a complex tool with no output schema. The fan-out examples are extensive but illustrative. It could be trimmed slightly, but every sentence provides value, so it earns a 4.

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

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

With no output schema, the description fully explains return shapes (result.market, result.analysis, result.evidence), resolver contract, parent_event extraction, news fallback fields, safety statuses, and resolution-rule risk. It covers edge cases like illiquid spreads and closed markets, making it complete for an agent to invoke and interpret results correctly.

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

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

The input schema fully describes all three parameters with 100% coverage, including format examples for market, the depth enum, and include_raw's behavior. The description does not add significant extra meaning beyond the schema; it reiterates some input formats but mostly leaves parameter explanation to the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It further details the process (resolves the market, classifies the bet, fans out to category-specific data packs) and distinguishes it from sibling tools like polymarket_edges and polymarket_arbitrage by focusing on research and evidence gathering.

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 for "should I bet on X", "what does the data say about Y", or "is there edge in Z"' providing clear when-to-use context. It does not explicitly name exclusions or alternative tools, but the use cases are well-defined and the 'ALWAYS inspect' guidance adds practical usage direction. A 'when not to use' note would make it a 5.

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

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

The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful output details but does not address behavioral aspects like pagination, limit semantics, or rate limits. It does not contradict annotations.

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

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

The description is front-loaded with the core purpose, but the third sentence ('Answers which genres and themes...') restates the same idea as the first sentence without new information. Slightly redundant, but overall compact.

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 an output schema and annotations covering safety, the description is adequate for a simple read-only list tool. The missing explanation of the limit parameter is a minor gap, but the description covers the core functionality and return fields.

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% for the single 'limit' parameter, and the description does not explain its purpose or usage. The parameter name is self-explanatory, but the description must compensate for low schema coverage and fails to do so.

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 returns Kitsu category vocabulary with specific fields (id, title, slug, description, child-category count). It distinguishes itself from sibling tools like 'anime' and 'manga' by focusing on the classification taxonomy rather than the titles themselves.

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

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

The description gives clear context for when to use it ('Answers which genres and themes Kitsu uses to classify anime and manga'), but does not explicitly mention alternatives or exclusions. This meets the 'clear context, no exclusions' bar.

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

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

Annotations already declare read-only/idempotent behavior, but the description adds substantial behavioral context: data sources (SEC EDGAR/XBRL, FAERS), precise metrics pulled, off-calendar fiscal year handling, sorting by primary metric, and output structure with citation URIs. This significantly exceeds annotation coverage.

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

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

The description is longer than typical but every clause carries useful information—trigger phrases, data specifics, sorting behavior, and output format. It could be slightly tighter, but there is no fluff or redundancy.

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

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

With no output schema, the description fully covers what the caller will receive: paired data, citation URIs, and sorted results. It addresses tool complexity (two entity types, different data sources) and leaves no major gap in understanding.

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

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

Schema coverage is 100%, but the description elevates parameter understanding: it explains what type='company' vs 'drug' actually fetch and provides concrete examples for the values array (tickers, drug names). It adds semantic depth well beyond the schema's terse field descriptions.

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

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

The description opens with concrete trigger phrases and states the core function: 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call.' It clearly distinguishes from sequential single-pack lookups and sibling entity_profile, making the tool's purpose unmistakable.

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

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

The description explicitly says 'ALWAYS PREFER over sequential single-pack lookups when comparing entities' and provides numerous natural-language examples that signal when to invoke. This gives clear when-to-use guidance and names the alternative approach it replaces.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds substantial behavioral context: account/paid-plan requirements, that it is NOT open-web search, that gaps[] are never invented, that citations are stable and resolvable only when fetchable, that standard/thorough return contradictions[], that large records are semantically excerpted, and latency expectations. This goes far beyond the structured annotations and contains no contradiction.

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

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

The description is long, but nearly every sentence delivers a distinct, necessary fact—auth, primary use, alternatives, output shape, depth semantics, citation guarantees, and latency. It is front-loaded with the account requirement and core capability. It could be slightly more scannable (e.g., bullets) but its density 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 fully carries the responsibility of explaining return values: it describes the findings packet (verbatim evidence, confidence, source, fetched_at, pipeworx:// citation), gaps[], contradictions[], hop field, citation_uri resolvability, and semantic excerpting. It also covers latency, depth trade-offs, and prerequisites. Nothing critical is missing for an agent to select and invoke this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra value by clarifying that the question can be broad/multi-part ('decomposition is the point'), explaining that 'thorough' requires a paid plan, and giving more context on what each depth level does in practice (gap-recovery, chasing leads, contradictions). It does not exhaustively document each nuance, but it supplements the schema meaningfully.

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

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

The description states exactly what the tool does: it performs grounded multi-source research across Pipeworx's 1455 structured data sources, decomposing questions into facets and routing to 5,529 tools in parallel. It clearly distinguishes itself from open-web search and sibling tools like ask_pipeworx by emphasizing structured-data coverage and the findings-packet output.

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

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

It explicitly specifies when to use deep_research ('Best for broad/multi-part questions over structured data') and when to use alternatives ('For a single lookup use ask_pipeworx'; 'For BREAKING or colloquial CURRENT-NEWS ... prefer ask_pipeworx'), and even states the account prerequisite and fallback if not signed in. The depth options are explained in context, making usage guidance unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, lowering the bar. The description adds valuable behavioral context: return of top-N tools with full schemas and the 'no second schema lookup needed' guarantee, which are not covered by annotations.

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

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

The description is a single, information-dense paragraph that front-loads the verb and resource. Every sentence adds value: what it does, when to use it, what it returns, and an explicit recommendation to call it first. No redundancy or filler.

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

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

For a discovery tool with no output schema, the description adequately explains return values (top-N tools with names, descriptions, schemas) and usage context. Combined with rich schema annotations, the agent has sufficient information to deploy 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% with descriptions and examples for all parameters, so baseline is 3. The description adds a broad list of domains (SEC filings, financials, etc.) that helps formulate queries, which is extra value beyond the schema's two examples. Minor deduction because aliases and limit are already well-documented.

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

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

The description clearly states 'Find tools by describing the data or task' and lists specific domains (SEC filings, FDA drugs, etc.), making it distinct from siblings. It also explains the return format, further clarifying its 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?

Explicitly says 'Use when you need to browse, search, look up, or discover what tools exist' and advises 'Call this FIRST when you have many tools available.' This gives clear when-to-use guidance and implies a workflow, though it does not name specific alternatives.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: specific return fields, patent API sunset with soft-fail, GDELT→GNews fallback, and URI format for filings. This goes beyond the annotations and helps the agent predict behavior without needing to invoke the tool.

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

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

The description is dense and front-loaded with example user phrasings and a clear 'ALWAYS PREFER' directive. It is longer than ideal, but every sentence provides useful operational context or return-field specifics, so it remains appropriately 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 there is no output schema, the description thoroughly enumerates the response components (cik, company_name, recent_filings with URI patterns, fundamentals, patents, news, LEI) and explains fallback/soft-fail behavior. All necessary context for invoking the tool is present, making it 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 description coverage is 100% and the description largely repeats the same parameter information (ticker/CIK, names not supported, company type only). The description adds example value for zero-padded CIK but does not introduce substantially new semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool produces a full cross-source profile of a US public company in one parallel call, listing the data sources and return fields. It distinguishes itself from sibling tools by explicitly saying 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' and referencing resolve_entity for name-based lookups.

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

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

Explicit guidance: ALWAYS PREFER over chaining single-pack lookups when the user asks for a holistic view. Also instructs to use resolve_entity first if only a name is available, since names are not supported. This clearly defines when to use the tool and what to do instead.

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

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

Annotations already declare destructiveHint=true; the description adds that the operation targets 'a previously stored memory by key' and frames it as clearing sensitive data, offering useful context about what is destroyed. It stops short of describing irreversibility or idempotent behavior in detail, but the annotations cover the safety profile.

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

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

The description is two sentences, front-loaded with the core action, followed by concrete use cases. Every sentence earns its place and there is no redundant filler.

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

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

For a one-parameter delete operation with destructiveHint and idempotentHint annotations, the description covers what is deleted, when to delete, and how it fits with related tools (remember, recall). It is complete enough for an agent to select and invoke the tool correctly.

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

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

The input schema has 100% coverage; the only parameter 'key' is described as 'Memory key to delete'. The description simply echoes 'by key' without adding further semantic detail, so the schema carries the parameter information.

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 'Delete a previously stored memory by key', which uses a specific verb and resource and clearly distinguishes it from sibling memory tools like remember and recall. It fully states the tool's core function.

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

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

It provides explicit use cases: 'Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier.' It also names complementary tools with 'Pair with remember and recall', giving clear context for when to invoke this tool.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable process context: it fetches the page, extracts title/description/key links, and emits standard llms.txt markdown. It also notes the output format and drop location, going beyond what annotations alone provide. It does not mention failure modes, which keeps it from a 5.

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

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

The description is concise and well-structured: two sentences covering purpose and process, followed by a focused 'Useful for' list. It is front-loaded with the primary purpose and contains no redundant or filler content.

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

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

With no output schema, the description adequately conveys the return value (a 'single text blob' in standard llms.txt markdown). It covers purpose, process, output format, and use cases. It lacks minor prerequisites like URL accessibility or redirect behavior, but the description is otherwise complete for a tool of this simplicity.

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 schema already documents both parameters clearly (url as 'Full URL of the site to summarize' and max_links with default/max). The description does not add parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the tool's function with a specific verb ('Generate'), resource ('llms.txt file'), and scope ('for any URL'). It also provides concrete use cases, which distinguishes it from siblings like ai_visibility_check or scan_competitor_ai_presence.

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

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

The description provides explicit use-case scenarios ('getting a client's site indexed', 'drafting llms.txt for your own project', 'auditing how an AI crawler would see a competitor'). It does not mention when not to use the tool or name alternative tools, but the context is clear enough for selection.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds context by disclosing the return fields and scoping to active subscriptions, which goes beyond the annotations and helps set expectations for the response shape.

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 filler: the first states purpose and output, the second gives usage guidance. Information is front-loaded and every clause 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, single-parameter list tool with no output schema, the description is fully sufficient. It explains what is returned, the default scope, and when to use it, covering the essential context an agent needs.

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

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

Schema coverage is 100% with a clear description for the include_inactive parameter. The description's mention of 'active subscriptions' aligns with the default behavior but adds no extra semantic detail beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'List' and clearly identifies the resource as the caller's active subscriptions, naming the exact fields returned. It distinguishes itself from sibling tools like subscribe and unsubscribe by focusing on read-only listing.

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

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

The description gives clear usage context: use it to review monitored topics before adding more or to find an id to cancel. It implicitly points to alternatives (subscribe/unsubscribe) without naming them, but the guidance is actionable and specific enough for an agent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, fully disclosing the safety profile. The description adds value by specifying the exact return fields and the 'full' nature of the entry, plus the numeric ID constraint, going beyond the bare 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?

A single, well-structured sentence conveys all necessary purpose and output information without filler. It is front-loaded with the verb 'Fetch' and immediately specifies the resource and identifier.

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

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

Given the tool's simplicity (one parameter) and the presence of output schema and annotations, the description is nearly complete. It lists the return fields and the target source (Kitsu), but does not mention edge cases like invalid IDs or network errors. However, these are not typically required for a simple fetch tool.

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

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

The schema only defines 'id' as a string with no description, leaving 0% coverage. The description compensates by clarifying that the ID must be numeric and represents a Kitsu manga entry, effectively guiding the user on the expected input value. This is helpful but does not fully elaborate on format constraints (e.g., valid ID ranges).

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

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

The description clearly states the tool fetches a full Kitsu manga entry by numeric ID, listing specific return fields (title, synopsis, chapter/volume count, status, rating, cover image). This distinguishes it from siblings like search_manga (search by query) and top_manga (lists), and from anime (which targets anime entries).

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 the user has a numeric manga ID and needs comprehensive details. It does not explicitly name alternatives or exclusions, but the 'by numeric ID' phrasing provides a clear context. Sibling tools like search_manga suggest an alternative path, but the description does not mention when not to use this tool.

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

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

Annotations are all false and uninformative, so the description carries the full burden. It discloses key behaviors: filing without an account returns a claim_token, how to use the token later, rate-limiting (5 per identifier per day), that it's free and doesn't count against quota, and that the team reads digests daily. 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 somewhat long but every sentence earns its place: purpose, triggers, scope exclusion, claim_token usage, and rate limit. It is front-loaded with the main action. Minor redundancy ('Filing without an account returns...' and 'Read the reply...' could be tighter) but overall efficient.

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

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

For a feedback tool with 4 parameters, nested context, no output schema, and no read-only guarantees, the description comprehensively covers how to use it, what happens after filing, and what not to do. It provides enough to invoke correctly without additional context, including the claim_token retrieval flow and scope restrictions.

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 descriptively named parameters, so baseline is 3. The description adds significant extra meaning by explaining the claim_token workflow ('pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed') and the 'don't paste the end-user's prompt' guidance for message content, which goes beyond the schema.

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

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

The description opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes this feedback tool from sibling tools like ask_pipeworx or discover_tools, and enumerates the types of feedback (bug, feature, data_gap, praise).

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

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

Explicit when-to-use guidance is given: 'Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise).' It also provides a clear exclusion: 'ONLY for tools served by this Pipeworx connection... file it with that server instead' for other MCP servers, and tells users how to identify Pipeworx 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=true, idempotentHint=true, etc., so safety is covered. The description adds valuable context: data source (CF analytics-engine), privacy (no PII), and caching behavior (5min-1h), which enriches the agent's understanding beyond the annotations.

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

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

The description is well-structured: a clear lead sentence, a numbered list of use cases, and a terse technical note. It is slightly longer than the bare minimum but every sentence carries useful information, with no fluff.

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

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

Despite having no output schema, the description explains the output components (top tools, top packs, total call volume), the data shape (pack, tool, count), and freshness (cached 5min-1h). This is complete for a simple read-only analytics 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 a single 'window' parameter and enums, and the schema description already explains the meaning of each window. The tool description merely repeats the window values without adding additional semantics, so it meets the baseline but doesn't exceed it.

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

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

The description clearly states it returns top tools, top packs, and total call volume from other agents' Pipeworx usage, with a specific verb ('Returns') and resource. It distinguishes itself from sibling tools like discover_tools or ask_pipeworx by focusing on aggregate trending signals.

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

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

Provides explicit use cases (discovering hot data sources, confirming canonical tools, checking alignment) but does not contrast with alternatives or state when not to use. The context is clear enough for an agent to decide when this is relevant, but exclusions 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?

Even though annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the description adds rich behavioral context: the fill check against live CLOB depth, the >3pp threshold for signals, the semantic-anchor Jaccard filter, the partition placeholder filter, and the warning that realizable_edge_pp <= 0 means the edge is not tradable. This goes far beyond the annotations and fully discloses the tool's behavior.

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

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

The description is long but densely packed with necessary information and clearly organized with labeled sections (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK). The first sentence front-loads the core purpose, and every sentence adds operational value. No filler or redundancy.

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

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

No output schema exists, so the description carries the full burden of explaining return values. It enumerates opportunities[], partition_check{}, fill check fields, and the meaning of realizable vs theoretical edge. It also covers edge cases like placeholder filtering and low-similarity pairs. For a tool of this complexity, the description is remarkably complete.

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

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

Schema coverage is 100% and the schema already describes event and topic, but the description adds substantial meaning: concrete slug examples, that full Polymarket URLs are accepted, what kind of seed question works for topic, and the deeper semantics of each mode. This elevates the parameter semantics well 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 opening sentence explicitly states the tool's function: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It distinguishes three distinct modes (trending_scan, event, topic) and names the specific resources, making its purpose unambiguous relative to sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

The description gives explicit usage guidance: 'Call with NO args for a trending_scan... pass event for... or topic for...' It recommends event for a specific market and topic for cross-event scanning, explains when cross-event mode is valuable, and directs users to polymarket_fill_risk for custom sizing. This is a model of usage clarity.

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 is exceptionally transparent about behavior: details edge calculation net of slippage, Kelly caps at 0.25, 24h-move warnings, placeholder-slug filtering, partition overround construction, diagnostics for empty segments, and 1h caching. It even explains why min_kelly does not apply to partitions and why paid OIS/SOFR data is needed for reliable Fed bets — all beyond the annotation hints. 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 long and dense, but every sentence earns its place — model families, edge metrics, knobs, diagnostics, and caching are all covered. It is front-loaded with the purpose statement. While not concise in the two-sentence sense, the complexity of the tool justifies the length, and the structure is well-organized.

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

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

With no output schema, the description carries the full burden of explaining the response shape. It thoroughly describes by_segment, fed_candidates/fed_note, _diagnostics with funnel counters, and includes concrete output fields like edge_pp_net, kelly_fraction, market.liquidity, and spread_pp. It also covers caching, stale-data behavior, and filter-drop reasoning — making it remarkably complete for a tool of this complexity.

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

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

Schema description coverage is 100% with detailed per-parameter descriptions, meeting the high-coverage baseline of 3. The description adds extra semantic value by grouping min_liquidity / max_spread_pp as 'TRADEABLE-EDGE KNOBS' and explaining how min_partition_leg_kelly interacts with min_kelly, which helps agents reason about filtering behavior beyond the schema alone.

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

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

The description opens with a clear verb+resource+scope: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' This distinctly positions it as a discovery tool among siblings, and the 'what should I bet on today' framing reinforces its purpose without ambiguity.

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

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

Provides clear usage context: built for discovering opportunities without paging hundreds of markets, and explains when to apply knobs like min_liquidity and max_spread_pp. It also explicitly states why Fed bets are excluded. However, it does not explicitly name alternative sibling tools or provide when-not-to-use guidance, stopping short of a 5.

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

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

The annotations already mark it as read-only and safe, so the description adds substantial behavioral detail beyond that: history depth bounded by a 60-day TTL, snapshots written only on cache-miss (meaning gaps indicate no scan), and decay computed from daily closes rather than intraday. These are critical nuances that affect interpretation of results and are not captured in annotations. The description also explains the response structure thoroughly, covering tracked[], expired[], and snapshot_dates[].

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

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

The description is longer than typical, but it is well-structured with clear sections (Args, RESPONSE, LIMITS) and front-loads the purpose. It is not unnecessarily verbose for the amount of critical information it conveys, though it could be slightly tightened. Each section 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?

The tool has no output schema, so the description must explain the return structure on its own—and it does so exhaustively. It covers the meaning of each response field, the interpretation of lifespan, limitations from TTL and data gaps, and the source of decay values. This is a complete picture for an agent to invoke the tool and understand results without further guesswork.

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

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

The schema already fully documents both parameters (days: lookback with default/clamp, window: family with enum). The description repeats the defaults and adds the term 'snapshot family' but does not add meaning beyond the schema's descriptions. Since schema coverage is 100%, the baseline is 3, and the description provides marginal extra value.

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

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

The description opens with a specific, action-oriented purpose: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It clearly answers a concrete question ('how long has this edge existed and is it shrinking?') and distinguishes itself from sibling tools by focusing on temporal analysis rather than just current edges. This is more than just a restatement of the name.

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

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

The description provides clear context for when this tool is relevant: you use it to understand edge persistence/decay, and it contrasts a fresh edge with an old one. It does not explicitly name alternatives or state exclusions, but it implicitly differentiates from the related 'polymarket_edges' tool by being built on its snapshots. The intended use case is clear enough for an agent to select it appropriately.

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, but the description adds critical context beyond these: it warns that 'partial basket fills convert an arb into an unhedged directional position' and that 'theoretical overround on thin books is not capturable.' These insights are not evident from annotations alone and significantly enhance the agent's understanding of potential risks.

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

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

Though the description is relatively long, it is front-loaded with the core purpose and systematically organized into requirements, mode-specific behavior, outputs, and usage guidance. Every sentence contributes value—there is no redundancy or filler. The density is justified by the tool's complexity and the absence of an output schema.

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

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

With no output schema, the description compensates by enumerating all return values for both modes (top_of_book, vwap_fill_price, slippage_pp, verdict, etc. for single-market; theoretical_sum, realizable_sum, capture_ratio, thin_legs[], etc. for basket). It also covers edge cases like thin legs and forced directional risk, plus the size clamp, making the description self-contained and actionable.

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

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

Schema coverage is 100%, but the description goes far beyond the schema definitions. It explains that exactly one of market or event is required, interprets size_usd differently in single-market (max spend vs target proceeds) versus basket (settlement notional), and clarifies side defaults and auto-selection logic. This adds substantial meaning to each parameter beyond the basic schema descriptions.

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

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

The description opens with a specific verb+resource: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It clearly distinguishes itself from sibling tools like polymarket_arbitrage and polymarket_edges by focusing on fill risk and slippage, and it details two distinct modes (single-market and basket), making its purpose unambiguous.

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

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

The description explicitly states when to use the tool: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It names the alternative tools and explains the rationale (thin books, partial fills), providing clear context for when it is needed versus when it may be unnecessary.

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, and the description adds extensive behavioral context: compatibility_warning firing conditions, temporal_alignment semantics, skipped_cross_type/subtype counters, and a candid limitation about pre-mapped topics. This goes far beyond the safety profile already provided.

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

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

The description is well-structured with visible labels (TWO MODES, RESPONSE, SAFETY FIELDS) and every sentence carries operational meaning. It is long, but the complexity of the safety warnings justifies the length; still, it could be slightly tightened without losing essential caveats.

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

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

With no output schema, the description fully compensates by specifying the response shape: leg-by-leg prices, spread[].top_spreads_pp, compatibility_warning conditions, temporal_alignment, and skipped counters. The tool is fully actionable without needing external documentation.

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

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

The input schema already covers all 3 parameters at 100% with descriptions and examples, so the baseline is 3. The description adds value by explaining the relationship between topic shortcuts and explicit overrides, and by framing the two modes ('auto-fetch the matching event' vs 'custom pairings'). This additional framing justifies 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 opens with a specific statement: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question,' which clearly identifies the verb (compute spread), resource (Kalshi/Polymarket venues), and scope. It distinguishes itself from venue-specific siblings like polymarket_arbitrage and polymarket_edges by focusing on cross-venue comparison and explains two distinct modes.

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 presents TWO MODES — topic shortcuts and explicit kalshi_event_ticker + polymarket_event_slug — and explains when each is appropriate. It also warns that 'most pre-mapped topics return compatibility_warning today' and that 'pre-mapped ≠ tradeable,' which gives practical guidance on when results may not be meaningful. It does not explicitly name sibling tools as alternatives, so it falls just short of a 5.

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

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

Annotations already convey read-only, idempotent, and non-destructive behavior, and the description adds valuable context about scoping to identifier and the remember/forget lifecycle. It doesn't describe edge cases like missing keys, but the annotation coverage makes this sufficient.

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

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

Three sentences, each earning its place: function, use case, and scope/pairing. No fluff or redundancy, and the primary action is front-loaded.

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

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

For a simple single-parameter tool with strong annotations, the description covers purpose, usage, scope, and relationships in a compact space. No missing critical information.

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 documents the 'key' parameter with full coverage, and the description enriches it by providing concrete examples (ticker, address, research notes) and clarifying the omit-to-list behavior. This adds meaningful semantic context beyond the schema.

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

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

The description clearly states the tool retrieves a value saved via 'remember' or lists all keys, using explicit verbs. It distinguishes from siblings by naming 'remember' and 'forget' as complementary actions, making its role unambiguous.

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

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

It provides a clear 'when to use' by advising to look up previously stored context without re-deriving, and names 'remember' as the saving counterpart. It lacks explicit 'when not to use' exclusions, but the pairing with siblings and contextual examples give strong guidance.

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

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

The description adds significant behavioral context beyond annotations: it explains the return payload structure (source, citation_uri, raw event payload), the side effect of mark_read (flagging events as read so subsequent calls only show newer ones), and the suitability for polling. Annotations already declare readOnly/idempotent, so the description enriches rather than merely restates.

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 compact, front-loaded with the primary action, and every sentence serves a purpose. It covers functionality, filtering options, a side-effect, and an alternative access point without any wasted words.

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

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

Despite having no output schema, the description adequately covers return values and parameter usage. It also addresses polling, filtering, and the existence of an alternative endpoint, making the tool complete enough 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by giving concrete examples for 'type' (sec_8k), clarifying the format for 'since' (ISO timestamp), and explaining the behavioral impact of 'mark_read' — details not fully captured in the schema descriptions alone.

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

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

The description clearly identifies the tool as pulling fired events from a subscription feed and returning the most recent alerts. It specifies the resource and the verb ('Pull'), and distinguishes from siblings like 'recent_changes' by mentioning 'alerts' and 'subscription feed' explicitly.

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

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

The description provides clear context for when to use the tool (e.g., polling) and even points to an alternative access method (GET registry.pipeworx.io/alerts.json) for scripts/dashboards. However, it does not explicitly state when not to use this tool in favor of sibling tools, so it falls short of a perfect 5.

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

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

Annotations already establish read-only/idempotent, and the description adds meaningful behavioral context: fans out to multiple sources, GDELT→GNews fallback, USPTO soft-fail due to API sunset, and return format. No contradiction.

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

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

The description is dense but every sentence adds value—query examples, source fan-out, format details, return shape, and alternative. 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?

No output schema, yet description clearly explains return structure (changes[], total_changes, citation URIs). Covers sources, fallback, date formats, and alternative tool—complete for a complex tool.

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

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

Schema covers all parameters with examples (ISO/relative since, ticker/CIK). Description adds some contextual use guidance (typical monitoring values) but largely mirrors schema content. With 100% schema coverage, 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's a change feed for a company over a time window, with specific query examples. It distinguishes itself from entity_profile by contrasting dynamic changes vs static profile, so it's unambiguous among siblings.

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

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

Explicitly provides when to use ('what's new' questions) and when not to (use entity_profile for static profile), plus notes fallback behavior and soft-fail conditions. This gives clear decision guidance.

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

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

The annotations already cover read-only, idempotency, and destructive flags, so the description needs to add context. It does so by disclosing persistence behavior (authenticated vs. anonymous sessions) and scoping ('scoped by your identifier'), which is valuable beyond the annotation fields. It does not contradict the annotations.

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

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

The description is front-loaded with the core purpose, followed by condensed usage guidance and persistence details. Every sentence adds value without repetition — it is appropriately sized for the tool's simplicity.

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

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

For a low-complexity two-parameter tool with no output schema, the description covers all needed context: purpose, when to use, persistence semantics, and integration with sibling tools. Nothing essential is missing.

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

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

The input schema already has 100% coverage with descriptions for both key and value. The description reinforces the key-value model and provides real-world examples, but it does not add new parameter-level semantics beyond what the schema already provides.

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

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

The description clearly states the tool's function with a specific verb ('Save') and resource ('data the agent will need to reuse later'), and explicitly contrasts with sibling tools recall and forget. This makes it easy to distinguish from other memory-related operations.

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

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

It provides explicit when-to-use guidance with concrete examples ('a resolved ticker, a target address, a user preference, a research subject') and directly names the pairing tools ('Pair with recall to retrieve later, forget to delete'). This is model guidance for choosing this tool over 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?

Annotations declare readOnly, openWorld, idempotent, non-destructive. The description adds valuable behavioral context beyond these: identifiers are labeled with their source, unresolved identifiers are explicitly listed under 'unresolved' rather than omitted, and LEI/FIGI enrichment degrades gracefully if upstream sources are unavailable. It also mentions that each call cascades through multiple internal endpoints, setting expectations for latency and complexity.

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

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

The description is long, but every sentence provides essential detail: examples, use-case guidance, per-type behavior, and graceful degradation. It is front-loaded with examples and the core purpose. The 'company' sub-description is particularly dense with parentheticals, slightly hindering readability, but the density is necessary given the complexity of the data returned.

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

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

With no output schema, the description carries the full burden of explaining return values. It covers both entity types thoroughly: company returns CIK, ticker, LEI, FIGI, ownership info, and unresolved list; drug returns RxCUI, ingredient, brand, and citation. It also addresses failure modes (unavailable GLEIF/OpenFIGI) and the internal cascade. This is complete for a lookup tool of this complexity.

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

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

Schema coverage is 100% with basic parameter descriptions, but the description adds substantial meaning. For 'company' it explains the cross-source identity spine (CIK, ticker, LEI, FIGI) and what input formats are accepted (ticker, CIK, or name). For 'drug' it specifies the output components (RxCUI, ingredient, brand) and citation format. This goes well beyond the schema's simple field descriptions.

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

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

The description opens with concrete query examples and explicitly states the tool's purpose: 'resolve a user-spoken NAME to the canonical/official identifiers other tools require as input.' It distinguishes itself from sibling tools by naming its role as a preliminary lookup step and listing supported entity types (company, drug). The verb+resource+scope is specific: it resolves names to official identifiers.

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

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

The description gives explicit when-to-use guidance: 'Use FIRST whenever you have a name but need an ID.' It also explains why it should be preferred over manual multi-step lookups: 'using resolve_entity replaces 2-3 manual lookups.' This clearly signals when this tool is appropriate, though it does not discuss when not to use it, the 'Use FIRST' directive is strong 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 annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds meaningful behavioral detail: it probes each entity via ai_visibility_check, ranks by score, and returns a list with score, confidence, and signal density. This gives insight into internal mechanics without contradicting any annotation.

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

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

The description is concise (four sentences) and front-loaded with the primary purpose. Each sentence adds value: purpose, mechanism, example use case, and output format. No redundant or filler content.

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

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

Given the tool's complexity (4 params, no output schema), the description provides a solid overview including return format and use case. It does not mention edge cases or error handling, but the complete schema and clear purpose make it sufficiently complete for an agent to understand what the tool does and what it returns.

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 all 4 parameters, so the baseline is 3. The description does not add significant meaning beyond the schema; it restates the first-entity-as-subject concept but otherwise relies on the schema's thorough documentation.

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

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

The description clearly states the tool's function: 'Compare AI visibility across multiple entities side-by-side,' with a specific verb and resource. It distinguishes from the sibling ai_visibility_check by explicitly mentioning it probes each entity with that sub-tool and ranks results.

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

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

Provides clear usage context: 'Useful for competitive AI-marketing audits' with an example query. However, it does not explicitly state when NOT to use it or name alternative tools for single-entity checks, though the mention of ai_visibility_check implies the distinction.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds significant behavioral context beyond these: the composite fan-out nature, graceful degradation on partial failures, the 5-30s first-measurement delay for bundlephobia, and the sources_failed field in case of timeouts. This fully discloses expected behavior.

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

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

The description is front-loaded with purpose, then usage, return summary, ecosystem constraints, and failure behavior. Every sentence contributes unique information, and despite being moderately long, it is efficiently organized for a composite tool with multiple sources and edge cases. No filler or redundancy.

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

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

With no output schema, the description fully compensates by enumerating the return summary fields (is_latest, license, published_at, advisory_count, bundle_kb_min, bundle_kb_gz, dependency_count, has_esm, tree_shakeable), per-advisory detail, links, and recent alternative versions. It also covers ecosystem limitations and timeout behavior, making the tool's usage and expected output completely clear.

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

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

Schema coverage for parameters is 100%, with both 'package' and 'version' fully described in the schema (npm package name, scoped packages accepted, version defaulting to latest). The description adds no substantial semantic value beyond the schema, merely reiterating the schema's own explanation. 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 defines the tool's purpose: a composite 'should I add this npm package to my project' check that fans out across deps.dev and bundlephobia. It specifies the exact resources inspected (license, advisories, version history, bundle size, dependency count, ESM/tree-shake support) and is easily distinguishable from sibling tools, none of which perform dependency scanning.

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

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

Explicit guidance is given: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also provides an exclusion with an alternative: 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly'. This clearly states when to use and when not to use the tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and non-destructive. The description adds that this is a full-text search returning up to 20 matches and enumerates the returned fields (id, titles, synopsis, etc.), which gives useful behavioral context beyond annotations without contradiction.

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

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

The description is two sentences, front-loads the core action, and uses the second sentence to enumerate return values. No extraneous content.

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

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

Given the simple 2-parameter schema and existing annotations, the description is complete: it states the search limitation (by title), the maximum result count, and lists the return fields. It doesn't need to explain return values since an output schema exists, but the inclusion of that list makes the tool self-contained.

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

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

The schema provides ranges/defaults for limit (1-20, default 10), and the description adds that the query is a title search via 'by title.' However, it doesn't elaborate on limit semantics beyond 'up to 20 matches,' and with 50% schema coverage, the description provides moderate added value.

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

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

The description states a specific verb+resource+scope: 'full-text search of Kitsu's anime catalogue by title' and clarifies the tool's purpose as 'Answers what the Kitsu entry for an anime is and what its id is.' This clearly differentiates from sibling search_manga and top_anime, which focus on different resources.

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 an anime title needs to be searched in the Kitsu catalogue, and notes the result includes the id. However, it does not explicitly exclude other search types (e.g., searching by staff or genre) or compare with alternatives like search_manga, so guidance is clear but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context by specifying the result limit (up to 20 matches) and the exact return fields (id, titles, synopsis, counts, status, rating, cover). This goes beyond the annotations and helps agents understand what to expect from the tool.

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

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

The description is three clear, front-loaded sentences: the first states the primary purpose and limit, the second enumerates returned fields, and the third summarizes the core use. Every sentence provides meaningful detail without redundancy or fluff. It is appropriately concise for a search tool.

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

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

Given the tool's low complexity (2 params, 1 required) and the presence of an output schema, the description is complete enough. It covers the tool's purpose, search scope, result limit, and return fields, giving the agent sufficient context to decide when and how to invoke it. No critical information is missing.

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

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

The input schema has no parameter descriptions (0% coverage). The description partially compensates by indicating that the query is a title search for manga and that results are capped at 20. However, the 'limit' parameter is not explicitly explained, leaving ambiguity about whether it overrides this default. This adds some meaning but not complete compensation for the missing schema descriptions.

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

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

The description clearly states the tool performs full-text search of Kitsu's manga catalogue by title, which distinguishes it from sibling tools like search_anime. It explicitly answers what the tool does: returns a Kitsu manga id and entry details. This is specific verb+resource and differentiates from alternative search 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 clear context that this tool is for searching manga by title in the Kitsu database, and its purpose is to obtain the Kitsu manga id and details. It implies usage for manga-related lookups rather than anime, but does not explicitly mention alternatives or exclusion criteria. This is clear context without explicit when-not-to-use guidance.

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

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

Beyond the readOnly/idempotent annotations, the description discloses return format (passages with offsets and scores), underlying algorithm (BGE-base-en embeddings, cosine similarity, 500-char overlapping windows), and input handling (200K char cap, truncation with flag). This exceeds what annotations provide and adds critical operational context.

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

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

Three dense, information-packed sentences with no superfluous words. Purpose is front-loaded, then usage guidance, then technical constraints. 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?

Even without an output schema, the description fully covers return values (passages with offsets and similarity scores), algorithmic behavior (embeddings, windowing, truncation), and integration with sibling ask_pipeworx_grounded. It gives the agent everything needed to decide when to invoke and what to expect.

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

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

Schema covers all 3 parameters with descriptions, and the tool description enriches them with real-world examples ('supply-chain risk', 'fiscal year 2024 revenue') and clarifies the 'text' parameter's purpose (already-pulled record). It also adds behavior beyond schema (truncation flag), which parametrically informs the agent.

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 'Semantic search INSIDE a fetched record' with specific outputs (top-N passages with character offsets and similarity scores) and concrete examples. It distinguishes itself from siblings like ask_pipeworx_grounded by emphasizing 'inside a fetched record' vs grounding 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 states when to use ('record is too big to cram into the prompt'), provides a usage pattern with ask_pipeworx_grounded ('fetch with the gateway, ground over the relevant passages'), and explains the benefits (saves context, verifiable quotes). This is clear guidance with an alternative named.

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, the description discloses important behavioral details: the need for an OAuth account, persistence limitations, the always-on feed, email/SMS requirements (verified phone, 10/day cap), and the fact that the subscription id is returned. This adds significant context that annotations alone do not provide.

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

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

The description is long but densely packed with necessary information: purpose, prerequisites, supported types with examples, and delivery channels. It is well-structured and front-loaded with the main purpose, though the length could be trimmed without losing value.

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

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

For a complex tool with 5 subscription types and nested delivery options, the description covers purpose, prerequisites, examples, and return value. It omits the webhook delivery channel (though the schema covers it) and only highlights three of the five types, but this is a minor gap given the schema's 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?

The input schema already provides 100% parameter descriptions with type-specific examples, and the description largely mirrors these examples (e.g., items:['5.02'], series_id:'UNRATE'). It does not add new semantic meaning beyond the schema, earning the baseline score of 3.

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

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

The description clearly states the tool's function: 'Create a proactive monitoring subscription to a live-data event stream.' This specific verb+resource phrasing distinguishes it from siblings like 'list_subscriptions' and 'unsubscribe', and the mention of 'proactive monitoring' contrasts with pull-based tools like 'recent_alerts'.

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

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

The description gives explicit prerequisites (requires Pipeworx OAuth account, anonymous and BYO cannot persist) and explains delivery channels including the always-on feed that can be pulled via recent_alerts. It does not explicitly state when not to use this tool, but the context and comparisons to alternatives are 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds value beyond that by disclosing the return shape: category-bucketed example questions with the exact tool and argument shape for each, drawn from the live catalog of thousands of tools. This is useful behavioral context not present in the annotations.

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

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

The description is a single dense paragraph, but every clause contributes: example questions, categories, return details, argument usage, and onboarding use-case. It is not as crisp as a two-sentence example (e.g., TDQS 4.3), but it is well-structured and front-loaded with the core question phrases. No redundancy; the schema and description complement without duplication.

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

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

With no output schema, the description fully carries the burden of explaining return values, and it does: 'Returns category-bucketed example questions... each with the exact tool + argument shape.' It also covers argument behaviors, the onboarding context, and how to learn about meta-tools. For a zero-required-parameter tool with rich scope, 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?

The schema already covers the single 'topic' parameter at 100% with a description enumerating allowed focus areas. The description adds only slight reinforcement by giving examples ('finance', 'pharma', 'betting') and stating 'Omit for a cross-category spread,' which aligns with the schema. This is baseline for high schema coverage; the description does not introduce 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 the tool's substantive purpose with a specific verb and resource: it is the onboarding entry point to discover what can be asked of Pipeworx, returning category-bucketed example questions. It clearly distinguishes itself from potential siblings like discover_tools by framing itself as the meta-level 'what can I ask' entry point and explicitly mentioning the meta-tools (ask_pipeworx, entity_profile, compare_entities) it can teach.

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, or to learn how to call the meta-tools.' This is a clear when-to-use directive. It also explains that omitting the topic gives the full spread and passing a topic focuses the results, providing actionable usage guidance. No exclusions are given, but the guiding context is strong.

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

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

Annotations already indicate a safe, read-only, idempotent operation, so the bar is lower. The description adds valuable behavioral details: ordering options, a maximum of 20 entries, and the exact fields returned (id, titles, ranks, rating, episode count, synopsis). 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 two sentences, front-loaded with the core purpose. Every sentence adds value: the first defines the tool, the second details output and use cases. 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's simplicity, the description is complete. It covers what data is returned, possible orderings, and the maximum result count. With an output schema present, no further return-format details are needed.

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

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

The schema covers only 50% of parameters, but the description compensates fully. It explains the 'by' parameter as 'popularityRank (default) or ratingRank' and the 'limit' parameter by stating 'up to 20 entries,' giving both meaning and constraints.

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

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

The description clearly states the tool's function: returning the highest-ranked anime on Kitsu, ordered by popularityRank or ratingRank. It specifies the resource (Kitsu anime) and differentiates from siblings like search_anime and top_manga by focusing on ranking lists.

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 by saying 'Answers which anime are most popular or highest rated according to Kitsu,' providing clear context. However, it does not explicitly mention alternatives or when not to use the tool, though sibling names suggest the distinction.

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 and idempotent behavior, so the description's addition of the sortable ranks and the 20-entry cap provides useful behavioral context. 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 entire description is one front-loaded sentence, conveying all essential information without waste.

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

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

The tool is simple with only two parameters and an output schema exists, so the description covers the needed context: source, sorting, result count, and fields. No significant gaps.

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

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

With 0% schema description coverage, the description carries the full burden for parameters. It explains both 'by' (popularityRank default or ratingRank) and 'limit' (up to 20 entries), making the parameter meanings clear.

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

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

The description clearly identifies the tool's function: listing top-ranked manga from Kitsu, with specific sorting options (popularityRank or ratingRank) and return fields. This distinguishes it from siblings like top_anime and search_manga.

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 when to use the tool (for top-ranked lists) by stating the default sort and the cap of 20 entries. However, it does not explicitly mention alternatives or exclusions, such as using search_manga for filtered queries, so it only earns a 4.

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

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

Annotations already indicate this is a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable context: ownership enforcement and that the row is deactivated rather than deleted, preserving historical events via recent_alerts. This goes beyond basic annotation coverage.

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

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

The description is two sentences long, front-loaded with the core action, and every clause adds meaningful context. No redundant phrases or filler.

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

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

For a simple one-parameter cancellation tool, the description covers the essential behavioral aspects: ownership, soft-delete, and historical data availability. Given the lack of an output schema, it is reasonably complete, though it could optionally mention the response format or post-cancellation state.

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

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

The schema fully describes the single 'id' parameter (100% coverage), including its type and origin ('returned by subscribe'). The description merely reiterates 'by id', adding no new semantic value beyond the schema, so baseline 3 is appropriate.

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

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

The description opens with 'Cancel a subscription by id', a specific verb+resource pair that clearly identifies the tool's function. It distinguishes itself from sibling tools like subscribe and list_subscriptions by focusing on cancellation.

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 mentions ownership enforcement ('you can only cancel your own subscriptions') and the soft-delete behavior, giving clear context on when it's appropriate to use. While it doesn't explicitly name alternative tools, the sibling list and naming conventions make the use case obvious.

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/open-world/idempotent annotations, the description details crucial behavioral nuances: the meaning of every verdict, especially distinguishing could_not_verify (check did not happen, contains verification_error, must not be cited as evidence) from unsupported (no source exists). It also discloses the fallback routing, exact percent-delta math, and the pipeworx:// citation output, which the annotations alone do not convey.

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

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

The description is long but appropriately front-loaded with query examples and a clear purpose. Each section earns its place: usage trigger, routing, verdict semantics, and a note on efficiency. The only minor inefficiency is overlapping phrasing ('grounded pipeline' vs 'live source'), but overall it remains well-structured and readable.

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

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

For a tool with no output schema and moderately complex behavior, the description is remarkably complete. It defines all return verdicts, explains error states, describes source routing, and specifies the delivery of evidence with citations and reasoning. The agent is fully equipped to interpret results and handle edge cases like could_not_verify.

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

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

Schema coverage is 100%, with both parameters fully described. The description adds no additional parameter semantics; it references tolerance_pct only indirectly via 'exact percent-delta math' but does not go beyond what the input schema already states. This is the expected baseline when the schema carries the parameter burden.

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

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

The description uses a specific verb+resource ('natural-language claim verification against authoritative sources') with concrete invocation examples ('Is it true that…' / 'fact check'). It clearly differentiates from siblings by explaining it replaces a multi-step pipeline of NL parsing, entity resolution, lookup, and comparison, and uniquely handles both structured SEC and grounded fallback paths.

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 'Use whenever the agent needs to check whether something a user said is factually correct' and explains the branching for company-financial vs. other claims. It does not explicitly name alternative tools as better choices for other use cases, but provides clear contextual guidance and even notes it replaces 4–6 sequential calls, signaling when to choose this over manual delegation.

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