Watchmode

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

Annotations provide readOnlyHint, idempotentHint, etc. The description adds crucial behavioral details: that using Anthropic requires a BYO API key (passed to api.anthropic.com), and the default model is free. It also explains the return structure including per-model results and combined view, going beyond annotation hints.

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

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

The description is a single paragraph of about 70 words, front-loading the purpose and key details. Every sentence adds value; there is no redundancy or fluff.

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

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

No output schema exists, so the description must explain return values. It does so succinctly: 'Returns per-model {score, confidence, signals, raw_response} + a combined view.' This is sufficient for understanding outputs, though more detail on 'signals' or 'confidence' could be added.

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 all parameters have descriptions. The description adds marginal value, e.g., providing an example entity 'Pipeworx' and clarifying that '_apiKey' is only needed for Anthropic. While helpful, it does not significantly extend schema 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 clearly states it probes LLMs for knowledge about a business/brand/product/topic and scores visibility (0-100) per model. It specifies the default model and optional Anthropic probe, distinguishing it from sibling tools like 'ask_pipeworx' or 'deep_research' which serve different purposes.

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

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

The description lists use cases: 'AI-marketing audits, pre-launch brand checks, competitive monitoring.' It does not explicitly state when not to use it or compare directly to alternatives, but the context implies appropriate scenarios.

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

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

Annotations already establish readOnly/openWorld/idempotent behavior, and the description adds useful context: it fills arguments, returns structured answers with stable pipeworx:// citation URIs, works on every tier, and is a single fast call. It does not fully detail output formatting or edge cases, but with annotations covering the safety profile, the added behavioral context is more than 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?

The description is longer than average but well structured: it front-loads the key directive 'PREFER OVER WEB SEARCH', gives capability context, then moves to usage triggers, examples, and alternative sibling tools. The content is dense and purposeful, though a few repeated ideas and the long domain list could be trimmed without losing meaning.

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 general-purpose query tool with no output schema, the description is complete: it specifies the input, gives examples, names the correct sibling tools for different needs, explains the return style (structured answer with citation URIs), and even mentions handling of live news and breaking-news questions. An agent has everything needed to select and invoke the tool correctly.

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

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

Schema coverage is 100% since all parameters are documented aliases for 'question'. The description adds semantic value beyond the schema by explaining what kind of natural-language questions fit (factual, real-world entities/events/numbers) and by providing concrete examples such as 'current US unemployment rate' and 'Apple's latest 10-K', which helps the agent formulate valid inputs.

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 clear verb/role: route a factual question to 5,724 tools across 1,497 verified sources and return a structured answer with citation URIs. It distinguishes itself from web search and explicitly names siblings ask_pipeworx_grounded and deep_research as alternatives, so an agent can tell them apart without inspecting the schema.

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

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

The description gives explicit when-to-use guidance with trigger phrases ('what is', 'look up', 'find', 'get the latest'), domain examples, and a 'START HERE for most questions' directive. It also states when to step up to ask_pipeworx_grounded for hallucination-resistant single answers and to deep_research for broad/multi-part questions, which is model routing guidance beyond any structured field.

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

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

The description goes well beyond the annotations by disclosing that this is an experimental edge, that no candidate is currently active, that it currently matches ask_pipeworx exactly, and that results feed routing decisions. It also clarifies it is a full working router rather than a fallback stub, which is important behavioral context.

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

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

Every sentence earns its place: beta status, current candidate state, usage directive, and fallback clarification. The most decision-relevant information is front-loaded, 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?

The description provides enough context for an agent to use the tool today: it points to ask_pipeworx for the interface and explicitly says the current behavior matches it. It delegates the response shape to the sibling definition rather than describing it directly, but the pointer is clear and no output schema exists to fill that gap.

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 parameter meanings and aliases are already fully documented. The description says 'same arguments' and 'use it exactly like ask_pipeworx' but adds no new parameter-level detail, matching the baseline for fully covered schemas.

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

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

The description states a specific verb and resource: a universal router covering 5,724 tools, and explicitly frames itself as the beta twin of ask_pipeworx. It distinguishes itself from the stable sibling by naming experimental routing improvements as the differentiator, so an agent can understand exactly what this variant is for.

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

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

It gives explicit usage direction: use exactly like ask_pipeworx when the newest routing is wanted, and notes results are compared against the stable router. It does not spell out a when-not-to-use case or compare against ask_pipeworx_grounded, but the context is clear enough to select between the beta and stable variants.

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 the description adds significant behavioral context: it returns only what the tool result contains, produces a structured refusal with enumerated refusal_reason values, and incurs one extra LLM call. It also specifies the exact success and refusal output shapes, going well 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 dense but every sentence earns its place: purpose, routing behavior, output contract, use cases, and cost/alternative routing. It is front-loaded with the most important selection signal ('hallucination-resistant') and structured so an agent can quickly decide whether to use this 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?

There is no output schema, so the description correctly compensates by specifying the full return shape for both success and refusal, including refusal_reason enumeration. It also covers routing, cost tradeoff, and when to prefer a sibling. For a tool of this complexity, 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?

Schema coverage is 100%, so the schema already documents the single semantic parameter and all aliases. The description adds no new parameter syntax details; its mention of 'fills arguments' is behavioral rather than parameter-specific. Baseline 3 is appropriate because the schema carries the parameter documentation 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 opens with a specific function: 'Hallucination-resistant answer mode for high-stakes reads.' It clearly states the mechanism (same routing as ask_pipeworx, then extracts only from tool results) and the output contract (answer with evidence or explicit refusal). It also distinguishes itself from the sibling ask_pipeworx by the grounded extraction and refusal behavior.

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

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

Explicitly states when to use: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' with concrete domains (financial verdicts, legal claims, etc.). It also gives an exclusion: 'prefer ask_pipeworx for casual lookups' and names the cost difference, allowing the agent to route correctly.

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

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

Annotations declare readOnly, openWorld, idempotent, non-destructive. Description adds extensive behavioral details: fan-out logic per category, resolver contract with match confidence and alternatives, parent event extraction for partitioned bets, news fallback mechanisms, safety short-circuit for low-confidence/closed markets, wide-spread liquidity warning, and resolution-rule risk. No contradiction; description greatly expands on annotations.

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

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

Description is long (approx. 500 words) but well-structured with clear sections. It front-loads the core purpose and then covers response shapes, resolver contract, parent event, news fields, safety, and resolution rules. Every section earns its place given the complexity. Could be slightly more concise, 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?

No output schema, so description must document return fields. It thoroughly covers result.market, result.analysis, result.evidence, market_match_confidence, parent_event, news fields, and all safety/error states (low-confidence, closed, wide-spread). Complete for a complex tool with multiple data sources.

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 three parameters with descriptions. The description adds examples for the 'market' parameter (slug, URL, question text), explains 'depth' enum (quick vs thorough with defaults), and elaborates on 'include_raw' (summarized vs full payloads, size implications, use cases). Adds significant meaning beyond schema.

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

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

Description explicitly states it researches Polymarket bets by pulling Pipeworx data. It specifies the tool resolves market, classifies bet, fans out to data packs, and returns evidence packet. It distinguishes from siblings by focusing on single bet research, unlike polymarket_edges or polymarket_arbitrage. Very specific verb+resource+scope.

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

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

Description provides explicit use cases: 'should I bet on X', 'what does the data say about Y', 'is there edge in Z'. It gives guidance on when to use (research single bet) but does not explicitly contrast with sibling tools or state when not to use. Still, clear and actionable.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive behavior. The description adds detailed behavioral context: for 'company' type, it pulls latest 10-K financials from SEC EDGAR/XBRL with correct fiscal year handling; for 'drug' type, it pulls FAERS adverse-event counts, FDA approvals, and trial counts. Also mentions sorting by primary metric and returning citation URIs.

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

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

The description is a single well-structured paragraph that front-loads the core function with example queries, then details entity types and output. It is concise and every sentence adds value.

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

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

Given the lack of output schema, the description compensates by explaining what is returned (paired data with citation URIs). It also covers the two entity types, their data sources, and the sorting behavior. The description is complete for an AI 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% with descriptions for both 'type' and 'values'. The description enriches these by specifying expected formats (tickers/CIKs for company, drug names for drug) and explaining what data each type retrieves.

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

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

The description clearly states the tool's purpose: side-by-side comparison of 2-5 companies or drugs in a single parallel call. It provides example queries and distinguishes from sequential lookups and sibling tools like entity_profile.

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

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

Explicitly advises to prefer this tool over sequential single-pack lookups when comparing entities. Gives concrete examples like 'X vs Y' and 'rank these companies' to indicate when to use.

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

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

Goes far beyond the readOnly/openWorld/idempotent annotations, detailing the findings packet (verbatim evidence, confidence, source, fetched_at, citation_uri), explicit gaps[] with never-invented behavior, depth-specific hop logic, contradictions[], semantic excerpting, and latency expectations. No contradiction with annotations.

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

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

The description is long and dense, but each sentence adds distinct value: auth, scope, output, usage guidance, depth differences, citation resolution, and latency. It is front-loaded with the most decision-critical facts (account requirement, single-lookup alternative), though it would benefit from tighter paragraphing.

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

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

Despite having no output schema, the description fully characterizes the return packet (evidence, confidence, source, fetched_at, citation_uri, gaps[], contradictions[], hop field), so an agent knows exactly what to expect. Together with auth requirements, per-depth behavior, and latency bounds, nothing needed for correct invocation is missing.

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

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

Schema covers both parameters 100%, including the depth enum semantics and the natural-language question description. The description adds only incidental context (paid plan for thorough) and repeats the schema's depth explanations without introducing new parameter-level meaning.

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

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

States a specific resource and behavior: 'Grounded multi-source research across Pipeworx's 1497 STRUCTURED data sources ... in ONE call', explicitly contrasting with open-web search. Distinguishes from siblings by naming ask_pipeworx as the alternative, and the verb 'decomposes/routes' plus deliverables makes the function 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?

Provides explicit when-to-use ('Best for broad/multi-part questions over structured data') and two clear exclusion routes: single lookups use ask_pipeworx, breaking current-news topics use ask_pipeworx. Also covers the auth fallback ('If you are not signed in, use ask_pipeworx instead'), leaving no ambiguity about alternatives.

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

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

Annotations already indicate safe, read-only, idempotent behavior (readOnlyHint: true, destructiveHint: false, idempotentHint: true). The description adds that results are 'ready to call directly, no second schema lookup needed,' giving useful context on the output format and immediate usability. 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 concise (3 sentences) and front-loaded with the core purpose. It includes examples of valid queries and lists domains efficiently. Every sentence adds value, though it could be slightly more 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?

Given the tool's complexity as a meta-search, the description adequately explains what it returns (top-N tools with schemas and examples) and how to use it (call first for exploration). With no output schema, the description compensates by stating the return structure. It is sufficiently complete for its context.

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

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

Schema coverage is 100% with well-described parameters, including acceptable aliases for 'query'. The description provides example queries but does not add significant meaning beyond what the schema already offers. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states it 'Find tools by describing the data or task', specifying a wide range of domains. It explains the return includes tool names, descriptions, and schemas. While it distinguishes itself from sibling tools as a discovery meta-tool, it does not explicitly contrast with other search-like tools in the list.

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

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

The description provides explicit guidance: 'Call this FIRST when you have many tools available and want to see the option set.' It implies the tool is for browsing and exploration, not for singular answers. However, it lacks explicit 'when not to use' or alternative tools for direct answers.

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. Description adds useful behavioral context: fans out across multiple sources, soft-fails for patents, and describes return structure.

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?

Front-loaded with example queries. Packed with information but every sentence adds value. Slightly long but justified by complexity.

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

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

No output schema, but description comprehensively explains return data (cik, filings, fundamentals, patents, news, LEI) and notes patent API sunset. Covers all relevant details.

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

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

Schema coverage is 100% with descriptions for both parameters. Description reinforces meanings with examples (ticker, CIK) and limitation (names not supported), adding value beyond schema.

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

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

Description clearly states it provides a 'full cross-source profile of a US public company in ONE parallel call', lists specific data types returned, and distinguishes from sibling tool resolve_entity.

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

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

Explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups' for holistic views, and specifies 'use resolve_entity first' when input is a name.

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

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

Annotations already provide destructiveHint and idempotentHint; description adds context about clearing 'sensitive data' and staleness, but doesn't elaborate on error cases or side effects.

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, efficient, and front-loaded with the main action. No unnecessary words.

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

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

Given the simple single-parameter tool with no output schema, the description fully covers purpose, usage, and relationships with siblings.

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

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

Schema coverage is 100%, and the description does not add additional meaning beyond the schema's 'Memory key to delete'. Baseline 3 is appropriate.

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

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

The description clearly states the action 'Delete a previously stored memory by key' with a specific verb and resource, and distinguishes from siblings 'remember' and 'recall'.

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

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

Explicit usage conditions: 'Use when context is stale, the task is done, or you want to clear sensitive data' and mentions pairing with 'remember and recall' for 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, idempotentHint, and openWorldHint, so safety is clear. The description adds process details (fetches page, extracts elements, outputs markdown) and output format, which goes 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?

Four sentences with no fluff: purpose, process, output, use cases. Front-loaded with key action, each sentence adds value.

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

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

Given the tool's simplicity (2 params, no output schema), the description covers all needed context: what it does, how it works, what it produces, and when to use it. No gaps.

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

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

Schema coverage is 100% and adequately describes both parameters. Description adds no new semantic meaning beyond restating the default/max for max_links. Baseline score of 3 applies.

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

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

Clearly states the verb 'generate', resource 'llms.txt file', and scope 'for any URL'. Provides specific use cases that differentiate it from siblings like '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?

Lists three explicit use cases (client's site, own project, competitor audit), giving clear context for when to use. Lacks explicit when-not-to-use or alternative tools, but the examples are informative.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description confirms it is a read operation and adds detail on return format (genre ID, name, TMDb ID). This adds some value beyond annotations but no additional behavioral disclosures.

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 only two sentences with no wasted words. It is front-loaded with the directory concept and efficiently conveys purpose, return values, and usage.

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

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

For a simple tool with no parameters and an output schema, the description fully explains what the tool does, what it returns, and how to use it (with list_titles). No gaps remain.

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 zero parameters, the baseline is 4. The description does not need to explain parameters since none exist, and it already covers the tool's purpose.

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 is a directory of movie and TV genres, lists examples, and specifies the return fields (ID, name, TMDb ID). It also mentions using it to filter list_titles by genre, distinguishing it from sibling tools.

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

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

The description gives an explicit usage context ('Use to filter list_titles by genre') but does not provide when-not-to-use or alternative tools. It implies a single use case without 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, idempotentHint, etc. Description adds return fields and default/optional behavior, enhancing transparency 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?

Two sentences: first defines purpose and output, second gives usage guidance. No wasted words, 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 list tool with one optional parameter and robust annotations, the description fully covers what an agent needs: output fields and when to use.

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

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

Single parameter 'include_inactive' is fully described in schema (100% coverage). Description adds no new meaning beyond schema, so baseline 3.

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

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

Clearly states 'List the caller's active subscriptions' with specific output fields. Distinguishes from siblings like subscribe and unsubscribe.

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

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

Explicitly says when to use: 'review what you're monitoring before adding more or to find an id to cancel'. Could mention alternatives like subscribe but still clear.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral context beyond annotations by mentioning pagination (page + limit) and the range of filtering options, which helps the agent understand 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 a single, well-structured sentence that immediately conveys the core functionality. It is front-loaded with action verbs and keeps content minimal, avoiding redundancy with structured fields.

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 11 parameters and no schema descriptions, the description is too brief. It does not explain how each parameter interacts, default values, or response format (though output schema exists). The agent would lack crucial details for complex queries.

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 description enumerates broad categories of parameters (streaming source, genre, network, type, date range, sort order) but provides no detail on valid values or format for any parameter. With 11 parameters and 0% schema description coverage, the description is insufficient to guide parameter usage effectively.

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

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

The description clearly states the tool's purpose: to browse and filter a title catalog by multiple criteria. It uses specific verbs ('browse', 'filter') and describes the resource ('Watchmode title catalog') and key filtering dimensions, distinguishing it from siblings like 'title_search' which likely handles name-based search.

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

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

The description implies usage for listing and filtering titles but does not explicitly state when to use this tool versus alternatives like 'title_search' or 'releases'. There is no guidance on prerequisites or exclusions, which is a gap given the number of sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful output detail (ID, name, origin country) but no additional behavioral traits beyond that.

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

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

Two sentences, front-loaded with purpose and example, then usage guidance. Every word earns its place.

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

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

Given no parameters and existence of output schema, the description fully covers what the tool does and how to use it within the tool ecosystem.

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?

No parameters exist; schema coverage is 100%. Baseline score of 4 applies as description adds no extra parameter meaning, but none is needed.

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 specifies the tool returns a directory of TV networks with ID, name, and origin country, and distinguishes from sibling list_titles by positioning it as a preparatory step.

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

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

Explicitly states usage context: 'Use as a directory before filtering list_titles by network.' This gives clear when-to-use guidance and hints at workflow integration.

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, providing no safety or side-effect hints. The description compensates by disclosing rate limiting (5 per identifier per day), the claim_token return when no account exists, how to read replies later, that the team reads digests daily, and that it is free. This goes well beyond what annotations convey 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 a single dense paragraph, but every sentence earns its place: purpose, usage rules, exclusions, claim-token flow, rate limits. It is front-loaded with the main verb, though a bulleted layout would improve scanability. The length is justified by the tool's complexity, so no waste.

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

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

Given that there is no output schema, the description adequately explains the return behavior (claim_token), the follow-up mechanism, and the scope of feedback. It covers all four optional parameters implicitly, the exclusion for non-Pipeworx tools, and operational limits. Sufficient for an agent to invoke this tool safely and effectively.

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

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

Schema coverage is 100%, so baseline is 3; the description adds meaningful usage nuance (e.g., 'don't paste the end-user's prompt,' 'describe in terms of Pipeworx tools/packs,' and the claim_token round-trip semantics) that helps agents compose parameters correctly. It doesn't restate schema descriptions but enhances them with real-world guidance.

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

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

The description opens with a specific verb and resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes this tool from all siblings (research, discovery, subscription tools) by positioning it as feedback exclusively for this Pipeworx connection.

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

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

Provides explicit when-to-use categories (bug, feature/data_gap, praise) and an explicit when-not-to-use exclusion: tools from other MCP servers should be reported there. Also explains the claim_token flow for following up, rate limits, and that it doesn't count against quota—excellent alternative/context guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds significant extra context: data source (CF analytics-engine), no PII, cached 5min-1h, and self-aggregating nature. 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?

Five sentences, front-loaded with purpose, followed by use cases and data source details. Every sentence contributes value without redundancy.

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

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

For a read-only tool with one optional parameter and no output schema, the description fully covers what is returned (top tools, top packs, total call volume), caching behavior, and data source. No gaps.

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

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

Schema coverage is 100% with a clear enum description. The description reinforces window semantics and adds 'cached 5min-1h depending on window', providing deeper insight 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 it returns top tools, top packs, and total call volume over a window. The verb 'Returns' and specific resources are explicit, and it is distinct from sibling tools like 'discover_tools' or 'ask_pipeworx'.

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

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

Three specific use cases are listed (discovering hot data sources, confirming canonical choice, seeing alignment). The window parameter's effect is explained ('shorter windows surface what's hot right now'). However, it does not explicitly state when not to use this tool or compare to 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 and idempotentHint=true; description adds rich behavioral context: it performs scans, checks fill depth, filters placeholders, and explains semantic anchors. 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 lengthy but well-structured with clear sections for each mode and response details. Every sentence contributes value, though some repetition exists (e.g., fill check explained twice).

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

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

Despite no output schema, the description fully explains the response structure (opportunities[], partition_check, fill check), failure cases (skipped_low_similarity, placeholders), and trading guidance, making it 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?

Schema coverage is 100% with detailed descriptions; the description adds contextual examples (slugs, seed questions) and explains the effect of each mode, slightly enhancing meaning beyond the schema.

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

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

The description clearly identifies the tool's purpose: finding arbitrage opportunities on Polymarket via monotonicity violations and partition-sum checks. It distinguishes itself from sibling tools by naming specific modes (event, topic) and referencing polymarket_fill_risk for custom sizing.

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 each mode ('event recommended for a specific market', 'topic for cross-event scanning'), when not to trade (realizable_edge_pp ≤ 0), and provides alternatives (polymarket_fill_risk for custom sizing).

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

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

Annotations indicate readOnlyHint, openWorldHint, idempotentHint, and not destructive. The description adds extensive behavioral context: the models used, caching at KV level keyed on knobs, diagnostic information, and details on how edges are computed. There is no contradiction with annotations.

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

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

The description is long but well-structured with clear sections (MODEL_DRIVEN, STRUCTURAL_ARBITRAGE, etc.) and front-loaded with purpose. However, it contains some redundancy and could be more concise.

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

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

Given the tool's complexity (9 parameters, multiple segments, caching, diagnostics), the description is remarkably complete. It explains the response structure, model families, tradeable-edge knobs, caching behavior, and diagnostic output, compensating for the lack of an output schema.

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

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

Schema description coverage is 100%, so each parameter already has a clear description. The tool description does not add significant new information about individual parameters beyond the schema; it provides broader context about the tool's logic.

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 it scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It clearly names the specific resource (Polymarket markets) and action (scan and return opportunities), distinguishing it from sibling tools like polymarket_arbitrage or polymarket_edge_tracker.

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

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

The description explicitly says it is 'built for what should I bet on today' and helps agents discover opportunities without paging hundreds of markets. While it does not list when not to use it or explicitly compare to siblings, the context and sibling list provide alternatives.

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

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds significant detail: it explains data freshness (daily closes, not intraday), TTL bounds (60-day snapshot TTL), and the meaning of expired opportunities (gone from latest snapshot). 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 fairly long but information-dense. Every sentence serves a purpose, and the structure is clear: purpose, arguments, response fields, limitations. It could be slightly more concise, but the level of detail is justified.

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

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

Despite lacking an output schema, the description thoroughly explains the return structure: tracked[] (with fields like first_seen, trend, decay_pp_per_day), expired[] (with lifespan_days), and snapshot_dates[]. It also covers data limits and snapshot availability, leaving no gaps 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%, so the baseline is 3. The description restates the default and clamping for 'days' and the default and options for 'window', but does not add new information 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 explicitly states that the tool provides edge persistence and decay telemetry, answering 'how long has this edge existed and is it shrinking?' It distinguishes itself from sibling 'polymarket_edges' by building on top of its snapshots to track historical behavior.

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

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

The description provides clear context for when this tool is useful (e.g., comparing fresh vs. old edges) but does not explicitly mention alternatives or when not to use it. The guidance is implied through the example, 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 mark safe, idempotent read operation. Description adds critical behavioral details: walking the order-book ladder, returning verdict (clean|degraded|cannot_fill), explaining basket fill risks (thin_legs, forced_directional_risk). No contradiction with annotations.

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

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

Dense and informative, but slightly verbose with all-caps emphasis and run-on sentences. Could be more scannable with bullet points, but front-loaded with purpose and key usage. 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?

No output schema, so description fully enumerates return fields for both modes: top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, verdict, plus basket-specific theoretical_sum, capture_ratio, profit_usd, per-leg detail, thin_legs, max_clean_notional, forced_directional_risk. Complete for the tool's complexity.

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

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

Schema covers all 4 parameters, but description adds deep context: explains side per mode and auto-detection, distinguishes market vs event, details size_usd interpretation (spend vs target proceeds in single, settlement notional in basket). Adds meaning well beyond schema.

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

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

Description opens with a precise verb+resource: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It then distinguishes between single-market and basket modes, and explicitly contrasts with siblings polymarket_arbitrage and polymarket_edges by advising use before acting on their 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?

States explicit usage: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' Provides rationale for when-not-to-skip (theoretical overrun not capturable, partial fills cause directional risk), leaving no ambiguity.

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

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

Annotations declare readOnlyHint=true and these are consistent with a read-only analysis tool, so there is no contradiction. The description goes far beyond the annotations: it discloses that compatibility codes can be non-empty even on returned pairs, that unclassified legs are NEVER paired, that spreads are gross (not net of Kalshi fees), and that temporal_alignment null means 'could not be computed', not 'aligned'. This is exceptionally rich behavioral disclosure.

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

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

The purpose is front-loaded in the first sentence and a clear mode/response/safety structure is visible. However, the description is very long, packing mode explanation, response format, safety codes, skipped-leg logic, fee disclosure, and feasibility warning into dense prose that interleaves topics. Every sentence earns its place — the content is genuinely useful — but the packing makes it harder to parse than it should be.

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 and no required parameters, the description carries the full burden of explaining return values and edge cases — and it does so comprehensively. It covers leg-by-leg prices, top_spreads_pp, compatibility_warning/codes semantics, skipped_unclassified and low_confidence_pairs, temporal_alignment fields, the gross-vs-net fee caveat, and the skipped_cross counters. Nothing an agent needs to interpret results correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds real value on top: it explains that topic picks from 10 pre-mapped shortcuts, that kalshi_event_ticker and polymarket_event_slug override the mapped side, and that both modes feed the identical matcher with the same disclosures. This clarifies the override relationship between topic and the explicit fields beyond bare schema text.

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 states a precise verb and resource: computing the cross-venue spread between Kalshi and Polymarket for the same resolving question. This differentiates it from siblings like polymarket_arbitrage and polymarket_edges, which the title and context confirm are distinct tools, and the description's focus on same-question cross-venue comparison makes its scope 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 explains two modes (topic shortcuts vs explicit ticker/slug pairings), states that both run the identical matcher, and includes a frank feasibility warning that most pre-mapped topics return compatibility_warning today and that pre-mapped ≠ tradeable. This is strong usage guidance, though it never explicitly names sibling alternatives or states when NOT to use this tool versus a pure arbitrage or edge 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 destructiveHint=false, covering safety and idempotency. The description adds valuable context: scoping to user identifier, listing behavior when key is omitted, and the fact that values are stored via 'remember'. This goes beyond what annotations provide.

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

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

Three sentences, each serving a distinct purpose: first sentence defines the action, second explains usage context, third adds scoping and pairing info. No redundant or extraneous text. 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?

For a simple tool with one optional parameter, good annotations, and no output schema, the description covers all necessary aspects: purpose, usage scenario, scoping, and relationship to siblings. The agent has enough information to decide when and how to use it correctly.

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

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

Schema covers the single parameter with 100% coverage, describing its use (omit to list all keys). The description reinforces this and adds that the key is used to retrieve a previously saved value, which is consistent. The baseline is 3 due to full schema coverage, but the description adds extra context (scoping, relationship to remember), justifying 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 starts with a clear verb ('Retrieve' or 'list') and resource (memory values). It explicitly distinguishes itself from sibling tools 'remember' and 'forget' by referencing them, ensuring the agent knows this is for retrieval and 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 states when to use it ('to look up context the agent stored earlier') and includes scoping ('Scoped to your identifier'). It also explains the dual behavior (retrieve with key, list without). While it doesn't explicitly list when not to use it, the pairing with remember/forget provides clear alternatives.

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

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

Annotations declare readOnlyHint=true, but description describes mark_read:true as modifying read status, contradicting read-only intent. Per rules, score is 1 for 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?

Three sentences, front-loaded with main action, every sentence adds value. No waste.

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

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

For a 5-parameter tool with no output schema, the description covers purpose, parameters, side effects, and alternative access. Lacks return format details but that's acceptable.

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%, baseline 3. Description adds value by providing examples for 'type' (e.g., sec_8k), 'since' ISO timestamp format, and explaining mark_read's effect, going beyond schema.

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

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

Description starts with 'Pull fired events from your subscription feed,' clearly stating the verb and resource. It differentiates from sibling tools like 'recent_changes' and 'list_subscriptions' by focusing on fired alerts from a feed.

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

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

States that 'Polls work fine' and provides an alternative REST endpoint for scripts/dashboards, giving clear context for usage. However, it does not explicitly say when not to use this tool vs 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?

Discloses multi-source fan-out, fallback logic, soft-fail for PatentsView, and output structure (grouped changes, count, URIs). No contradiction with annotations (`readOnlyHint`, `idempotentHint`); adds important context beyond them.

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

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

The description packs extensive detail into a single paragraph without waste, and front-loads example queries. Slightly less structured than ideal (could use bullet points for multiple sources), but still concise and effective.

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

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

Given the tool's complexity (multiple external APIs, fallback, soft-fail, multiple output fields) and lack of output schema, the description fully covers what the agent needs: sources, failure modes, return structure, and copy examples.

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

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

Schema coverage is 100%, but description adds meaning: `type` constrained to 'company', `since` explains ISO vs relative formats with examples ('7d', '30d', '1y'), `value` clarifies ticker vs CIK. Every parameter gains clarity.

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

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

Description uses specific verbs ('change feed for a company') and clearly distinguishes from sibling tool `entity_profile` by contrasting dynamic vs static profile. Examples of natural language queries make purpose immediately graspable.

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 (`What's new with X`) and when not to (`use entity_profile instead for static profile`). Also explains fallback behavior (GDELT→GNews) and soft-fail for patents, guiding correct invocation.

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

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

Annotations already declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds value by specifying the return format (2-letter codes) and giving example values, which helps the agent understand the output 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 exceptionally concise with two sentences. The first sentence immediately states the purpose and provides examples; the second gives usage guidance. No unnecessary words.

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

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

Given the tool has no parameters, no required params, and an output schema exists, the description is complete. It explains what the tool returns and how to use it, leaving no gaps in understanding for an agent.

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

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

The tool has no parameters, so the baseline is 4. The description does not need to add parameter information; it instead provides context on how to use the output with other tools, which is helpful.

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

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

The description clearly states the tool lists supported regions/countries for streaming availability and returns 2-letter codes, with concrete examples (US, UK, CA, AU). It implicitly distinguishes itself from sibling tools by explaining its usage with title_sources or list_titles.

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

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

The description explicitly says 'Use to constrain title_sources or list_titles to a region,' providing clear context for when to use the tool. It does not explicitly mention when not to use it or list alternatives, but the guidance is sufficient.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) already cover safety and side effects. The description adds behavioral context by specifying 'recent or upcoming' releases, which is not in annotations. No contradictions.

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

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

Two sentences, front-loaded with purpose then usage. No redundancy. Every sentence contributes value.

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

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

Despite having an output schema, the description does not fully cover the 8 parameters (missing 3). It provides adequate but incomplete guidance for a multi-parameter tool.

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

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

Schema has 0% description coverage, so description must compensate. It explains date range, source_ids, types, regions but omits limit, source_types, regions_pricing. Partial coverage; adds value for some parameters but not all.

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

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

The description clearly states the verb 'Return' and the resource 'releases', and specifies filtering dimensions (date range, source IDs, content type, region). It distinguishes this tool from sibling tools like genres or title_search by focusing on release tracking.

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 advises 'Use to track new additions to services', giving a clear use case. It does not explicitly state when not to use or compare to alternatives, but the context and sibling names provide some differentiation.

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 idempotentHint=true and destructiveHint=false. The description adds valuable context: key-value scoping by identifier, persistent memory for authenticated users, 24-hour retention for anonymous sessions—all beyond what annotations provide.

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

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

The description is appropriately front-loaded with the core purpose, then provides usage context and examples. While slightly lengthy, every sentence adds value without redundancy.

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

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

For a tool with only two parameters and no output schema, the description fully covers purpose, usage, parameter semantics, persistence behavior, and related tools, leaving no obvious gaps.

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

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

Schema coverage is 100%, providing basic descriptions. The description enhances with concrete examples for key (e.g., 'target_ticker') and clarifies value accepts any text, adding meaningful semantic guidance 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 saves data for reuse, provides specific examples of what to store (resolved ticker, target address, etc.), and distinguishes from sibling tools recall and forget.

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

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

Explicitly says "Use when you discover something worth carrying forward" and directs the agent to pair with recall and forget, providing clear when-to-use and alternative 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?

Even though annotations already mark the operation read-only, open-world, idempotent, and non-destructive, the description adds substantial behavior: graceful degradation when GLEIF/OpenFIGI are unavailable, explicit unresolved identifiers, asserting nothing on ambiguous matches and returning figi_candidates, and cascading through multiple lookup endpoints.

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 organized with supported types and concrete examples; every section contributes behavioral guidance. The opening example list is somewhat repetitive and the company parenthetical is heavy, so it is not maximally concise.

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

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

For a tool with no output schema and two parameters, the description is remarkably complete: it covers supported entity types, acceptable input formats, ambiguity handling, unresolved results, enrichment degradation, and why it replaces manual lookups. An agent has enough context to call it correctly.

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

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

Schema coverage is 100%, but the description goes well beyond the schema: it defines exactly what value should contain for a bond issuer versus a full noun phrase, gives ticker/CIK/name/brand examples, and clarifies that an ISIN resolves to the issuing legal entity. This materially reduces misparameterization risk.

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

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

The description opens with concrete user phrasings and states the verb-resource pair clearly: resolve a user-spoken NAME to canonical/official identifiers other tools require as input. It separates itself from entity-profile or lookup siblings by explaining that it produces the identifiers those tools consume, making the tool's 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 gives explicit when-to-use guidance: Use FIRST whenever you have a name but need an ID, and it details supported entity types and accepted input forms. It does not name alternatives or state when not to use this tool, so it stops short of full exclusionary guidance.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds valuable context: it probes each entity with another tool, returns score/confidence/signal density, and mentions that using Anthropic requires an API key. 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?

Two sentences plus a clarifying example; front-loaded with purpose. Every sentence adds value; no redundant or unnecessary text.

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

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

Covers purpose, parameters, return structure (ranked list with score, confidence, signal density), and integrates annotations. Lacks mention of error handling or rate limits, but these are not critical for this tool's usage given its read-only nature.

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

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

Schema description coverage is 100%. The description adds meaning by noting that the first entity is treated as the 'subject' for narrative and rest as competitors, which goes beyond schema. Also explains the relationship between models and _apiKey.

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

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

Description clearly states it compares AI visibility across multiple entities side-by-side, specifying it probes each with ai_visibility_check and returns ranked results. This distinguishes it from siblings like ai_visibility_check (single entity) and compare_entities (likely different comparison).

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

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

Explicitly states use case: 'competitive AI-marketing audits' and provides an example question. It doesn't explicitly say when not to use or list alternatives, but the context is sufficient for an agent to understand appropriate usage.

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

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

Disclosures beyond annotations: partial failure handling with sources_failed, timing note for bundlephobia first measurement (5-30s), and graceful degradation. Annotations already indicate read-only, open-world, idempotent; description adds operational details.

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; front-loads core purpose, then details components, usage, and notes. Slightly long but every sentence adds value. No redundancy.

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

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

Given no output schema, the description fully specifies return fields (summary block, per-advisory detail, links, alternative versions). Covers ecosystem limitation and partial failure behavior. Complete for a multi-source composite tool.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value: examples for scoped packages (@types/node) and default behavior for version ('Defaults to the latest published version when omitted'), which are not in 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 clearly states the tool's purpose: a composite check for npm packages using deps.dev and bundlephobia. It specifically mentions the verb 'check' and resource 'npm package', and distinguishes from any sibling tools by being the only dependency scanning tool.

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

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

Explicit guidance on when to use: 'Use whenever an agent asks 'is X safe / popular / small' or 'what does adding lodash cost me''. Also specifies ecosystem limitations and alternatives: 'NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly.'

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds substantial details: BGE-base-en embeddings, 500-char overlapping windows, 200K char cap with truncation flag, and return of offsets for verification. Goes well beyond annotations.

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

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

The description is a single, well-structured paragraph. Front-loaded with purpose, then usage, then technical details. Every sentence adds value; 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?

Given the simplicity (3 params, no output schema), the description provides complete context: explains return type (passages with offsets, similarity scores), truncation behavior, and pairing strategy. No gaps for an AI agent to misuse.

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

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

Schema coverage is 100%, so baseline is 3. Description does not add significantly to parameter semantics beyond schema; it repeats examples for query but no new constraints or formats.

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

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

The description clearly states the tool performs semantic search inside a fetched record, with concrete examples like SEC 10-K or article. It distinguishes from siblings by mentioning pairing with ask_pipeworx_grounded and emphasizing use for large texts.

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: 'when the record is too big to cram into the prompt.' Provides context on saving context, returning passages, and pairing with ask_pipeworx_grounded. Includes technical details like character cap and truncation.

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

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

Annotations already provide safety hints (readOnly, openWorld, idempotent, non-destructive). The description adds value by detailing the output content (IDs, name, type, regions, logo) and scope (worldwide), which enhances behavioral 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 extremely concise with two sentences: the first states what the tool is, the second gives usage advice. No wasted words, front-loaded, and every sentence earns its place.

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

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

Given zero parameters and an existing output schema, the description fully covers the tool's purpose and usage context. It explains the content of the output and provides a usage scenario, making it complete for a simple directory 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?

There are zero parameters, and schema coverage is trivially 100%. Per guidelines, the baseline for 0 params is 4, and the description adds no unnecessary param info, so a score of 4 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 is a directory of all streaming sources worldwide, listing IDs, name, type, regions, and logo. It distinguishes from related tools by advising use before filtering 'list_titles' by source, though it does not explicitly contrast with the sibling 'title_sources'.

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

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

The description explicitly says to use this tool as a directory before filtering 'list_titles' by source, providing clear usage context. It does not mention alternatives or when not to use, but the guidance is effective for its intended role.

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, including OAuth requirement, always-on feed, delivery channel options, SMS caps, webhook failure auto-disable, and one-time signing secret. No contradictions with annotations.

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

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

The description is concise and front-loaded with the core purpose. It packs substantial detail into a few sentences, though a bit dense; could benefit from light structuring but remains effective.

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

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

The description covers subscription types, delivery channels, prerequisites, and limitations despite lacking an output schema. It explains the return value (subscription ID) adequately for a creation tool.

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

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

With 100% schema coverage, the baseline is 3. The description adds detailed examples and constraints for subscription types and delivery parameters, such as required fields for clinical_trial and verification requirements for SMS, providing meaningful enrichment.

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 creates a proactive monitoring subscription to a live-data event stream and returns the subscription ID. It distinguishes itself from sibling tools like list_subscriptions and unsubscribe by focusing on creation.

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

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

The description specifies the requirement of a Pipeworx OAuth account, implying that anonymous users should not use this tool. It provides context for when to use it (monitoring specific event types) but does not explicitly mention alternatives for other use cases.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, etc. The description enriches this by detailing the output (category-bucketed examples with tool shapes) and that it draws from a live catalog, 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 slightly long but well-structured, front-loading example questions, then purpose, output, and usage. Every sentence is informative; minor redundancy could be trimmed but overall excellent.

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

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

Despite no output schema, the description fully explains the output format (category-bucketed example questions with tool+argument shape). It covers input, usage, and outcome, making it complete for a single-parameter onboarding tool.

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

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

Schema coverage is 100% but description adds significant value: it explains the topic parameter values (e.g., 'finance', 'pharma'), that omitting it gives a full spread, and provides examples of focus areas. This goes beyond the schema's minimal description.

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

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

The description clearly states the tool's purpose as an onboarding entry point that returns category-bucketed example questions with tool+argument shapes. It distinguishes from siblings by specifying this is for initial exploration while other tools like ask_pipeworx and compare_entities handle actual queries or comparisons.

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

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

Explicitly says 'Use this FIRST when you do not yet know what Pipeworx can do for you' and explains optional argument usage (omit for full spread, pass topic to focus). Provides clear when-to-use and how-to-use guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about returned data fields but no new behavioral traits beyond annotations. 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?

Single sentence, 25 words, front-loaded with key action and result. No redundant information.

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

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

For a simple read tool with rich annotations and an output schema, the description covers the essential data returned. It is complete enough for an agent to understand the tool's capability.

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

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

Schema coverage is 0%, so description should explain parameter meaning. It mentions title_id implicitly and append_to_response with 'optionally streaming sources', but does not specify title_id format or append_to_response valid values (e.g., 'sources,seasons' from examples). This leaves ambiguity for 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?

Description clearly states it fetches full metadata for a Watchmode title by title_id, listing key fields. It distinguishes from siblings like title_search and title_sources by focusing on a single title's complete metadata.

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?

Description implies use when you have a title_id and need full metadata, with optional streaming sources. It does not explicitly exclude alternatives, but the purpose is clear enough for an agent to decide.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the behavioral profile. The description adds that it returns Watchmode title IDs, which is useful but not extensive. No behavioral traits beyond annotations are disclosed.

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

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

Two sentences, no redundancy. Purpose and optional parameters are front-loaded. Every sentence adds value.

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

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

The tool has an output schema (not shown), so return values need not be described. The description covers input parameters and purpose. However, it omits details like pagination, multiplicity of results, or ordering, but annotations (openWorldHint) and output schema may compensate.

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 0%, so the description must compensate. It explains that search_value can be a name or ID (with search_field indicating type), and types is optional. However, it does not list allowed values for search_field (e.g., 'title', 'imdb_id', 'tmdb_id') or types, leaving some ambiguity.

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

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

The description clearly states the verb 'Search', the resource 'Watchmode titles', and the scope (by name or ID, with optional type filter). It distinguishes from sibling tools like 'list_titles' which likely retrieves all titles without search.

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

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

The description explains when to use the tool (searching by name/ID, optionally filtering by type), but does not explicitly exclude cases or mention alternatives. However, the context is clear enough for guided use.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about return fields (episode count, season number, year) and a usage hint, which complements the annotations without contradiction.

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

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

The description is two sentences (22 words), front-loading the core function and then providing return details and a usage hint. Every sentence adds value with no redundancy.

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

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

Given the simple tool (one parameter, no nested objects) and the presence of an output schema, the description is complete. It explains what the tool does, when to use it, and what it returns, enabling an agent to invoke it correctly.

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

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

Although schema description coverage is 0%, the single parameter 'title_id' is contextualized in the description as a 'Watchmode TV show ID' and tied to the output of title_search. This compensates for the lack of 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 that the tool returns seasons and episodes for a Watchmode TV show ID, specifying the output fields (episode count, season number, year). It distinguishes itself from siblings like title_search and title_detail by indicating it is used after title_search to enumerate structure.

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

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

The description explicitly advises 'Use after title_search to enumerate a show's structure,' providing clear when-to-use guidance. It does not list alternatives or when-not-to-use, but the advice is sufficient for an agent to decide correctly.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds value by detailing the returned fields (services, regions, type, price).

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

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

Single sentence, front-loaded with purpose, no filler. Efficiently conveys core functionality.

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?

Output schema exists, but description could mention that regions filtering is optional. Still adequate for a tool with few parameters and rich annotations.

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

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

Schema has 0% description coverage; description mentions title_id but does not explain regions format or provide parameter details beyond the example.

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

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

Clearly states the tool returns streaming availability for a title_id, specifying services, regions, type, and price. Distinct from siblings like 'sources' or 'title_detail'.

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?

Implied usage for getting streaming sources of a specific title, but no explicit when-to-use or alternatives compared to similar tools like 'sources'.

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

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

Annotations indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable context: 'The row is deactivated (not deleted) so its historical events stay available via recent_alerts', which explains the non-destructive nature and conflicts with potential assumptions. Ownership enforcement is also disclosed. No contradiction with annotations.

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

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

Two sentences with no redundancy. Every phrase adds essential information (action, ownership, effect on data). 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?

For a simple tool with one required parameter and no output schema, the description is largely complete. It covers the mutation effect, ownership rule, and persistence of historical data. Minor omissions like error handling or idempotency implications are acceptable given 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?

The description does not add information beyond the input schema for the single parameter 'id'. Schema coverage is 100%, so a baseline of 3 is appropriate. The description mentions the id is returned by subscribe, which mirrors the schema's description.

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

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

The description clearly states 'Cancel a subscription by id', with the verb 'Cancel' and resource 'subscription'. It distinguishes itself from sibling tools like 'subscribe' and 'list_subscriptions' by specifying the cancellation action.

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

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

The description states 'Ownership is enforced — you can only cancel your own subscriptions', explicitly specifying when to use (own subscriptions) and when not to use (others' subscriptions). However, it does not name alternative tools for other scenarios, which slightly reduces 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 declare readOnly, openWorld, idempotent, and non-destructive hints, and the description adds substantial behavioral detail beyond that: the meaning of each verdict, the critical caveat that could_not_verify means the check did not happen and must not be treated as evidence, verification_error structure, and the grounded pipeline's verbatim evidence handling. 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 a single dense paragraph but every sentence earns its place: purpose, routing, return values, critical caller warning, and efficiency benefit. It is well-structured with clear sections, though slightly long. No redundant 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 covers the full behavior: what the tool does, when to use it, how it routes claims, what it returns (verdicts, actual value, citation), and critical error semantics. It is complete for an agent to select and invoke correctly, especially alongside 40+ siblings.

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

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

Schema coverage is 100%, but the description adds significant meaning: tolerance_pct overrides the implied tolerance and explicitly recommends values for hallucination detection, and the claim examples clarify the expected input. This goes beyond the schema's basic descriptions, earning a score above the baseline.

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

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

The description uses a specific verb ('verify') and resource ('natural-language claim verification against authoritative sources'), with clear examples of trigger phrases. It distinguishes itself from siblings by explicitly stating it replaces 4–6 sequential calls and details the structured vs grounded pipeline, making its unique 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 states when to use: 'Use whenever the agent needs to check whether something a user said is factually correct,' and provides clear routing rules for company-financial vs. other factual claims. It also implies alternatives by noting it replaces sequential NL parsing, entity resolution, data lookup, and comparison steps, giving strong usage context.

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