Goproxy

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

Annotations already indicate read-only, idempotent, and open-world behavior. The description adds valuable context: default model is free, Anthropic requires BYO key, output includes per-model {score, confidence, signals, raw_response} plus combined view. No contradictory information.

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

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

The description is four sentences: first sentence states the core function, second adds model details, third describes return format, fourth lists use cases. Every sentence is informative and no unnecessary words. Front-loaded with the main action.

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

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

Given the tool's moderate complexity (4 parameters, no output schema), the description is complete: it explains purpose, parameter usage, return format, and use cases. Annotations cover safety and behavior. No missing pieces needed for an agent to invoke correctly.

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

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

Schema description coverage is 100% (all parameters described). The description enriches semantics by specifying the default model as 'Workers AI Llama-3.3-70b', clarifying that _apiKey is only needed for Anthropic, and explaining that context aids disambiguation. This goes beyond the schema descriptions.

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

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

The description clearly states the tool probes LLMs for knowledge about entities and scores visibility (0-100) per model, with a specific verb 'probe' and resource 'visibility'. It distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on scoring per-model and providing a combined view.

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

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

The description specifies use cases ('AI-marketing audits, pre-launch brand checks, competitive monitoring') and provides model selection guidance (default free, optional Anthropic with key). It lacks explicit comparisons to sibling tools or when-not-to-use advice, but the purpose is clear enough for an agent to decide.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true, and the description is consistent with them — no contradiction. Beyond the annotations, it adds valuable behavioral context: the tool is a meta-router over thousands of sources, it auto-fills arguments (so the agent only supplies a question), and it returns structured answers with stable pipeworx:// citation URIs. It stops short of a 5 because it never addresses what happens when no source matches or how failures/latency manifest.

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 front-loaded — the preference directive and domain list come first — but the tail is visibly repetitive: 'START HERE for most questions' and 'even if web search could also answer it' recur, and the example block appears to be duplicated. Roughly a quarter of the text is redundant, which dilutes an otherwise efficient structure.

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 broad router with one required parameter, no output schema, and rich annotations, the description covers the essential decision factors: when to invoke it, how it behaves internally (routing, argument filling), and the output shape (structured answer plus pipeworx:// citation URIs). Missing only edge-case details such as no-match behavior or failure modes, which are secondary for selection and invocation.

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

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

Schema coverage is 100%: 'question' is fully documented and all five aliases (q, text, input, query, prompt) are individually described in the schema, so the baseline of 3 applies. The description's only contribution is 'fills arguments,' which reassures the agent that no additional parameters are needed. No per-parameter meaning is added beyond what the schema already provides.

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

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

The description states a specific function with action verbs: 'Routes the question to the right one of 5,767 tools across 1506 verified sources, fills arguments, returns the structured answer.' It delimits scope precisely to factual questions about real-world entities, events, and numbers, and it separates itself from the main alternative with 'PREFER OVER WEB SEARCH' and 'even if web search could also answer it.' It does not differentiate from sibling variants ask_pipeworx_beta/grounded, but the standalone purpose is 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?

This is exemplary routing guidance: explicit trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), a concrete domain list (SEC, FDA, FRED/BLS, patents, real estate, weather, clinical trials, stocks, crypto, sports), six worked examples, the directive 'START HERE for most questions,' and an explicitly named alternative (web search) with the condition 'even if web search could also answer it.' The when-not boundary is implied rather than stated, but the factual/structured-data edge is clear.

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

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

Discloses a critical state-dependent behavior beyond the annotations: candidate routing improvements may be enabled live, so behavior can differ from ask_pipeworx over time, and it currently matches ask_pipeworx exactly with a dated evidence reference. This complements the readOnly/idempotent safety annotations with experimental compare-and-merge context. Rate limits and auth are not mentioned, but the annotation profile already covers safety.

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

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

Five sentences, front-loaded with the core identity: identical router, 5,767 tools, same arguments and response shape. The candidate retirement date is specific but grounds the 'currently matches ask_pipeworx exactly' claim with evidence. No filler, and the 'falls back to nothing' clarification earns its place by preventing a common misinterpretation.

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 whose entire contract is 'identical to ask_pipeworx,' the description covers what it is, when to use it, its current state, and its safety profile via annotations. The absence of an output schema is mitigated by the 'same response shape' pointer to the stable sibling. Given the moderate complexity, nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, with every parameter (question plus five aliases) already documented in the schema. The description adds only that arguments are identical to ask_pipeworx, which is a pointer rather than new semantic detail. With the schema carrying the load, the baseline 3 is appropriate.

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

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

States precisely that this is the beta of ask_pipeworx, an identical universal router over 5,767 tools with the same arguments and response shape. The beta-vs-stable distinction differentiates it from its closest sibling, and the clarification that it is a full working router rather than a fallback removes ambiguity about what it does.

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

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

Explicitly instructs the agent to 'use it exactly like ask_pipeworx when you want the newest routing,' naming the alternative and the selection condition. The closing line that it 'falls back to nothing' preempts a likely misuse. No explicit when-not-to-use statement, but the stable-vs-experimental contrast strongly implies it.

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

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

The annotations already indicate safe read-only, open-world, idempotent behavior. The description goes further by disclosing an explicit refusal contract with all refusal_reason values, the exact success return shape, and the extra LLM call cost. This adds behavioral detail well beyond the structured 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 section earns its place: purpose, return contract, failure modes, usage guidance, and cost trade-off. The most important differentiator ('grounded extraction') is front-loaded, and the refusal-reason list is compact and directly useful.

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

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

With no output schema present, the description fully covers return values and refusal responses. It also explains the relationship to ask_pipeworx, the cost difference, and the high-stakes use cases, making the tool self-sufficient for correct invocation and interpretation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'fills arguments' in a general way but adds no extra meaning about individual parameters; the schema itself already documents accepted aliases like query, prompt, and text.

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

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

The description clearly identifies a specific verb ('EXTRACTS the answer') and a distinct resource/behavior ('hallucination-resistant answer mode') and explicitly differentiates from ask_pipeworx by noting the same routing but grounded extraction. It leaves no doubt as to what task this tool performs.

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 exactly when to use this tool: whenever an answer will be quoted, cited, or acted on and the agent must not invent facts. It also gives a clear exclusion by saying 'prefer ask_pipeworx for casual lookups,' and it names the relevant alternative sibling.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint false), the description reveals behavioral traits: low-confidence matches short-circuit with status, closed markets skip fan-out, wide spreads flag illiquidity, and resolution-rule risk parsing. It details response shape and edge-case handling, adding substantial context annotations alone do not provide.

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

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

The description is long but densely informative, with a logical structure: purpose, usage, classifiers, fan-out examples, response shapes, resolver contract, parent events, news fields, safety. Every sentence adds value, though it could be slightly more concise without losing essential details.

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

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

Given the tool's complexity and absence of an output schema, the description covers all bases: input specification, behavioral nuances (e.g., market match confidence, cancellation rules), error states (low_confidence_match, market_closed_or_inactive), and guidance for interpreting results. An AI agent has sufficient context to use the tool effectively.

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

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

Schema coverage is 100%, and the description adds rich meaning: market accepts slug, URL, or question text; depth enum explained as 'quick = 2-3 evidence sources, thorough = full fan-out'; include_raw default false with guidance on when to set true. Examples in input schema reinforce usage.

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

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

The description starts by stating the tool 'Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call,' clearly indicating the verb (research), resource (Polymarket bet), and scope (single call). It specifies input types (slug, URL, question text) and distinguishes itself from sibling tools focused on general queries (ask_pipeworx) or claim validation (validate_claim).

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

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

The description explicitly says 'Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z"' and provides examples of classification and fan-out. It advises inspecting resolver contract fields and warns about low-confidence matches, but does not explicitly state when to avoid this tool or compare to alternatives.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description reveals data sources (SEC EDGAR for companies, FAERS for drugs), off-calendar fiscal year handling, sorting by primary metric, and return format (paired data + citation URIs). High transparency.

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

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

Description is dense but every sentence adds value. Front-loaded with example queries. Could be slightly more structured but remains efficient for 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?

Given the tool's complexity (two entity types, different data sources, sorting, citations) and no output schema, the description covers all essential behavioral aspects. Replaces 8-15 lookups context further clarifies efficiency.

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

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

Schema coverage is 100%, baseline 3. The description adds value by clarifying that 'values' for company are tickers/CIKs and for drug are names, and reinforces constraints. This is meaningful beyond schema literal 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 it performs side-by-side comparison of 2-5 companies or drugs, with example queries. It distinguishes itself from sequential single-pack lookups, 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?

Explicitly instructs to 'ALWAYS PREFER over sequential single-pack lookups when comparing entities', providing clear when-to-use guidance. Also implies limits (2-5 entities) and data source context.

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

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

Even with readOnlyHint and idempotentHint annotations, the description adds substantial behavioral context: it requires an account, notes that 'thorough' needs a paid plan, describes parallel routing to 5,767 tools, reveals the findings packet shape, explicitly says gaps[] are 'never invented', and gives latency expectations. Nothing in the description contradicts the annotations.

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

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

Though long, the description is dense and front-loaded: the account requirement and alternative tool are stated first, followed by the core mechanism, return format, use cases, depth semantics, and latency. Every sentence carries operational information; there is 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?

There is no output schema, but the description compensates fully by detailing the findings packet, citation URIs, gaps[], contradictions[], hop fields, semantic excerpting, and expected runtime. It also addresses limitations (structured catalog only) and authentication prerequisites. An agent has enough context to decide, invoke, and interpret results.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaningful layers: it clarifies the question parameter is meant for 'broad/multi-part' natural language, and it explains depth behaviors beyond the enum ('standard' re-angles unanswered gaps, 'thorough' chases leads, 'quick' is single-hop). It does not simply repeat the schema.

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

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

The description states a specific verb and resource: 'Grounded multi-source research across Pipeworx's 1506 STRUCTURED data sources... in ONE call.' It clearly distinguishes itself from siblings by saying 'this is NOT open-web search' and by naming ask_pipeworx as the alternative for single 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 when-to-use and when-not-to-use guidance is present: 'If you are not signed in, use ask_pipeworx instead', 'Best for broad/multi-part questions over structured data', and 'For a single lookup use ask_pipeworx'. It also explains the trade-off between depth levels, so an agent can select this tool appropriately.

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

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

The description adds valuable behavioral context beyond annotations: it returns top-N relevant tools with full schemas and curated examples, ready to call directly. It also mentions alias handling for query parameters. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint all consistent).

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

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

The description is concise (about 100 words) and front-loaded with the core purpose. Every sentence adds value: purpose, domain list, output behavior, usage guidance. No unnecessary words.

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

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

Given the tool's complexity (6 params, no output schema), the description fully compensates by explaining input aliases, output format (names, descriptions, schemas with examples), and usage context. It is complete enough for an agent to use correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add significant parameter detail beyond summarizing that aliases are accepted, which is already in the schema. No further semantic enrichment.

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

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

The description clearly states the tool's purpose: 'Find tools by describing the data or task.' It lists many domains and distinguishes itself from sibling tools by instructing to call it first when needing to see the option set, rather than directly answering a query.

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: 'Use when you need to browse, search, look up, or discover what tools exist for: [list]' and 'Call this FIRST when you have many tools available and want to see the option set (not just one answer).' This clearly differentiates when to use this tool versus others.

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, and idempotent hints, and the description adds substantial behavioral context: patents soft-fail, empty sections mean real no-data rather than bugs, private companies return resolved:false with notes, and news uses a GDELT→GNews fallback. It also explains that a company with only small-molecule drugs legitimately has no fda_products. No contradiction with annotations.

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

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

The description is long but densely informative; every sentence contributes either usage examples, source coverage, output sections, or edge-case behavior. The purpose is front-loaded, and the response fields are enumerated in a clear, organized sequence. It is appropriately sized 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?

There is no output schema, so the description carries the burden of explaining return values, and it does so thoroughly: cik/company_name, recent_filings URIs, fundamentals, patents, federal_contracts, fda_products, hiring, news, LEI, and sources_used/sources_failed. It also covers resolution failures and input flexibility. An agent has enough context to invoke the tool correctly without further inference.

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, but the description adds real value by clarifying that `type` accepts 'company' or 'ticker' interchangeably regardless of the actual value shape. It reinforces the three accepted value forms (ticker, zero-padded CIK, company name) and explains name resolution via SEC EDGAR, which is not fully obvious from the schema alone.

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

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

The description opens with concrete user intents and a specific deliverable: a full cross-source profile of a US public company in one parallel call. It enumerates the data sources and response sections, and explicitly contrasts itself with chaining single-pack lookups. This makes the tool's purpose unmistakable and distinct from siblings.

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

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

It explicitly says 'ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view,' giving clear when-to-use guidance. It also covers acceptable input forms, private-company fallback behavior, and soft-failure cases. This leaves little ambiguity about when to select 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 mark destructiveHint=true and idempotentHint=true. Description repeats 'Delete' but adds no additional behavioral context beyond what annotations provide, so it meets the baseline without adding extra value.

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

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

Three sentences, each adding value: main action, usage context, and relationship to siblings. No wasted words, front-loaded with verb and resource.

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

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

For a single-parameter tool with full schema coverage and annotations covering idempotence and destructiveness, the description is sufficient. It also mentions pairing, which aids context.

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

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

Schema coverage is 100% and already describes the 'key' parameter as 'Memory key to delete'. The description does not add further details about key format or constraints, achieving the baseline of 3.

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

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

The description clearly states the action ('Delete a previously stored memory by key'), uses a specific verb and resource, and distinguishes from sibling tools like 'remember' and 'recall'.

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

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

Provides explicit when-to-use scenarios: 'when context is stale, the task is done, or you want to clear sensitive data'. Suggests pairing, but does not include when-not-to-use or alternatives.

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

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

Annotations already declare idempotent, read-only, non-destructive. The description adds value by explaining the process (fetches page, extracts title/description/key links, emits markdown) and output format (single text blob). No contradictions with annotations.

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

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

The description is two sentences plus a bullet list of use cases. It is front-loaded with the main purpose and every sentence adds value. No redundant or vague phrasing.

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 the output format ('single text blob') and purpose. It covers the core process and use cases. Minor omissions: no mention of edge cases (e.g., inaccessible URLs) but acceptable given idempotent/read-only annotations.

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

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

Schema coverage is 100% with clear descriptions for both parameters (url, max_links). The tool description does not add significant meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('generate'), the resource ('llms.txt file'), and the outcome ('so AI crawlers can index the site cleanly'), with specific steps (fetches, extracts, emits). It is distinct from siblings like ai_visibility_check and scan_competitor_ai_presence.

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

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

The description lists three concrete use cases (client indexing, drafting own project, auditing competitor), providing clear context for when to use the tool. However, it does not explicitly compare to sibling tools or mention 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. The description adds no behavioral context beyond the brief subject, missing details like error handling, rate limits, or what happens for missing module_path.

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?

Extremely short description is not helpful conciseness; it is under-specification. No front-loading of key information. Every sentence should earn its place, but this single phrase fails to convey essential purpose.

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

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

Given the tool has two parameters (one required), no schema description, but has an output schema, the description is wholly inadequate. It does not explain return values, prerequisites, or how the tool integrates with the domain.

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

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

Schema description coverage is 0%, meaning the description does not explain parameters at all. The description adds no meaning beyond the schema, leaving the agent to guess the purpose of 'version' and 'module_path'. Baseline is low due to poor 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 'go.mod content' is vague and does not specify what action the tool performs (e.g., retrieve, list, get). It hints at the subject but lacks a clear verb and resource distinction from siblings like 'module'.

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 on when to use this tool versus alternatives. The sibling 'module' tool is related but no differentiation is provided. Agent has to infer usage from context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by listing returned fields (id, type, params, etc.) and mentioning the default filter for active subscriptions, aligning with annotations without contradiction.

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

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

The description consists of two efficient sentences: the first states the tool's purpose and return fields, the second provides usage guidance. 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 simple parameter schema, comprehensive annotations, and lack of output schema offset by listing return fields, the description sufficiently covers what an agent needs to select and invoke the tool correctly.

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

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

Schema has 100% coverage for the single parameter, already describing include_inactive with default false. The description adds no further detail about the parameter beyond implying active subscriptions.

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 'List the caller's active subscriptions' with a specific verb and resource, and distinguishes from sibling tools like subscribe and unsubscribe.

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

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

The description explicitly says 'Use this to review what you're monitoring before adding more or to find an id to cancel', providing clear when-to-use and alternative tool references.

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 no behavioral context beyond stating the output, which is adequate but not enhanced. No contradictions.

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

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

The description is very concise at four words, but this conciseness sacrifices clarity. It is front-loaded but too minimal to be informative, failing to earn its place with meaningful content.

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

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

Despite an output schema and good annotations, the description lacks context about the tool's domain (e.g., Go modules) and how it differs from similar tools. It is incomplete for an agent to confidently select and use 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 0% with no property descriptions. The description mentions 'most recent version' which implies module_path identifies a module, but it does not clarify the expected format (e.g., Go module path) or add meaning beyond the raw parameter name.

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 'Most recent version + metadata' vaguely implies retrieval but is not a clear verb-resource statement. It does not distinguish from sibling tools like go_mod or versions, making the tool's specific purpose ambiguous.

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 no guidance on when to use this tool versus alternatives such as go_mod, versions, or version_info. No context about prerequisites or limitations is given.

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

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

Annotations are all false and offer no safety hints, but the description adds rich behavioral context: rate limit (5/day), free usage, no quota impact, the claim_token return and lookup flow, and the team's daily digest practice. This goes well beyond the annotations.

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

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

Every sentence earns its place, providing distinct information: purpose, usage conditions, boundary conditions, instructions, return behavior, and constraints. It is front-loaded with the core action and avoids redundancy despite being long.

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

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

Despite having no output schema, the description explains the return behavior (claim_token), how to check on the resolution, rate limits, scope limitations, and the team's workflow. This is complete for a feedback tool and leaves no critical gaps.

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

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

Schema coverage is 100% with detailed parameter descriptions, so baseline is 3. The description adds extra guidance beyond the schema: 'don't paste the end-user's prompt', 'describe in terms of Pipeworx tools/packs', and clarifies that claim_token is returned when filing without an account, which enriches the parameter semantics.

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

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

The description uses a specific verb ('Tell') and resource ('Pipeworx team') and clearly states the tool's scope: reporting something broken, missing, or needing to exist. It distinguishes itself from sibling research/analysis tools by focusing on feedback submission.

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

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

Provides explicit when-to-use criteria (bug, feature/data_gap, praise) and when-not-to-use (tools from other MCP servers), including the alternative action of filing with that server. Also gives instructions on how to describe issues, making usage unambiguous.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive, so safety is clear. The description adds value by explaining the data source (CF analytics-engine), no PII, and caching behavior (5min-1h). It does not contradict annotations.

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

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

The description is highly concise: two sentences summarizing output, three bullet points for use cases, and one sentence on provenance. No wasted words; front-loaded with core function.

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

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

For a simple tool with one parameter and robust annotations, the description covers output (top tools, packs, volume), data source, caching, and use cases. It lacks specifics on response format (e.g., whether counts are absolute or relative), but overall sufficient.

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 description already explains the window parameter's effect. The tool description repeats the same semantics without adding new information. Baseline of 3 is appropriate as schema does the heavy lifting.

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

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

The description clearly states what the tool does: returns top tools, packs, and total call volume over a time window. It uses specific verbs and resources, and the purpose is distinct from siblings like discover_tools. The bullet points on use cases further clarify its value.

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

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

The description provides explicit use cases (discovering hot data sources, confirming canonical tools, aligning with agent needs) but does not specify when not to use it or differentiate from alternatives. The guidance is clear and contextual, though exclusion criteria are absent.

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

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

Annotations already indicate readOnlyHint and idempotentHint, but the description adds significant context: semantic anchor (Jaccard similarity), partition filter, fill check against CLOB depth, and response structure. 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 detailed but well-structured with clear sections (e.g., 'SEMANTIC ANCHOR', 'PARTITION FILTER', 'FILL CHECK'). While long, every sentence adds value; slightly more formatting (e.g., bullet points) could improve readability.

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 complexity of arbitrage detection with multiple modes, the description covers scanning, partition checks, cross-event handling, fill risk, and integration with other tools. It lacks an explicit output schema but describes the response structure 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?

Schema coverage is 100%, and the description enriches both parameters: event as slug/URL for single-mode, topic as seed for cross-event mode, explaining the behavior of each and why to choose one over the other.

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

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

The description clearly states 'Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks,' which is a specific verb-resource-method combination. It is distinct from sibling tools like polymarket_edges and polymarket_fill_risk.

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

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

The description explicitly instructs when to use no args, event, or topic modes, and directs users to polymarket_fill_risk for custom sizing, providing clear usage guidance and alternatives.

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

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

The description provides extensive behavioral context beyond annotations, including three model segments, edge calculation details, caching strategy, and diagnostics. It adds value by explaining internal logic and edge cases, with no contradictions to 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 and contains significant technical detail. While well-structured into paragraphs, it is lengthy and could be more concise for quick comprehension.

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

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

Given no output schema, the description covers the response structure (by_segment, diagnostics) and explains filter behavior. It is complete enough for an agent to understand inputs and outputs, though a formal return type specification would enhance clarity.

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 descriptions are already detailed. The description adds contextual advice (e.g., slippage adjustment, min_partition_leg_kelly clarification) and behavioral impact, going beyond what the schema provides.

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

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

The description clearly states the tool scans Polymarket markets and returns opportunities where Pipeworx data disagrees with market price. It specifies the use case 'what should I bet on today' and differentiates from sibling tools by focusing on edge detection with detailed model families.

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

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

The description explicitly says it's for discovering opportunities without paging hundreds of markets and provides guidance on adjustable knobs. However, it does not explicitly contrast with sibling tools (e.g., polymarket_arbitrage) or state when not to use it.

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

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

Annotations indicate read-only, open-world, idempotent, non-destructive behavior. The description adds rich behavioral detail: snapshot TTL limits, decay computation from daily closes, interpretation of negative values, trend categories, and meaning of data gaps. No contradictions.

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

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

The description is a single dense paragraph but is front-loaded with purpose. Every sentence adds value, though it could be slightly more structured (e.g., bullet points for response sections). 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?

No output schema exists, so the description must compensate. It thoroughly describes the three output arrays (tracked, expired, snapshot_dates) with field explanations, limits, and caveats, making it complete for an AI agent to understand the return value.

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

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

Schema coverage is 100%, so baseline is 3. The description adds default values for both parameters (days: 14, window: '1wk'), max clamp for days (30), and explains how parameters affect output via the response structure. This goes beyond the schema.

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

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

The description clearly states the tool's purpose: providing edge persistence and decay telemetry from daily snapshots, answering how long an edge has existed and if it is shrinking. It distinguishes from siblings like polymarket_edges by focusing on time-series and decay analysis.

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 guidance on when to use (distinguishing between fresh and old edges) and implies context through the comparison, but does not explicitly name alternative tools for simpler edge queries. 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 (readOnlyHint, idempotentHint, destructiveHint) already indicate safe read-only behavior. The description adds significant context: walks the ladder, returns verdict (clean|degraded|cannot_fill), explains forced directional risk for baskets, and mentions the dominant loss mode (partial fills converting arb into directional position).

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

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

The description is somewhat long but each sentence earns its place, front-loading purpose and key requirement. It could be slightly better structured (e.g., bullet points for modes) but remains dense and informative without waste.

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

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

Despite having no output schema, the description exhaustively documents all return fields for both modes, explains edge cases (partial fills, forced directional risk), and provides sufficient context for correct tool invocation and result interpretation.

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

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

Schema description coverage is 100%, baseline 3. Description adds nuance: size_usd interpreted differently for single-market (spend/target) vs basket (settlement notional), side defaults explained for both modes, and return fields listed that are not in schema (e.g., top_of_book, vwap_fill_price, capture_ratio, etc.).

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 does a 'Realizable-vs-theoretical edge check against live CLOB order-book depth' with two explicit modes (single-market and basket). It distinguishes from siblings like polymarket_arbitrage and polymarket_edges by specifying usage before acting on those signals.

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

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

The description explicitly says 'USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500', explains why (theoretical overround not capturable, partial fills cause directional risk), and clarifies requirement of one of `market` or `event`.

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 (readOnly, idempotent, non-destructive) provide the safety profile, and the description richly extends it: compatibility codes are enumerated with meanings, unclassified legs are NEVER paired, temporal_alignment null means 'could not be computed' not 'aligned', spreads are gross not net because Kalshi fees aren't modeled, and returned pairs can still carry non-empty warnings. This is far beyond what annotations alone 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?

Every sentence carries information, and the purpose is front-loaded, but the description is a dense wall of text with heavy ALL-CAPS emphasis ('TWO MODES', 'BOTH', 'NEVER', 'EITHER') that could have been replaced by section headings or bullets. For a 3-parameter tool it is long; the length is mostly justified by the missing output schema, but scannability suffers.

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

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

There is no output schema, so the description carries the full burden of explaining return values — and it does: leg-by-leg prices, spread[].top_spreads_pp with the Kalshi − Polymarket sign convention, per-entry flags[], skipped_unclassified, low_confidence_pairs, temporal_alignment, fees_note, and skipped cross-type/subtype counters. An agent has enough to interpret results correctly without guessing.

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; each parameter is already documented with allowed values and examples. The description adds genuine value on top by explaining that BOTH modes run the identical token-overlap matcher, that the explicit ticker/slug 'override' the topic-mapped side, and that the same disclosures apply regardless of mode — semantics the schema fields don't convey.

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

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

The opening sentence nails it: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question' — a specific verb, resource, and scope. It distinguishes itself from polymarket-only siblings (polymarket_arbitrage, polymarket_edges, polymarket_edge_tracker) by naming the cross-venue comparison as the core job, and immediately clarifies the two operational modes.

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

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

The TWO MODES section explicitly tells the agent when to use the pre-mapped topic shortcuts versus explicit ticker/slug pairings, and the override relationship between parameters. The warning 'pre-mapped ≠ tradeable' and 'most pre-mapped topics return compatibility_warning today' serves as a when-not guidance. It stops short of naming sibling alternatives for when this tool shouldn't be used at all.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds scoping to 'your identifier' and pairing intent, which adds behavioral context beyond annotations.

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

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

Four sentences with no wasted words, front-loaded with the primary action. Concise yet fully informative.

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 retrieval tool with one optional parameter and good annotations, the description covers purpose, usage, scoping, and pairing completely.

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

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

Schema coverage is 100% with description for 'key'. The tool description adds examples of typical keys (ticker, address, notes) and clarifies omitting key lists all, enriching meaning beyond schema.

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

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

The description clearly states the tool retrieves a saved value or lists keys, using specific verbs 'retrieve' and 'list'. It distinguishes from siblings by naming 'remember' and 'forget' 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?

Provides clear context for use: 'to look up context the agent stored earlier... without re-deriving it from scratch.' While it doesn't explicitly state when not to use, the pairing with remember/forget gives good 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 includes a mark_read parameter that modifies state (flags events as read), which contradicts the readOnlyHint annotation that indicates the tool does not modify state.

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

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

The description is concise (4 sentences), front-loaded with the purpose, and each sentence adds necessary detail without redundancy.

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

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

Covers return fields, filtering, and mark_read behavior, but lacks details on pagination or error handling; no output schema, so description partially compensates.

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 full schema coverage, the description adds valuable examples (e.g., filter type 'sec_8k') and explains the mark_read behavior more clearly than the schema alone.

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

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

The description clearly states 'Pull fired events from your subscription feed' with specific verb and resource, and distinguishes itself by mentioning an alternative feed for scripts and dashboards.

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 (polls work fine) and mentions an alternative source (GET endpoint) for scripts/dashboards, but does not explicitly exclude cases.

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

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

The description details the fan-out to multiple sources, fallback logic from GDELT to GNews, soft-fail for USPTO, and return format (grouped changes, count, URIs). This adds significant value beyond the annotations (readOnlyHint, idempotentHint). No contradiction.

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

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

Single paragraph with clear structure: example queries, source enumeration, parameter format, return format. Every sentence adds value with no redundancy.

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

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

Given the tool's complexity (multiple sources, fallback, window formats) and no output schema, the description fully covers inputs, behavior, and output format, making it self-sufficient.

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% description coverage, but the description adds meaning: explains `since` shorthand (ISO vs relative), suggests typical value '30d', and clarifies `value` as ticker or CIK. Provides context beyond schema.

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

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

The description clearly states the tool provides a change feed for a company, specifying sources (SEC, GDELT/GNews, USPTO) and distinguishing from the sibling tool 'entity_profile' by noting it returns dynamic changes vs static profile.

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

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

The description explicitly lists example queries ('What's new with X', 'latest on Y') and advises when to use 'entity_profile' instead. It lacks explicit 'when not to use' but provides clear usage context.

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

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

Annotations provide idempotentHint=true and destructiveHint=false. The description adds important behavioral context: memory persistence duration (24 hours for anonymous, persistent for authenticated), scoping by agent identifier, and key-value storage model. 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 three sentences, each providing essential information. It is front-loaded with the primary purpose, and every sentence adds value without fluff or repetition.

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

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

The tool has two parameters, no output schema, and annotations. The description thoroughly covers when to use, memory scope, persistence, and relationship to other tools. It leaves no obvious gaps for an agent to misuse 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 already has 100% coverage with descriptions for both 'key' and 'value' parameters. The description does not add new parameter information beyond what the schema provides, so it meets the baseline expectation.

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 ('Save data') and identifies the resource ('key-value pair'). It clearly distinguishes the tool from its siblings ('recall', 'forget') by mentioning them explicitly.

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

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

The description explicitly states when to use the tool ('when you discover something worth carrying forward') and mentions complementary tools ('Pair with recall to retrieve later, forget to delete'). No alternative tools are suggested, but the guidance is clear and actionable.

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

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

Annotations already declare the tool read-only, open-world, and idempotent, and the description adds substantial behavioral context beyond that: internal cascading lookups, graceful degradation when GLEIF/OpenFIGI are unavailable, explicit `unresolved` output, and `figi_candidates` on ambiguous matches. It also details edge cases like ISIN-to-LEI mapping and non-US issuer coverage, which are not visible from annotations or schema.

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

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

The description is long and dense, but the front-loaded opening sentence establishes purpose immediately and the complexity of a multi-endpoint resolution tool justifies much of the detail. The heavy use of nested parentheticals and eight example phrasings makes it less crisp than it could be, though each section does contribute necessary 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?

Despite having no output schema, the description covers return semantics thoroughly: identifiers labelled with their source, unresolved identifiers explicitly stated, `figi_candidates` when a name matches multiple instruments, and graceful degradation of LEI/FIGI enrichment. It also explains both supported entity types' result contents and accepted inputs, so nothing the agent needs to invoke or interpret the call is missing.

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

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

Schema coverage is 100%, giving a baseline of 3, but the description adds essential meaning beyond the schema: 'Pass the ENTITY NAME ONLY' with a concrete bond-issuer counterexample, accepted input formats per entity type (ticker, CIK, ISIN, brand/generic), and how ambiguity is handled. This materially improves the agent's ability to construct correct calls.

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 and resource: resolving a user-spoken name to canonical/official identifiers that other tools require. It lists concrete user phrasings ("What's the ticker for…", "who owns X") and explicitly frames itself as the first lookup step, which clearly separates it from sibling tools that operate on already-resolved entities.

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 guidance 'Use FIRST whenever you have a name but need an ID' is an explicit when-to-use instruction, and the description explains that the tool replaces 2-3 manual lookups. It does not name alternative tools or give explicit when-not-to-use conditions, but the context is clear enough for an agent to select this over siblings like entity_profile or compare_entities.

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 valuable behavioral context beyond annotations, such as probing each entity with ai_visibility_check, ranking by score, and returning a ranked list with score, confidence, and signal density. It also notes the first entity is treated as the subject for narrative. 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 two sentences, front-loaded with the main action, and every sentence earns its place without waste. It efficiently conveys purpose, methodology, and use case.

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

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

Given the tool's moderate complexity (4 parameters, all documented) and no output schema, the description adequately covers return structure (ranked list with score, confidence, signal density per entity). Complete for an agent to understand inputs and outputs.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that the first entity in the array is treated as the subject for narrative, which is not in the schema. This adds semantic value beyond the parameter descriptions.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, using specific verbs and resources. It distinguishes from siblings like ai_visibility_check (single entity) and compare_entities (generic) by specifying the context of competitive AI-marketing audits.

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 frames usage for competitive AI-marketing audits with a concrete example ('does Claude know about us as well as our competitors?'). It implies when to use but does not explicitly exclude cases or name alternatives, though the context is clear.

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

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

Annotations already signal read-only and idempotent behavior. Description adds valuable context: composite external calls, partial failures with graceful degradation, and a 5-30s timeout on bundlephobia's first measurement for a new version.

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

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

Description is information-dense and covers all aspects in a logical order: purpose, use case, ecosystem scope, return values, and edge cases. While it runs long, every sentence adds value and there is 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?

With no output schema, the description fully documents return values (summary block, advisories, links, versions) and handles edge cases like partial failures and timeouts, making it complete for the agent to understand the tool's behavior.

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

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

Schema covers both parameters with descriptions (100% coverage). Description adds no new parameter-level details beyond what schema provides, though it does clarify the composite purpose. 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?

Description clearly states the tool is a composite check for npm packages across deps.dev and bundlephobia, with a specific use case ('should I add this npm package to my project'). It distinguishes from siblings by being the dedicated tool for npm dependency analysis.

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

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

Explicitly instructs when to use: when an agent asks about safety, popularity, size, or cost of adding an npm package. It also notes the ecosystem limitation (NPM only) and compares with other ecosystems, though it doesn't list specific sibling tool alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true. The description adds significant context: BGE-base-en embeddings, cosine similarity, 500-char overlapping windows, 200K char limit with truncation flag, and that passages have offsets for verification. No contradictions.

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

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

The description is fairly concise and front-loaded with the key purpose and usage. Some implementation details (embedding model, window size) may be extraneous, but overall every sentence adds value and there is minimal waste.

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

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

Given 3 parameters, comprehensive annotations, and no output schema, the description is nearly complete. It covers behavior, constraints (truncation), usage pattern, and even ties to a sibling tool. An agent can fully understand and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining that 'text' is the document to search, 'query' is a natural-language query with examples, and mentions default and range for 'limit'. This goes beyond the schema's minimal 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 'Semantic search INSIDE a fetched record' and specifies the inputs (text and query) and outputs (top-N passages with offsets and similarity scores). It distinguishes itself from siblings by mentioning pairing with ask_pipeworx_grounded, establishing a unique niche.

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

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

Explicitly states when to use: 'when the record is too big to cram into the prompt — search_within saves context'. It pairs with ask_pipeworx_grounded but does not explicitly list alternatives or when not to use, though the context is clear enough.

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

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

The description discloses critical behavioral traits beyond annotations: account prerequisites, SMS throttling (10/day cap), webhook auto-disable after 10 failures, and delivery channels. It adds value without contradicting annotations.

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

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

The description is front-loaded with the main action and methodically details types and delivery, with no wasted sentences. It earns its length with valuable 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 complexity of event types and delivery, the description covers inputs comprehensively. However, the return format is only briefly mentioned as 'new subscription id' without additional structure, leaving slight ambiguity in output expectations.

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

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

With 100% schema description coverage, the description enhances understanding with concrete examples for each type, delivery options, and webhook signing details. It adds significant meaning beyond the schema.

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

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

The description clearly states the tool creates a proactive monitoring subscription and returns a subscription ID, specifying various event types and delivery channels. It effectively distinguishes from sibling tools like list_subscriptions and unsubscribe by focusing on creation.

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

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

The description provides explicit context for when to use (proactive monitoring, supported types) and account requirements (Pipeworx OAuth). It does not explicitly mention when not to use or alternatives, but the context is strong enough to guide correct usage.

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

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

Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds context about returning example questions from a live catalog and being the first step, which complements the annotations without contradiction.

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

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

The description is efficiently structured, front-loading common queries, then explaining what it returns, how to call it, and when to use it. Every sentence adds unique value without repetition or excess.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is fully complete. It covers purpose, return content, usage modes, and placement in the tool ecosystem, leaving no gaps.

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

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

Schema coverage is 100% with a clear description for 'topic'. The main description further clarifies the effect (full spread vs focused) and gives specific examples like 'finance', adding value beyond the schema.

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

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

The description clearly states the tool's purpose as the onboarding entry point, returning category-bucketed example questions with tool and argument shapes. It uses specific verbs like 'returns' and 'call', and distinguishes it from sibling tools like ask_pipeworx by focusing on exploration.

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

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

Explicit guidance: 'Use this FIRST when you do not yet know what Pipeworx can do for you' and to learn meta-tools. It details calling with no arguments for full spread or passing a topic, providing clear context for when to use this tool vs alternatives.

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

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

Discloses beyond annotations: row is deactivated (not deleted), historical events remain. Complements annotations without contradiction.

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

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

Two efficient sentences with front-loaded purpose. 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 simple tool with one param and no output schema, description fully covers purpose, access control, and side effects.

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 description adds limited value beyond schema. However, it reiterates the id comes from subscribe, which is mildly helpful.

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

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

Clearly states 'Cancel a subscription by id' with specific verb and resource. Distinguishes from sibling tools like 'subscribe' and 'list_subscriptions'.

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

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

Explicitly notes ownership enforcement, telling when to use (own subscriptions). No direct alternatives mentioned, but context is clear.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive, but the description adds substantial context: the distinction between could_not_verify (check did not happen, carrying verification_error) and unsupported (no source found), the warning not to treat could_not_verify as evidence, and the source routing details. This goes well beyond the structured 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 relatively long but packed with essential information: trigger phrases, purpose, routing, return values, and error-state caveats. The 'IMPORTANT for callers' section is critical for correct usage. Minor redundancy in the list of trigger phrases is acceptable given the overall density.

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 absence of an output schema, the description thoroughly explains what the tool returns (verdict enum, grounded/structured value, citation, reasoning) and clarifies the meaning and handling of error states. It also addresses the two execution paths, making it 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?

The input schema provides 100% coverage for both parameters, with thorough descriptions (including the tolerance_pct semantics and examples). The tool description adds no further parameter-specific detail beyond the claim examples already present in the schema, 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's function: natural-language claim verification against authoritative sources, with explicit trigger phrases ('fact check', 'verify the claim that…'). It distinguishes itself from sibling tools by focusing solely on claim verification and even contrasts with a multi-step manual pipeline it replaces.

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

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

The description explicitly says to use it whenever the agent needs to check whether something a user said is factually correct, and provides natural-language examples that signal when to invoke it. It does not explicitly name sibling tools as alternatives, but the internal routing logic (SEC EDGAR vs grounded pipeline) gives context for when it is applicable.

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, covering safety and idempotency. The description adds no behavioral context beyond what annotations provide, failing to add value.

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 short but lacks substantive content. It is not genuinely concise; it is under-specified and fails to convey useful 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 has parameters and likely an output schema, the description is incomplete. It does not mention any context about what the tool returns or how it behaves, leaving significant gaps 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?

Schema description coverage is 0%, and the description does not explain the parameters 'version' and 'module_path'. While parameter names are somewhat self-explanatory, the description adds no additional meaning or format requirements.

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

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

Description 'Version metadata.' is a tautology that restates the tool's name without specifying an action. It does not clarify what the tool does (e.g., retrieve, check, display). With many sibling tools like 'versions', this lacks differentiation.

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 provided on when to use this tool versus alternatives like 'versions'. The description gives no context for appropriate usage scenarios or 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, destructiveHint=false, and idempotentHint=true. The description adds no extra behavioral context (e.g., rate limits, constraints). It is consistent but does not surpass 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 extremely concise but lacks structure. While it avoids verbosity, it could be improved by adding a brief explanation of the parameter or result format.

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

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

Given a single required parameter and an existing output schema, the description is too minimal. It fails to describe what 'available versions' means, how the parameter is used, or any edge cases.

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 only parameter 'module_path' has no description in the schema (0% coverage) and is not explained in the tool description. The agent receives no semantic guidance beyond the parameter name.

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 'List available versions' clearly states the action (list) and the resource (versions). It is specific enough, though it does not differentiate from the sibling 'version_info' 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?

No guidance is provided on when to use this tool versus alternatives (e.g., version_info). The description lacks context about prerequisites or appropriate scenarios.

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