Alphafold

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral details: the default model is free, passing '_apiKey' results in BYO-key billing via Anthropic, and the exact return structure per model. This goes beyond the annotations and helps set expectations for side effects (cost) and output format.

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

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

The description is four sentences, each earning its place: the main action, the model default and key requirement, the return format, and the use cases. It is front-loaded with the core verb and has no filler or repetition of schema field names.

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 4 parameters, no output schema, and rich annotations, the description fully compensates: it explains the scoring scale, the per-model response structure, the combined view, default model behavior, and cost implications. There is no missing critical context for an agent to decide whether to invoke this tool and what to expect.

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

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

Schema coverage is 100%, so the baseline is 3. The description enhances the meaning of 'models' by specifying the default ('Workers AI Llama-3.3-70b (free)') and clarifies '_apiKey' with 'BYO key — you pay Anthropic directly', adding cost context not present in the schema. It also explains the practical effect of 'context' (disambiguation), adding value beyond schema descriptions.

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

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

The description opens with a specific verb ('Probe') and resource ('LLMs'), and clearly states the output ('score visibility (0-100) per model'). It unambiguously distinguishes itself from generic query tools by focusing on visibility scoring rather than open-ended Q&A, even though it doesn't name sibling tools.

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

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

The description provides clear context on when to use the tool ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and explains the cost implications of using the Anthropic model. However, it does not explicitly mention when not to use it or name specific alternative tools, stopping short of full exclusions.

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

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

The annotations already declare the tool as read-only, open-world, idempotent, and non-destructive. The description adds context about the nature of the data (sequence-level annotations) but does not disclose any additional behavioral traits, such as potential filters or default behavior, so it stays at a baseline level.

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 brief and contains no wasted words. However, it is a sentence fragment rather than a complete sentence, which slightly reduces its structural quality, but still earns high marks for conciseness.

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

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

For a simple 2-parameter tool with an output schema, the description is adequate but has clear gaps: it lacks an explicit purpose verb and usage guidance. The examples partially compensate, but the tool would benefit from stating that it retrieves annotations for a given qualifier.

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

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

The schema covers 50% of parameters (type has a description, qualifier does not). The description adds meaning by giving examples of annotation types (MUTAGEN, LOW_CONFIDENCE_REGIONS) and the examples show qualifier usage with a UniProt-like ID, but it does not explicitly explain the role of the qualifier parameter.

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

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

The description identifies the resource as 'sequence-level annotations' with examples, but lacks an explicit verb like 'get' or 'list'. The name 'annotations' implies retrieval, and the examples make it clearer, but the purpose is not as directly stated as it could be.

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 offers no guidance on when to use this tool or how it compares to alternatives. The examples imply usage with a qualifier, but there is no explicit context about when to choose this over sibling tools like 'uniprot' or 'entity_profile'.

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

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

Annotations already declare read-only, open-world, and idempotent behavior. The description adds valuable context about routing, argument filling, citation URIs, and tier availability. It does not contradict annotations and goes beyond them by explaining the tool's internal orchestration.

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

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

The description is longer than average but every sentence adds value: usage priority, source coverage, examples, and sibling distinctions. It is front-loaded with the most important instruction and logically organized, though slightly verbose.

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 meta-router tool with no output schema, the description fully covers when to use, examples, alternatives, and expected behavior. It also handles edge cases like breaking news and multi-part questions. Given the tool's complexity, the description is remarkably complete.

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

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

Schema coverage is 100% and all six parameters are aliases for the same question field. The description supplements this by providing concrete example questions and clarifying that the parameter accepts natural language queries, which helps the agent phrase effective 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 clearly states the tool routes questions to 5,358 tools across 1,395 verified sources and returns structured answers with citations. It explicitly contrasts with sibling tools ask_pipeworx_grounded and deep_research, making its unique role 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 opens with 'PREFER OVER WEB SEARCH' and provides detailed criteria, examples, and explicit 'Step up only when needed' guidance for alternatives. It specifies exact query types and scenarios, leaving no ambiguity about when to choose this tool.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds genuinely useful behavioral context: it is a beta with candidate routing improvements that may be enabled live, currently identical to ask_pipeworx, and 'Falls back to nothing — this IS a full working router'. This goes beyond the annotations and provides transparency about variability and completeness.

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

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

The description is four sentences long and packs in beta status, current operational state, usage guidance, and a clarification about fallback. While somewhat dense, every sentence adds value; the parenthetical 'same 5,358 tools, same arguments, same response shape' is redundant with ask_pipeworx but reinforces parity. It is slightly verbose but not wasteful.

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

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

For a single-parameter read-only router with no output schema, the description covers the essential context: purpose, experimental status, usage, and current behavior. It omits explicit return-shape details, but says 'same response shape' as ask_pipeworx, and the sibling tool exists to provide that context. Overall, it is complete enough for 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?

Schema description coverage is 100%: all six parameters (question and its aliases) are documented with descriptions. The tool description adds no new parameter-level semantics beyond stating 'same arguments' as ask_pipeworx, but the schema already fully covers meaning. Per the baseline rule, a score of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly identifies this as a beta version of ask_pipeworx, explicitly stating it is an 'identical universal router' with the same tools, arguments, and response shape, while differentiating it via candidate routing improvements. This distinguishes it from the sibling ask_pipeworx and clarifies its experimental nature.

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

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

The description provides explicit guidance: 'Use it exactly like ask_pipeworx when you want the newest routing', and clarifies that results are compared against the stable router. It also mentions the current state (no active candidate) and that it fully works, implying it can be used as a drop-in experiment. However, it does not explicitly contrast against ask_pipeworx_grounded or state when not to use it, so it falls slightly short of a 5.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds valuable behavioral details beyond this: it returns a structured object with evidence verbatim quotes, confidence, and explicit refusal reasons, and states it uses ONLY the tool result content. It also discloses the extra LLM call cost. No contradiction with annotations.

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

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

The description is dense but every clause earns its place: purpose, routing behavior, return format, refusal reasons, use cases, and cost trade-off. It is front-loaded with the core purpose and structured logically. No 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?

Despite having no output schema, the description fully specifies the return shape and refusal reasons. It also covers when to use, when not to use, and the relationship to ask_pipeworx. Given the tool's complexity (routing across 5,358 tools), this is exceptionally complete.

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

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

Schema description coverage is 100% and the parameter descriptions are complete (all aliases for question). The description does not add new parameter-level semantics beyond what the schema already provides. With full schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states this is a 'Hallucination-resistant answer mode for high-stakes reads' and explains that it extracts answers using only tool result content. It distinguishes from the sibling ask_pipeworx by noting the same routing but grounded extraction, so the agent knows exactly what this tool does differently.

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.' Also provides an exclusion: 'prefer ask_pipeworx for casual lookups' and explains the trade-off (extra LLM call). This is model 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 no destructive action. The description goes far beyond these by detailing the resolver contract, blocking statuses (low_confidence_match, market_closed_or_inactive), spread warnings, news fallback mechanisms, and cancellation rule risk. This is exemplary transparency for a complex tool.

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

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

The description is lengthy, but it is well-structured with capitalized section headers and front-loaded with the core purpose. Each section (RESOLVER CONTRACT, PARENT_EVENT, SAFETY, etc.) adds substantive information necessary for correct usage. While it could be condensed, the complexity of the tool warrants the detail.

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

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

With no output schema, the description takes full responsibility for explaining the return value structure. It covers result.market, result.analysis, result.evidence, the resolver contract, parent event extraction, news fields, safety statuses, and cancellation rule risk. This is thorough and complete for a tool of this complexity.

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

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

Schema description coverage is 100%, so the schema fully documents market, depth, and include_raw. The description adds crucial context for the 'market' parameter by explaining the resolver contract (market_match_confidence, score, alternatives, suggestions) and how different input formats are resolved. This goes beyond the schema's basic type/description, 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 begins with a specific verb+resource: 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call.' It clearly distinguishes from sibling tools by stating the exact use cases: 'should I bet on X', 'what does the data say about Y', or 'is there edge in Z'. This is precise and 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?

Explicit usage contexts are provided ('Use for...'), and the fan-out examples illustrate appropriate scenarios for different bet types. However, it does not explicitly mention when not to use the tool or name alternative sibling tools for similar tasks, so it falls short of a 5.

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

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

Annotations already indicate readOnly, openWorld, idempotent, and non-destructive. The description goes further by disclosing data sources (SEC EDGAR/XBRL for companies, FAERS for drugs), fiscal-year handling ('AAPL Sep, NVDA Jan'), sorting behavior ('sorted by primary metric so 'largest'/'most'/'biggest' reads off the top'), and the return of citation URIs. These traits are not derivable from annotations alone, making the description highly transparent.

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-organized, front-loading trigger phrases and the core parallel-call benefit. Every sentence adds value, from data-source details to off-calendar fiscal year handling. It is longer than the TDQS 4.3 baseline, but the added length is justified by the tool's complexity (two entity types, distinct data sources). A slight structural improvement (e.g., separating trigger phrases from data details) would make it more scannable, but it remains concise relative to the information conveyed.

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

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

For a tool with no output schema, the description covers the essential return behavior: 'Returns paired data + pipeworx:// citation URIs per entity.' It also covers data provenance, sorting, and performance benefits. Gaps remain: it does not mention error handling (e.g., invalid tickers), whether drug names must be brand or generic, or limitations like only US SEC filings. These are minor omissions given the description's overall richness, but they prevent a perfect score.

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

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

The schema already describes parameters with 100% coverage (type enum and values min/max/example). The description adds substantial meaning beyond this: it explains what 'type=company' retrieves (latest 10-K revenue + net income + cash + long-term debt) and what 'type=drug' retrieves (FAERS adverse-event counts, FDA approval counts, active trial counts). It also clarifies that values map to tickers/CIKs for companies and names for drugs, enriching the schema 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 a specific action: 'side-by-side comparison of 2–5 companies or drugs in ONE parallel call.' It lists concrete trigger phrases like 'X vs Y' and 'which is bigger / better / larger / more profitable,' and differentiates from siblings by emphasizing it replaces 8–15 sequential lookups and should be preferred over single-pack lookups. The verb+resource+scope are explicit and unambiguous.

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

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

The description provides explicit usage guidance: it lists trigger phrases ('Compare X and Y', 'X vs Y', 'rank these companies', etc.) and states 'ALWAYS PREFER over sequential single-pack lookups when comparing entities.' This clearly tells the agent when to use this tool over alternatives (e.g., entity_profile or sequential calls). It also clarifies which entity types are supported and what data each type returns.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint, destructiveHint), the description discloses critical behavior: account/payment requirements, expected latency (15-90s), the return packet structure (verbatim evidence, confidence, source, citation, gaps[]), never-invented behavior, contradictions scanning, and the explicit note that it is NOT open-web search. This is far richer than the annotations alone and sets clear expectations.

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

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

The description is dense but front-loaded with the most critical caveat (account requirement) and includes all essential information. Some points are repeated (e.g., 'not open-web search' and 'structured catalog' appear more than once), but given the tool's complexity, the length is justified. It earns a 4, not a 5, due to slight 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?

Despite the absence of an output schema, the description fully explains the return format (findings packet with evidence, confidence, source, fetched_at, citation, gaps[], contradictions[], hop field), how the tool decomposes and routes, its limitations (empty gaps for non-catalog topics), and performance expectations. It also gives example questions and clearly states what the tool does not do. This is exceptionally complete for a complex tool.

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

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

The input schema already provides 100% coverage for both parameters, but the description adds meaningful context: 'question' is explicitly stated to support broad/multi-part input ('decomposition is the point'), and the `depth` parameter is elaborated beyond the enum text with details about gap-recovery hops, iteration, and contradictions at standard/thorough levels. This adds value over the schema while not being essential for basic understanding.

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

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

The description uses a specific verb ('research') and resource ('Pipeworx's 1395 STRUCTURED data sources'), clearly distinguishing it from open-web search and sibling ask_pipeworx for single lookups. It states it is best for broad/multi-part questions over structured data and provides concrete example questions, making its 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 provides when-to-use and when-not-to-use guidance: 'If you are not signed in, use ask_pipeworx instead', 'For a single lookup use ask_pipeworx', and 'For BREAKING or colloquial CURRENT-NEWS topics, prefer ask_pipeworx'. It also explains prerequisites (account, paid plan for thorough) and gives example use cases, 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 convey read-only and idempotent behavior. The description adds valuable behavioral context: it returns top-N tools with names, descriptions, and full input schemas, and each result is ready to call directly without a second lookup. This goes beyond annotations by explaining the return format and workflow, though it doesn't mention rate limits or edge cases.

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

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

The description is dense and front-loaded with the core purpose ('Find tools by describing the data or task'), followed by when to use and what to expect. The lengthy domain list is useful but somewhat verbose; still, every sentence earns its place and there is no fluff. It's efficient but not as lean as the two-sentence ideal.

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

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

For a discovery tool with no output schema, the description is complete: it explains the return value (top-N tools with names, descriptions, schemas, curated examples), the workflow ('ready to call directly, no second schema lookup needed'), and the intended use case. This suffices for an agent to understand what to do before and after calling 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 description coverage is 100%, so the baseline is 3. The description does not add much beyond the schema—the examples in the description ('analyze housing market trends', 'look up FDA drug approvals') are already present in the schema's examples and query description. The alias information is also duplicated from the schema. No new parameter semantics are introduced.

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

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

The description clearly states the tool's purpose with a specific verb+resource: 'Find tools by describing the data or task.' It enumerates many domains (SEC filings, financials, FDA drugs, etc.), making its scope unmistakable. It also differentiates itself from sibling tools by framing itself as the discovery layer before using specific tools.

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

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

It gives explicit usage guidance: 'Use when you need to browse, search, look up, or discover what tools exist' and 'Call this FIRST when you have many tools available.' This specifies when to invoke the tool and implicitly when not to (when you already know which tool to use).

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

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

Beyond the annotation-readOnly/openWorld/idempotent/destructive, the description discloses the multi-source fan-out, specific return fields, fallback behavior (GDELT→GNews), API sunset soft-fail for patents, and the CIK zero-padding requirement. These are valuable runtime traits not captured in 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 efficiently organized: user-intent examples first, a directive, then return-field breakdown. Every sentence adds actionable information (sources, limits, fallbacks, constraints). No filler or repetition.

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

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

Given the tool's complexity (multi-source aggregation) and the absence of an output schema, the description provides a detailed inventory of returned data (cik, company_name, recent_filings with URIs, fundamentals with sort order, patents, news, LEI). It also covers edge cases like API sunset and name rejection, making it adequately complete for an agent.

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

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

While the input schema already describes both parameters (100% coverage), the description adds crucial semantics: acceptable formats ('AAPL' or zero-padded CIK), the explicit exclusion of names, and the hint to use resolve_entity for name lookup. This extra context helps the agent avoid failed invocations.

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

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

The description clearly states the tool's purpose with a specific verb phrase ('full cross-source profile of a US public company in ONE parallel call') and provides numerous example user intents. It distinguishes itself from sibling tools by positioning as a holistic alternative to chaining single-source lookups.

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

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

Explicit guidance is given: 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view.' It also names the prerequisite for name inputs: 'names not supported (use resolve_entity first if you only have 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 declare destructiveHint=true and idempotentHint=true, and the description aligns with these. The description adds context about clearing sensitive data and that the memory was 'previously stored,' but it does not discuss side effects, reversibility, or behavior for non-existent keys. With annotations covering the safety profile, this is adequate but not deeply transparent.

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 short sentences, each earning its place: the core action, the usage guidance, and the sibling relationship. The description is front-loaded with the primary purpose and contains no fluff or redundant information. Conciseness and structure are exemplary.

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

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

The tool is simple (one parameter, no output schema), and the description provides enough context: what it does, when to use it, and related tools. Annotations cover idempotency and destructiveness. Minor gap: no mention of what happens if the key does not exist, but the idempotentHint partially addresses this. Overall, 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 description coverage is 100%, with the 'key' parameter already described as 'Memory key to delete.' The description adds no new parameter-level semantics beyond the schema, only confirming the deletion is by key. Baseline for high schema coverage is 3, which is appropriate here.

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

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

The description states a specific verb ('Delete'), a resource ('previously stored memory'), and a method ('by key'). This clearly distinguishes it from siblings like remember and recall, which store and retrieve memories respectively. The title 'Forget' aligns with the description, reinforcing purpose.

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

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

Explicitly lists when to use: context is stale, task is done, or clearing sensitive data. This provides clear conditions for invocation. Additionally, 'Pair with remember and recall' guides tool selection by showing how this tool fits into the memory workflow, though it does not say when not to use, the positive guidance is strong and specific.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds context by explaining the fetch/extract/emit process and output format, which is beyond the annotations. It does not mention failure modes or rate limits, but annotations cover the safety profile.

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

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

The description is concise: two sentences with clear front-loading of the purpose, followed by process details and use cases. Every sentence adds value, and there is zero waste or repetition.

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

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

For a simple URL-fetch and text-generation tool, the description is quite complete: it explains the input, process, output format, and intended uses. It omits edge-case behavior (e.g., invalid URLs, timeout handling), but given the absence of an output schema, it adequately describes the return value as a text blob.

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

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

Schema description coverage is 100%, so the schema fully documents both 'url' and 'max_links'. The description adds context by mentioning 'link entries' and 'key links', but does not meaningfully elaborate on parameter semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description uses specific language: 'Generate a production-ready llms.txt file for any URL' and details the process and output format. It clearly distinguishes the tool from sibling tools like scan_competitor_ai_presence or ai_visibility_check by focusing on creating a file rather than scanning or checking 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?

Provides explicit use cases ('Useful for: getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing how an AI crawler would see a competitor'), giving clear context for when to use. However, it does not explicitly state when not to use or name alternative tools, so it lacks 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=true and idempotentHint=true, but the description adds behavioral context by specifying the default scope (active subscriptions, with include_inactive false implied) and listing the returned fields. This supplements the safety profile without contradicting it.

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

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

The description is two sentences: the first states the action and return values, the second provides usage guidance. It is front-loaded with the verb and resource, contains zero fluff, and 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 the tool's low complexity (one optional parameter, no output schema), the description fully covers the tool's purpose, return payload, and practical use cases. It gives the agent everything needed to decide when and how to invoke it.

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

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

The input schema fully documents the single parameter include_inactive with a clear description, so the schema carries the semantic load. The description does not add any parameter-specific details beyond what the schema already provides, meriting the baseline score of 3.

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

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

The description uses a specific verb 'List' and identifies the resource as 'the caller's active subscriptions,' clearly distinguishing it from sibling tools like subscribe and unsubscribe. It also enumerates the exact return fields (id, type, params, created_at, last_fired_at, fire_count), making the tool's function unambiguous.

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

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

The description provides clear user context: 'Use this to review what you're monitoring before adding more or to find an id to cancel.' This indicates when the tool is appropriate, but it does not explicitly state when not to use it or mention alternatives, so it falls just short of the highest tier.

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, so the description carries the full burden. It reveals important behavioral traits: rate-limited to 5 per identifier per day, free, does not count against tool-call quota, and that the team reads digests daily with signal impacting roadmap. 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?

Every sentence earns its place: purpose, usage conditions, message framing guidance, and operational constraints (rate limit, cost). The structure is front-loaded and no filler exists.

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 (nested context object, enum, no output schema, all-false annotations), the description is remarkably complete. It covers when, how, what to include, constraints, and behavior, leaving little ambiguity for an agent selecting or invoking it.

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%, giving each parameter clear descriptions (type enum, message max length, context object). The description adds extra semantic guidance by insisting the issue be framed in terms of Pipeworx tools/packs and forbidding pasting end-user prompts, which goes slightly beyond the schema.

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

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

The description opens with a specific verb+resource: 'Tell the Pipeworx team something is broken, missing, or needs to exist.' It clearly distinguishes this feedback tool from sibling research/query tools by focusing on reporting issues directly to the team.

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 when a tool returns wrong/stale data, when a tool you wish existed isn't in the catalog, or when something worked surprisingly well'), provides a key exclusion ('don't paste the end-user's prompt'), and mentions rate limits. This is exemplary guidance.

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

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

Beyond the readOnlyHint and other annotations, the description adds valuable behavioral context: it explains the data source (CF analytics-engine), confirms no PII is involved, specifies the data shape (pack, tool, count), and discloses caching behavior (5min-1h depending on window). This goes above and beyond the 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 well-structured and front-loaded: it states the core function first, then provides a clear bulleted list of use cases, and finishes with concise transparency notes. Every sentence adds value, and the length is appropriate for the tool's complexity.

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

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

For a tool with one optional parameter, strong annotations, and no output schema, the description is complete. It covers return values, data source, privacy, and caching. The description alone is sufficient for an agent to understand the tool's behavior and output.

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

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

The schema already fully describes the single 'window' parameter with enum values and behavioral notes (short vs long windows). The description merely mentions the window options without adding new semantic meaning, so a baseline score of 3 is appropriate given the 100% 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 the tool's function: it returns top tools, top packs, and total call volume over a recent window, based on what other AI agents are calling. The verb 'Returns' is specific, the resource is well-defined, and it distinguishes itself from sibling tools like discover_tools by focusing on trending/aggregated call data.

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

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

The description explicitly lists three concrete use cases (discovering hot data sources, confirming canonical tool choice, aligning use case with agent needs). This provides clear guidance on when to use the tool, effectively distinguishing it from 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 readOnly/openWorld/idempotent, and the description adds extensive behavioral context beyond that: output fields, partition placeholder filtering, similarity thresholds, and fill-check logic that warns not to trade when realizable edge is non-positive. 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?

Although long, the description is organized into labeled sections (SEMANTIC ANCHOR, PARTITION FILTER, FILL CHECK) and every sentence carries operational detail. It is front-loaded with the core purpose and enhances scannability.

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 the description enumerates response fields, includes edge-case behavior (placeholder filter, similarity rejection), and explains how the fill check refines signals. It is complete for a complex tool with two optional parameters.

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

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

The input schema already documents both parameters well (100% coverage), and the description further clarifies semantics with concrete slug examples, mode-specific behavior, and the no-arg default. It adds meaning about how each parameter changes the scan scope and checks performed.

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: 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks.' It clearly defines the tool's scope and distinguishes modes (trending scan, event-specific, topic cross-event), differentiating it from sibling tools like polymarket_fill_risk.

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

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

Explicit usage instructions are provided: 'Call with NO args for a trending_scan', 'pass event for the strongest per-event partition_check', or 'topic for a themed cross-event scan.' It also names an alternative for custom sizing (polymarket_fill_risk), satisfying when-to-use and alternative guidance.

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

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

The description adds extensive behavioral context beyond the annotations: it details the three response segments, explains tradeable-edge knobs, discloses the 1-hour KV caching keyed on knobs, warns when a 24h move already exceeds the edge, and describes diagnostics for empty segments. These specifics go well beyond the readOnlyHint/openWorldHint 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, CONCENTRATED_LONGSHOT, TRADEABLE-EDGE KNOBS, RESPONSE TOP-LEVEL). Every sentence adds necessary detail for a complex tool with 9 parameters and no output schema. It is appropriately dense without being 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?

Given the tool's complexity (9 parameters, deep response structure, no output schema), the description is exhaustive. It covers model families, segment groupings, diagnostics, caching, and edge-case warning behavior. A caller would know exactly what results to expect and how to interpret them.

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

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

The schema already documents all 9 parameters with 100% coverage, setting a baseline of 3. The description adds valuable semantics beyond the schema, such as the interplay between min_kelly and min_partition_leg_kelly (partition arbs always return kelly_fraction_half=0 at parent level), and the explanation of tradeable-edge knobs. This elevates it to 4.

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

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

The description opens with a specific verb+resource+outcome: 'Scan top Polymarket markets and return opportunities where Pipeworx data disagrees with market price.' This clearly differentiates it from sibling tools like polymarket_arbitrage or polymarket_edge_tracker by focusing on data disagreement and opportunity discovery for daily betting.

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 the intended use case: 'Built for "what should I bet on today" — agents discover opportunities without paging hundreds of markets.' It also gives contextual hints like Fed bets being excluded from ranking and explains knob behavior. However, it doesn't explicitly mention alternative tools or when not to use it.

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

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

Even though annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, the description adds significant behavioral context: snapshot TTL limits, cache-miss writing, gaps in snapshot dates, decay computation from daily closes net of slippage, and median lifespan as a competition clock. It explains the meaning of expired opportunities and the implications of snapshot gaps, going far beyond what annotations provide.

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

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

The description is dense but well-structured with clear sections: purpose, args, response fields, and limits. Every sentence carries essential information, from the philosophical rationale to technical details about TTL and intraday calculation. It is front-loaded with the main question and quickly moves into actionable details 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?

Despite having no output schema, the description fully specifies the response structure: tracked[] with edge_pp_net time-series, first_seen, trend, decay_pp_per_day; expired[] with lifespan_days; snapshot_dates[]. It also addresses data freshness, TTL limits, and computation basis. This is comprehensive for a read-only telemetry tool with two simple parameters.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'Args' section mostly repeats the schema: days default 14 and window default '1wk'. It adds minor context like 'lookback' and 'snapshot family', but these are already conveyed in the schema descriptions. No meaningful new semantics are added beyond the schema.

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

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

The description opens with a specific verb and resource: 'Edge persistence and decay telemetry built from daily polymarket_edges snapshots.' It clearly states the tool answers 'how long has this edge existed and is it shrinking?' which precisely differentiates it from sibling tools like polymarket_edges that likely provide current edges. The purpose is unique and unambiguous.

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

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

The description provides strong contextual guidance by explaining the difference between fresh and old wide edges and outlining the tool's role in deciding trade viability. However, it does not explicitly name alternative tools or state when not to use this tool. The usage context is clear but lacks explicit exclusions or direct sibling comparisons.

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 state readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral detail: it 'walks the ladder', returns specific fields like top_of_book and slippage_pp, identifies thin_legs and forced_directional_risk, and warns that partial basket fills leave the user unhedged. This far exceeds the annotation-provided safety profile.

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

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

The description is long, but it is well-structured with capitalized mode headers and front-loaded purpose. Every sentence provides necessary detail for a complex analysis tool. It could be more compact, but no sentence is wasted; it earns its length.

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

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

Since there is no output schema, the description must explain return values. It lists all key outputs for single-market and basket modes, discusses edge cases (thin books, partial fills, cannot_fill verdict), and explains the dominant loss mode. This is thoroughly complete for a tool of this complexity.

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

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

The input schema covers 100% of parameters, so the baseline is 3. The description adds meaning by explaining how size_usd is interpreted differently in single-market vs basket mode and how side selects overround vs underround in basket mode. It also clarifies default behavior for side with 'default auto from partition sum', slightly enriching the schema.

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

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

The description opens with a specific verb+resource: 'Realizable-vs-theoretical edge check against live CLOB order-book depth.' It clearly distinguishes between single-market and basket modes and explicitly references sibling tools (polymarket_arbitrage, polymarket_edges), so there is no ambiguity about what this tool does or how it differs.

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

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

The description provides explicit usage context: 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500.' It names the exact preceding tools and gives a threshold, and it explains why (thin books, partial fills converting arb into directional risk). This is clear when-to-use guidance with 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 readOnly, openWorld, idempotent, and non-destructive behavior. The description adds substantial context beyond those: it defines the compatibility_warning (with two distinct cases), explains temporal_alignment and why aligned:false makes spreads meaningless, and describes skipped_cross_type/subtype counters. It also warns that the tool may return no matched pairs even when both venues have many legs. This far exceeds the annotation baseline.

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

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

The description is long but well-structured with bold section labels (TWO MODES, RESPONSE, SAFETY FIELDS) and front-loaded with the core purpose. Each sentence carries meaningful caveats or explanations; there is minimal redundancy with the schema. It earns a 4 rather than 5 because it is quite verbose and could be slightly tightened without losing critical information.

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

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

Given the tool's complexity (3 optional params, no output schema), the description is exceptionally complete. It describes the response structure (leg-by-leg prices, spread.top_spreads_pp) and all safety fields, including compatibility_warning conditions and temporal_alignment. It also sets realistic expectations about the rarity of real cross-venue spreads. This handles the lack of an output schema thoroughly.

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 the schema provides 100% coverage with descriptions for the three parameters, the tool description adds significant meaning by explaining the two modes and how 'topic' shortcuts map to venue events, and that kalshi_event_ticker and polymarket_event_slug override the topic-mapped sides. It also clarifies the semantics of the pre-mapped topic list. This goes well beyond the schema's bare descriptions, so the extra credit is warranted.

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

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

The description opens with a specific verb+resource: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It clearly distinguishes this from sibling tools (e.g., polymarket_arbitrage focuses on arbitrage, presumably within or across other venues) by defining the comparison scope and outcome. The two modes and the explicit topic list further sharpen the tool's purpose.

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

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

The description gives clear when-to-use guidance for each mode ('topic' auto-fetches pre-mapped macros, explicit mode for custom pairings) and provides a strong when-not-to-trust warning: 'most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.' However, it does not explicitly name any alternative tool to use instead, so while the usage context is excellent, the exclusion/alternative dimension is not fully covered.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds that it provides 'full' metadata and specifically PDB, CIF, and PAE URLs, which goes slightly beyond the annotations. However, it does not disclose any other behavioral traits such as potential rate limits or whether certain parameters could return empty results. This is adequate given the simplicity and annotation coverage.

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

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

The description is a single, concise sentence that front-loads the key output types (metadata and structure URLs). It is efficient and avoids unnecessary words, though the word 'full' is arguably redundant. It could have provided slightly more structure by naming the tool's action, but it remains appropriately brief.

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 parameter set and the presence of an output schema, the description is minimally viable. It tells the agent what to expect (metadata and URLs) but does not explain the context (e.g., that these are protein structure predictions from AlphaFold) or when such data would be useful. The output schema likely provides the return structure, so the description is adequate but leaves room for more context.

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

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

The input schema has 100% coverage for the single parameter 'qualifier', which is described as a UniProt accession. The description does not add any additional meaning about the parameter beyond what the schema already provides. With high schema coverage, the baseline of 3 applies, and the description adds no extra value here.

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

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

The description states it provides 'Full prediction metadata + structure file URLs (PDB, CIF, PAE)', which clearly identifies the resource (protein structure prediction data) and the outputs (metadata and structure file URLs). However, it lacks an explicit verb like 'retrieve' or 'get', making it slightly less action-oriented than ideal. It does distinguish from siblings like 'uniprot' by focusing on prediction-specific data.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention that it should be used for protein structure prediction tasks or that other tools like 'uniprot' should be used for sequence information. The description is purely a data summary and offers no contextual usage instructions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond this: scoping to the agent's identifier (anonymous IP, BYO key hash, or account ID) and the dual-mode behavior (omit key to list all keys).

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

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

The description is three sentences long and front-loaded: the first sentence states the core action, the second gives usage context, and the third explains scoping and companion tools. Every sentence earns its place with no redundancy.

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

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

For a simple one-parameter read tool with rich annotations and full schema coverage, the description covers purpose, usage, scoping, and sibling relationships. No output schema exists, but the return value (retrieved value or list of keys) is implicit. The description is complete for its 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?

The input schema already fully describes the only parameter (key) with the same 'omit to list all keys' behavior, giving 100% schema coverage. The description reiterates this but adds no new parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves a previously saved value or lists all saved keys, using a specific verb ('Retrieve') and resource ('value previously saved via remember'). It distinguishes itself from siblings 'remember' (save) and 'forget' (delete) by positioning recall as the lookup operation.

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

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

It explicitly says 'Use to look up context the agent stored earlier' and gives concrete examples (target ticker, address, research notes). It also mentions pairing with 'remember' to save and 'forget' to delete, implying when not to use recall and naming alternatives.

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

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

Beyond annotations that already declare readOnly/idempotent, the description explains the mark_read side effect (flagging events so next call only shows newer ones), the return payload structure, and the same feed's external URL. This adds substantial 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?

Three sentences, front-loaded with the core purpose, and every sentence contributes a distinct fact. No filler or redundancy.

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

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

Despite no output schema, the description explains return fields (source, citation_uri, raw payload) and covers the main usage scenarios: filtering, pagination via mark_read, and external access. It is complete for a 5-parameter tool with zero required parameters.

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

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

Schema has 100% parameter coverage, so baseline is 3. The description adds value by explaining the type filter with an example ('sec_8k'), the since parameter as ISO timestamp, and the mark_read semantics. It does not mention limit or unread_only, but those are already well-described in the schema.

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

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

The description begins with a specific verb-resource pair: "Pull fired events from your subscription feed." It clearly identifies the tool's function and differentiates it from siblings like list_subscriptions and recent_changes by focusing on subscription event alerts.

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

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

Provides clear context: filters by type/since, mark_read behavior for incremental polling, and that polling works fine. It also mentions an external HTTP alternative for scripts/dashboards. However, it does not explicitly name sibling tools for comparison, so it misses the top score.

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

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

Beyond the annotations (read-only, idempotent), the description discloses detailed behavior: it fans out in parallel to multiple sources, explains the GDELT→GNews fallback for rate limits or 5xx errors, notes the USPTO soft-fail due to PatentsView API sunset, and specifies the return structure (changes[], total_changes, pipeworx:// citation URIs). This provides rich behavioral context that annotations alone do not cover.

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

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

The description is front-loaded with purpose and example queries, then efficiently covers sources, parameter semantics, return structure, and alternative usage in a compact, dense format. Every sentence earns its place, providing essential information without 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?

The description is highly complete for a complex multi-source tool: it explains the fan-out behavior, fallback logic, accepted `since` formats, return structure, and the alternative entity_profile. However, it does not break down the fields inside `changes[]` or address edge cases like unknown entities, which would be valuable given the lack of an output schema. Still, it provides enough for an agent to invoke and interpret results correctly.

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

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

The input schema already provides complete descriptions for all three parameters (type enum, value examples, since format and examples) with 100% coverage. The tool description largely reiterates these details, adding only minor context like connecting `since` to the SEC filings window. Since schema coverage is high, the baseline of 3 applies.

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

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

The description explicitly states the tool's function as a 'change feed for a company in the last N days/weeks/months' and provides example queries like 'What's new with X' and 'updates on Acme.' It lists the data sources (SEC EDGAR, GDELT→GNews, USPTO) and distinguishes itself from the sibling tool entity_profile, making its purpose unmistakable.

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

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

The description gives clear when-to-use guidance by directing users to 'Use entity_profile instead when you want the static profile...' and recommends typical monitoring windows ('Use "30d" or "1m" for typical monitoring'). It also frames this tool as the right choice for time-boxed updates, contrasting with static profile needs.

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

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

Adds scoping by identifier and auth-dependent retention (24h vs persistent), beyond annotations. Could mention overwrite behavior but idempotentHint already implies it.

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 purpose, examples, and pairings — 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?

Complete for a simple 2-param, no-output tool; covers persistence, scope, and sibling integration.

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 params 100% with clear descriptions; description adds the key-value framing but no significant extra meaning.

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

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

The description states a specific action ('Save data') with a clear resource (key-value memory), and distinguishes it from siblings by mentioning 'recall' and 'forget' pairings.

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 'Use when' clause with concrete examples (resolved ticker, target address) and references to alternatives (recall, forget).

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond annotations: it discloses internal cascading through multiple endpoints, auto-disambiguation, and the citation URIs returned. This enriches the agent's understanding of what happens during execution and what the response contains.

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

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

The description is longer than average but every segment earns its place: example queries, supported types, return details, and usage guidance. It is front-loaded with user-perspective examples, though the density could overwhelm some agents. Slightly trimmed wording could make it a 5, but it remains 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?

The tool has two entity types with distinct input/output needs and no output schema. The description fully covers these: it specifies the exact inputs for each type, the returned identifiers, citation URIs, and the internal cascade. This is sufficient for an agent to invoke the tool correctly without needing additional documentation.

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

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

Schema coverage is 100%, so the baseline is 3. The description surpasses the schema by explaining the meaning of type and value in context (e.g., what 'company' returns, accepted input forms like ticker or CIK, and the promise of auto-disambiguation). It adds practical semantics beyond the schema's enum and generic 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 verb ('resolve') and resource ('user-spoken NAME to the canonical/official identifier'), with explicit examples of user queries. It differentiates from siblings by positioning itself as the FIRST step when an ID is needed, and provides concrete return details (ticker, CIK, RxCUI) that distinguish it from profile or comparison 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 explicit usage context: 'Use FIRST whenever you have a name but need an ID.' It also lists supported entity types and input formats, which helps the agent decide when to invoke. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

Beyond the annotations (readOnly, idempotent, openWorld), the description discloses that the tool calls ai_visibility_check for each entity, ranks results by score, and returns score/confidence/signal density. This is substantial behavioral detail that helps the agent predict side effects and output shape.

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

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

Three sentences, front-loaded with the primary action, then the mechanics, then a concrete use case. Every sentence contributes without redundancy or unnecessary verbosity.

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

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

With no output schema, the description compensates by explicitly stating the return format (ranked list with score, confidence, signal density). It also covers the internal probe call and the typical scenario (brand + competitors). Combined with strong annotations, the description is fully adequate 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?

The input schema already covers all parameters with descriptions, so the baseline is 3. The description adds value by explaining that the first entity is treated as the 'subject' for narrative framing and the rest as competitors, which is not in the schema. This extra semantic context justifies a 4.

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

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

The description explicitly states the tool compares AI visibility across multiple entities side-by-side, distinguishing it from the sibling ai_visibility_check which focuses on a single entity. It names the key resource (AI visibility) and the operation (compare/probe/rank), making the purpose unmistakable.

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

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

The description gives a clear use case ('competitive AI-marketing audits') and implicitly contrasts with the single-entity ai_visibility_check by saying it probes each entity with that tool. However, it does not explicitly state when not to use this tool or name an alternative for single-entity checks, so it falls short of a 5.

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

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

Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), the description adds substantial behavioral context: composite fan-out across two services, partial failure degradation, a potential 5-30s latency on first measurement, and the sources_failed field. This is material behavior not captured by annotations.

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

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

The description is longer than typical, but every sentence provides valuable information: purpose, use cases, return fields, performance caveat, and ecosystem fallback. It could be slightly tightened (e.g., 'Composite' and 'fans out' are informal), but it is front-loaded and well-organized, earning a 4.

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

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

With no output schema, the description compensates by enumerating the summary block fields (is_latest, license, published_at, etc.), advisory detail, links, alternative versions, and failure behavior. It also notes the timeout possibility and graceful degradation, making it complete enough for an agent to use 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?

The schema already documents both parameters with 100% coverage, including the default version behavior. The description adds only the ecosystem scope limitation ('NPM ecosystem only in v1'), which clarifies the package parameter but does not change its meaning. Baseline 3 is appropriate as the schema carries the load.

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 it is a 'Composite "should I add this npm package to my project" check in ONE call' and names the two data sources (deps.dev and bundlephobia). It clearly distinguishes from siblings by noting the NPM-only scope and the fallback to deps.dev:version for other ecosystems.

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 guidance: 'Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me"'. It also explicitly states that non-NPM ecosystems should go to deps.dev:version directly, providing an alternative.

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

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

Beyond the read-only and idempotent annotations, the description discloses concrete behavioral details: BGE-base-en embeddings with cosine similarity over 500-char overlapping windows, a hard cap of 200K chars with truncation and flagging, and output includes character offsets and similarity scores. This gives the agent full awareness of the tool's operation and limits.

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, usage rationale, return format, and technical details. It is front-loaded with the core idea and then elaborates logically, with no superfluous text.

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

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

Given the lack of an output schema, the description adequately explains return values (passages with offsets and similarity scores). It also covers the use case, pairing with a sibling tool, input constraints, and technical mechanism, making it fully self-contained for an agent deciding whether and how to invoke it.

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 high (100%), so parameters are already well-documented. The description adds marginal value by clarifying the 'limit' as top-N passages and stating that inputs over 200K chars are 'truncated and flagged', which nuances the 'text' parameter beyond its schema 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 opens with 'Semantic search INSIDE a fetched record', a specific verb+resource that clearly distinguishes it from general search tools. It further differentiates by explicitly pairing with ask_pipeworx_grounded and describing the exact role of searching within already-fetched text.

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 when the record is too big to cram into the prompt' and explains the benefit of saving context and returning only relevant passages. It also gives a complementary usage pattern with ask_pipeworx_grounded, offering clear guidance on how this tool fits into a workflow.

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 not read-only, not destructive, idempotent, and open-world. The description adds meaningful behavioral context beyond these: the need for OAuth authentication, persistent feed behavior, phone verification for SMS, and the 10/day cap. It also implies idempotency by returning a new subscription id, but does not contradict annotations. However, it does not mention webhook behavior (e.g., signing secret at subscribe time) which is only in the schema.

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

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

The description is a single tight paragraph that front-loads the primary purpose and then efficiently covers requirements, types, and delivery channels. There are no wasted sentences, though it could be slightly better structured with bullets or separation of concerns. It is appropriately sized for the amount of 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?

The tool is moderately complex with 3 params, nested objects, 5 enum values, and no output schema. The description covers auth, types, and feed/email/SMS but omits the webhook delivery option entirely and only mentions 3 of the 5 supported types (patent_grant and clinical_trial are missing). Since there is no output schema, the description only states that a subscription id is returned, leaving other possible response details unclear. This is a clear gap in completeness.

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

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

Schema coverage is 100%, so baseline is 3. The description enriches parameter semantics with concrete examples for each supported type (e.g., 'items:["5.02"] = officer change', 'topic:"fed"', 'series_id:"UNRATE"') and clarifies delivery channels (feed, email, sms) with phone verification requirements. This goes beyond the schema's descriptions.

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

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

The description opens with 'Create a proactive monitoring subscription to a live-data event stream,' which is a specific verb+resource statement that clearly differentiates from siblings like list_subscriptions and unsubscribe. It also notes the return value (subscription id), cementing its purpose.

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

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

The description gives important context for when to use the tool: it requires a Pipeworx OAuth account and notes that anonymous/BYO cannot persist subscriptions. It also explains the always-on feed and optional email/SMS channels, implying when you'd use each. It does not explicitly mention alternatives or when not to use, but the guidance is clear enough for an AI agent.

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

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

Annotations already declare readOnly/openWorld/idempotent, so the safety profile is known. The description adds meaningful behavioral detail: it returns category-bucketed examples, uses the live catalog, supports topic filtering, and teaches meta-tool invocation. 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 front-loaded with example user queries, then explains purpose, categories, and usage. It is somewhat long but every element earns its place, providing useful intent-matching phrases and category lists without filler.

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

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

For a single-optional-param tool with no output schema, the description thoroughly covers return format (category-bucketed examples with tool+argument shape), invocation patterns (omit for full spread, topic to focus), and when to use it. Omitted details like error handling are unnecessary for this 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% and the schema's parameter description already lists allowed topics and the omit behavior. The description adds only a few examples ('finance', 'pharma', 'betting') and a synonym for the omit case ('full spread'), which is largely redundant. Baseline 3 is appropriate.

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

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

The description explicitly states the tool is the onboarding entry point for an agent that just connected, returning category-bucketed example questions with exact tool and argument shapes. This distinguishes it clearly from siblings like ask_pipeworx or discover_tools by emphasizing its role as a suggestion/exploration 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?

The description gives explicit when-to-use guidance: 'Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools.' It also mentions alternatives (ask_pipeworx, entity_profile, compare_entities) contextually, though it doesn't fully spell out when NOT to use it.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds context about the content of the summary (organism, sequence, mean pLDDT), which is useful. It does not disclose any additional behavioral traits like auth or rate limits, but the annotations cover the safety profile.

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

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

The description is a single, front-loaded sentence that conveys the essential purpose. It is concise with no wasted words and easy to parse.

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

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

Despite the minimal description, the tool is simple (one parameter) and benefits from rich annotations and an output schema. The description specifies the key content fields, making the tool understandable. The only notable gap is the undefined 'qualifier' parameter, but overall, the tool is adequately described for its 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 input schema has only one required parameter 'qualifier' with examples but no description. The tool description does not explain what 'qualifier' means or how it relates to the prediction. Schema description coverage is 0%, and the description fails to compensate for this gap.

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 provides a short summary for a prediction, specifically including organism, sequence, and mean pLDDT. This is specific and actionable, though it doesn't explicitly distinguish it from sibling tools like 'prediction' or 'annotations'.

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 no explicit guidance on when to use this tool versus other tools. It implies usage for obtaining summary details of a prediction, but does not mention alternatives or exclusions. Context beyond the basic purpose is missing.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful context about what data is returned (PDB/CIF/PAE URLs, pLDDT scores), going beyond the annotations without contradicting them.

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

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

The description is a single, front-loaded sentence that packs the action, resource, and parameter semantics without any wasted words or repetition of annotations.

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 only one parameter and an output schema provided, the description is sufficient: it states the input format, the data retrieved, and the relationship to a sibling tool. No additional context is needed.

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

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

Despite 0% schema description coverage, the description fully explains the single parameter: it is a UniProt accession (e.g., 'P00533'), including an example and the note that it is explicitly expected. This entirely compensates for the missing schema description.

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

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

The description uses a specific verb ('Fetch') and names the exact resource ('AlphaFold structure prediction metadata'), and differentiates from the sibling tool 'prediction' by noting it 'takes uniprot_id explicitly.' This makes the tool's purpose unmistakable.

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

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

It explicitly compares itself to the sibling tool 'prediction' and states the key distinction ('takes uniprot_id explicitly'), giving clear guidance on when to choose this tool over the alternative.

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

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

The description discloses behavior beyond annotations: ownership is enforced, the row is deactivated not deleted, and historical events remain available. This complements annotations (e.g., destructiveHint=false) and provides concrete context about side effects and permissions. 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, front-loaded with the action, and every sentence adds value. The first states what it does; the second explains ownership, behavior, and consequence. No wasted words.

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

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

Given the tool's simplicity (1 param, no output schema, no nesting), the description fully covers what an agent needs to know: action, parameter source, ownership restrictions, and the non-destructive outcome. It is self-sufficient even with modest 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?

The schema already documents the 'id' parameter with a clear description ('Subscription id (uuid) returned by subscribe'). Since schema coverage is 100%, the description adds no significant extra meaning beyond the action itself. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Cancel' and resource 'subscription', and clearly scopes by 'id'. It also distinguishes itself from siblings like subscribe (create) and list_subscriptions (list) by stating 'Cancel a subscription by id.' The added detail about deactivation (not deletion) further clarifies its unique purpose.

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

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

The description clearly implies when to use the tool: to cancel a subscription. It adds a critical constraint (ownership enforcement) and references recent_alerts as the place to see historical events. However, it does not explicitly name alternatives or state when not to use it, so it falls just short of full guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is known. The description adds valuable behavioral detail: it explains the structured fast path for company financials, the fallback grounded pipeline with 'verbatim evidence', the verdict categories, and the 'pipeworx:// citation'. It also clarifies tolerance_pct behavior. This goes beyond the annotations without contradicting them.

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

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

The description is dense but well-structured, opening with user-phrase patterns, then the core purpose, followed by the routing logic, return details, and an efficiency claim. Every sentence carries substantive information, though it is longer than necessary; it could be tightened without losing meaning. Overall it is appropriately sized for a complex tool and achieves good front-loading.

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

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

Given the tool's complexity and the absence of an output schema, the description sufficiently explains the return values: the verdict types (confirmed / approximately_correct / refuted / inconclusive / unsupported), the grounded or structured actual value with citation, and reasoning. It also covers the input space (company-financial vs. other claims). Missing some details like rate limits or error states, but overall it is complete enough for an agent to understand what to expect.

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

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

Schema description coverage is 100% (both claim and tolerance_pct have descriptions). The tool description adds further utility by giving concrete claim examples and explaining tolerance_pct's override semantics: 'Overrides the tolerance implied by the claim wording — set 1–2 for hallucination detection where any material error must be refuted.' This adds meaning beyond the raw schema, though the schema already does most of the work.

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

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

The description clearly states the tool's function: 'natural-language claim verification against authoritative sources' and explicitly says 'Use whenever the agent needs to check whether something a user said is factually correct.' It distinguishes itself from siblings like deep_research or entity_profile by focusing on true/false claim verification and by noting it 'Replaces 4–6 sequential calls' (NL parsing → entity resolution → data lookup → comparison), which highlights its unique single-call role.

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

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

The description provides a clear 'when to use' condition: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also provides sub-routing guidance within the tool itself (company-financial claims go through SEC EDGAR + XBRL, other claims fall through to a grounded pipeline). However, it does not explicitly name alternative sibling tools to avoid, so it falls short of a full 5, but offers strong contextual guidance.

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