Fred

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint false) are not contradicted. The description adds behavioral context: cost implications for Anthropic (BYO key), default free model, and return structure. It could mention that results may vary based on model knowledge, but it adequately discloses the probe nature.

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

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

The description is concise, with no unnecessary words. It front-loads the purpose and key details (default model, optional Anthropic) in the first sentence, then elaborates on return values and use cases. Every sentence adds value.

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

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

Given no output schema, the description specifies the return structure: per-model {score, confidence, signals, raw_response} + combined view. It covers all 4 parameters, explains optional keys, and provides enough context for an agent to understand inputs and outputs. The tool is not overly complex, and the description feels complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that models default to workers-ai, _apiKey is only needed for Anthropic, and context helps disambiguate. This goes beyond schema descriptions, providing usage semantics effectively.

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

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

Description clearly states the tool probes LLMs for brand/product knowledge and scores visibility (0-100). It specifies the default model and optional Anthropic probing. The verb 'probe' combined with resource 'LLMs' and outcome 'score visibility' makes purpose very specific. It differentiates from siblings like 'scan_competitor_ai_presence' by being more general and offering multiple model probes.

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 outlines use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It provides guidance on when to include _apiKey (for Anthropic probes) and default model behavior. However, it does not explicitly state when not to use this tool or compare it to sibling tools like 'scan_competitor_ai_presence' for specific competitor analysis.

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?

With no annotations, the description carries the full burden. It states that Pipeworx 'picks the right tool, fills the arguments, and returns the result', which discloses the autonomous behavior. However, it does not mention potential latency, fallback behavior if no tool matches, or any limits on question complexity.

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

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

The description is concise at 3 sentences with front-loaded purpose. The examples add value but could be seen as slightly excessive. Overall, it's well-structured and earns its length.

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

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

Given low complexity (1 param, no nested objects, no output schema), the description is reasonably complete. It explains the tool's core function and usage. However, it could mention that the answer might come from multiple internal tools and that results are not cached or revisitable.

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 description need not add much. The description explains the 'question' parameter as 'your question or request in natural language', which is slightly more informative than the schema's description, but adds little extra 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's purpose: ask a natural language question and get an answer from the best data source. It distinguishes itself by not requiring tool or schema knowledge, unlike sibling tools like fred_search or discover_tools which are more structured.

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

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

The description gives clear usage guidance: ask in plain English, no need to browse tools or learn schemas. It provides three concrete examples, which implicitly suggest when to use this tool over more specific tools like fred_series_info or fred_search.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds context by explaining the tool resolves the market, classifies the bet type, fans out to relevant packs, and returns an evidence packet with market-vs-model comparison. This goes beyond annotations without contradiction.

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

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

The description is moderately long but well-structured, front-loading the main purpose. Each sentence adds value, explaining the fan-out logic and use cases. Minor redundancy exists, but overall it's efficient for the 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?

Given the tool's complexity (classification, fan-out, comparison) and the lack of an output schema, the description is remarkably thorough. It explains the process, output format (evidence packet, comparison), and provides examples of pack combinations. Nothing essential is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the depth enum values ('quick = 2-3 evidence sources, thorough = full fan-out') and clarifying that the market parameter accepts slug, URL, or question text. This enhances understanding 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 researches Polymarket bets by pulling Pipeworx data in one call. It specifies the input formats (slug, URL, question text) and distinguishes itself from potential siblings by emphasizing it's the core demo product for bet context, avoiding the need for pack discovery.

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: 'should I bet on X?', 'what does the data say about this Polymarket market?', 'is there edge in this bet?'. It also implies superiority over manual pack discovery, though it doesn't explicitly exclude alternative tools like ask_pipeworx.

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 that tool returns paired data with pipeworx:// URIs and cites data sources (SEC EDGAR for company, FDA for drug), but could mention that it is read-only with no destructive effects.

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

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

Three concise sentences front-load purpose and provide all essential information without 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?

Description adequately covers tool functionality, data sources, and usage context; missing output schema is compensated by mentioning return types (paired data, URIs).

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?

Adds meaningful context beyond schema: explains how 'type' maps to different data fields and provides examples for 'values' format, enhancing schema coverage.

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

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

Description clearly states the tool compares 2-5 entities side by side, specifies data fields for company and drug types, and distinguishes from sibling tools by its unique comparison functionality.

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

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

Description implies usage for efficient comparisons by replacing 8-15 sequential calls, but does not explicitly state when not to use it or provide alternatives.

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

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

With no annotations provided, the description must cover behavioral traits. It mentions it returns 'most relevant tools with names and descriptions', but does not disclose details like performance, ordering, or any side effects. However, as a search tool, side effects are minimal, so a score of 3 is adequate.

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

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

Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

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

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

Given no output schema, the description explains what is returned ('names and descriptions'), and for a simple search tool, this is complete. The context of 500+ tools is addressed, and the instruction to call it first ensures proper workflow.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond the schema, but the schema already provides good descriptions for both parameters. No additional value added.

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 ('Search') and resource ('Pipeworx tool catalog'), clearly stating what the tool does. It distinguishes itself from siblings by positioning itself as a discovery tool for the catalog, which is unique among the sibling tools like fred_search or ask_pipeworx.

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

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

Explicitly states when to use it ('Call this FIRST when you have 500+ tools available'), implying it is a prerequisite for selecting other tools. Provides a clear instruction to the agent, effectively guiding its 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?

No annotations provided, so description carries full burden. It discloses return format (pipeworx:// URIs) and efficiency benefit (replaces 10-15 calls), but doesn't explicitly state read-only or potential errors. However, the context implies safe data retrieval.

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

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

Two sentences with key details, plus a third for the exception. No redundant words; front-loaded 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 no output schema, description lists included data types and format. Mentions exception for federal contracts. Lacks specifics on error handling or edge cases, but adequate for a profile 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?

Input schema has 100% coverage with descriptions, but the description adds value: clarifies that 'value' accepts ticker or CIK but not names, and recommends resolve_entity for names. This goes 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 explicitly states it returns a 'full profile of an entity across every relevant Pipeworx pack', listing specific data types (SEC filings, revenue, patents, news, LEI) and distinguishes from siblings like resolve_entity.

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

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

Clearly indicates when to use (comprehensive profile) and provides a direct alternative: 'For federal contracts call usa_recipient_profile directly (too slow to bundle).' Also implies using resolve_entity first for names.

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?

No annotations provided, so description carries full burden. It states deletion but omits details on irreversibility, side effects, or error handling. Agent needs more behavioral context.

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

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

Single sentence, no wasted words, front-loaded with action 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?

Simple tool with one param and no output schema, but description lacks important behavioral details like permanence or permission requirements, which would improve completeness.

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

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

Schema coverage is 100%, so schema already documents the key parameter. Description adds no further meaning beyond the schema description.

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

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

Description uses specific verb 'Delete' and resource 'stored memory by key', clearly distinguishing from sibling tools like 'recall' and 'remember'.

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

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

No explicit when-to-use or alternatives mentioned, but context implies deletion is for removing specific memories; sibling names provide implicit differentiation.

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

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

No annotations are provided, so the description carries the burden. It implies a read-only operation (browsing) but doesn't disclose return format, pagination, or any rate limits. Since it's a simple browse operation with no destructive actions, the lack of detail is acceptable but not ideal.

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 two sentences, with the key information front-loaded. Every sentence provides valuable guidance, including examples.

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

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

Given the low complexity (2 params, no output schema, no nested objects), the description is sufficient. It explains the tool's purpose and usage, though it could mention that it returns child categories or series count, but it's not critical.

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 both parameters are documented. The description adds context that category_id=0 is the root and provides example IDs, but doesn't add meaning beyond the schema's descriptions.

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

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

The description clearly states 'Browse FRED categories' and specifies the root category ID, distinguishing it from siblings like fred_get_series and fred_search. It provides specific examples of category IDs for popular topics, making the purpose very clear.

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

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

The description gives explicit usage guidance: start with category_id=0 for the root, and suggests using it for exploring available data by topic. However, it doesn't explicitly state when not to use it or mention alternatives, though siblings like fred_search are distinct.

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 does not detail behavioral traits beyond fetching observations. Annotations are empty, so no contradiction. The description adds value by listing example series IDs, but does not disclose rate limits, data scope, or potential errors.

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

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

The description is concise, with a clear first sentence stating the purpose, followed by a list of key series IDs. It is front-loaded and efficient, though the list could be shortened or referenced via the schema.

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

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

Given the tool's complexity (6 parameters, no output schema, no annotations), the description is adequate but incomplete. It does not explain the output format or what observations entail, which could be critical for an agent. The list of series IDs is helpful but not essential.

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

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

Input schema has 100% coverage with descriptions for all parameters. The description does not add additional meaning beyond the schema, as it only mentions series IDs and lacks parameter details. Baseline 3 applies.

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

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

The description clearly states the tool gets observations/data points for a FRED series, which is a specific verb-resource combination. It lists key housing series IDs, distinguishing it from other FRED tools like fred_search or fred_series_info.

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

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

The description implies usage for retrieving time series data, especially housing series, but does not explicitly state when to use this tool versus alternatives like fred_series_info (which returns metadata). No exclusions or conditions are provided.

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

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

Annotations are empty, so description carries full burden. It states 'latest FRED data releases' and shows 'upcoming and recent' but doesn't disclose pagination behavior, rate limits, data staleness, or any side effects. Minimal disclosure beyond basic purpose.

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?

Short and direct (two sentences), but could be slightly more specific. 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?

Tool has 3 parameters (1 required) and no output schema. Description is sufficient for basic understanding but lacks details on return format or error handling. With no output schema, agent may benefit from knowing what fields are returned.

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 parameters are well-documented in schema. Description adds no extra meaning beyond schema, so baseline 3 is appropriate.

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

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

Description clearly states it gets FRED data releases, specifically 'upcoming and recent releases of economic data'. The verb 'get' and resource 'releases' are clear, but it doesn't differentiate from siblings like fred_category or fred_search, which have different purposes.

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

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

No guidance on when to use this vs alternatives. Sibling tools exist for categories, series info, and search, but description doesn't indicate when releases is preferred.

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?

No annotations are provided, so the description carries the burden. It mentions the tool is for searching by keyword, which is clear, but does not disclose limitations like pagination, rate limits, or authentication requirements beyond what the schema implies.

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

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

Two concise sentences that front-load the main purpose and provide useful examples. 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 complexity (5 params, no output schema, no annotations), the description is complete enough for a search tool. It could mention that results include series IDs for further use with fred_get_series, but overall adequate.

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 parameters are well-documented in the schema. The description adds context by providing example search terms ('mortgage rate'), but does not add 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 states a specific verb ('Search') and resource ('FRED series'), and the examples of data types ('housing, employment, inflation') distinguish it from sibling tools like fred_get_series and fred_series_info.

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

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

The description implies usage for discovering series IDs, but does not explicitly contrast with other FRED tools (e.g., fred_category for browsing by category). No explicit 'when not to use' guidance.

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

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

No annotations provided, so description must carry full burden. It correctly implies read-only behavior by stating 'Get metadata'. However, does not disclose API rate limits or potential errors (e.g., invalid series_id).

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

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

Single sentence front-loads the action and lists key metadata fields concisely. No wasted words. Could be split into two sentences for 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 no output schema, description hints at return fields but not structure (e.g., JSON format). With only 2 simple params and a clear purpose, it is mostly adequate but leaves some ambiguity about response details.

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

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

Schema coverage is 100% (both parameters described). Description does not add new parameter info beyond schema, but schema already describes them adequately. 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?

Description clearly states it retrieves metadata (title, units, etc.) for a FRED series, distinguishing it from siblings like fred_get_series (likely returns values) and fred_search (finds series).

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

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

No guidance on when to use this vs. fred_get_series or fred_category. No mention of prerequisites (e.g., need an API key) beyond schema. Does not specify that it's a lightweight info call.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. Description adds behavioral detail: 'Fetches the page, extracts title/description/key links, and emits the standard format.' No contradictions. Adds 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?

Three sentences, front-loaded with the core action and purpose. Every sentence provides essential information. No redundant or trivial content.

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

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

Given simple tool with two well-documented parameters and annotations covering safety, the description fully explains tool function, output format, and use cases. No output schema required as output is described as a text blob.

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

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

Input schema has 100% coverage with clear descriptions for both 'url' and 'max_links' parameters. Description does not add significant meaning beyond schema; baseline 3 applies.

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

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

Description clearly states the tool generates a production-ready llms.txt file for any URL, with a specific verb ('generate') and resource ('llms.txt file'). It distinguishes from sibling tools by focusing on AI crawler indexing, a unique function among unrelated siblings.

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

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

Explicitly lists use cases: getting a client's site indexed, drafting for own project, auditing competitor's AI visibility. Lacks explicit when-not-to-use or alternatives, but context is clear and practical.

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?

With no annotations provided, the description carries the full burden. It discloses the rate limit (5 messages per identifier per day) and provides important usage instruction (not to include end-user prompt). This gives the agent necessary behavioral context for a feedback tool.

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

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

The description is two sentences, front-loading the purpose and immediately providing usage guidelines and rate limit. Every sentence adds value with zero waste.

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

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

For a simple feedback tool with no output schema, the description covers all essential aspects: what it does, how to structure feedback, rate limit, and privacy guidance (avoiding end-user prompt). It feels complete for the agent's invocation needs.

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

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

Schema description coverage is 100%, with each parameter having a clear description. The tool description does not add additional meaning beyond the schema, so the 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 action ('Send feedback to the Pipeworx team') and the resource (Pipeworx team), and lists specific use cases (bug reports, feature requests, missing data, praise) distinguishing it from sibling tools.

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

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

The description provides explicit guidance on when to use the tool (bug reports, feature requests, etc.) and what content to include ('Describe what you tried in terms of Pipeworx tools/data — do not include the end-user's prompt verbatim'). It also mentions rate limiting. While it doesn't specify when not to use it, 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 mark the tool as read-only and non-destructive. The description adds valuable behavioral context: the two-mode operation, search and grouping logic, and output of ranked opportunities with reasoning. This goes beyond the annotation-provided safety profile.

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

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

The description is a single, well-structured paragraph. It front-loads the main purpose, then concisely explains each mode with examples and cross-event nuances. Every sentence is informative and necessary, with no redundant 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?

The description covers the tool's purpose, two modes, use case differentiation, and output. It is nearly complete for an agent to use correctly. However, it does not explicitly state that only one parameter should be provided at a time (both are optional in schema), which is a minor ambiguity.

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

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

Input schema coverage is 100% with descriptive parameter details. The description expands on these by explaining the two modes and use cases, but the schema descriptions already convey the same information. Thus, the description adds modest extra 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: 'Find arbitrage opportunities on Polymarket by checking for monotonicity violations across related markets.' It specifies two modes with examples, making the functionality distinct. However, it does not explicitly distinguish itself from sibling tools like 'polymarket_edges', which is a minor gap for top marks.

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 guidance on when to use each mode (event vs. topic) with concrete examples, including a cross-event scenario that single-event mode misses. It lacks explicit direction on when not to use the tool or alternatives, but the mode-specific context is strong.

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

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

The description goes beyond annotations by explaining the process: lognormal model from FRED, live coinpaprika price, grouping by asset, computing model probability, ranking by edge magnitude, and returning top N with suggested trade direction. No annotation contradictions.

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

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

The description is well-structured with a clear first sentence, detailed process flow, and usage context. It is moderately concise but could be slightly tighter.

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 the tool (scanning, grouping, fetching, computing, ranking), the description covers all essential behavioral and output aspects. No output schema, but return format is described sufficiently.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds default values and the max limit for limit, but not much beyond the schema. 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 verb and resource: 'Scan the highest-volume Polymarket markets and return the ones where Pipeworx data disagrees most with the market price.' It specifies the model, inputs, and output, making it distinct from siblings like polymarket_arbitrage.

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 the intended use: 'Built for the what should I bet on today question — agents/users discover opportunities without paging through hundreds of markets by hand.' This gives clear context, though it doesn't mention when not to use or list alternative tools.

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

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

No annotations are provided, so the description must fully describe behavior. It states the tool retrieves or lists memories, which is adequate. However, it doesn't mention side effects, persistence, or limits, which would be helpful.

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 action, and contains no unnecessary words. Every sentence adds value.

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

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

Given the simple schema and no output schema, the description covers the tool's function well. It could mention return format or error handling, but for a simple memory retrieval tool, it is sufficiently complete.

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

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

Schema coverage is 100% with one parameter described. The description adds value by explaining that omitting the key lists all memories, which goes beyond the schema's description of 'omit to list all keys' by clarifying the use case.

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 memory by key or lists all memories when key is omitted. It specifies the verb 'retrieve' and resource 'memory', and distinguishes itself from sibling tools like 'remember' and 'forget'.

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

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

The description says to use it to retrieve context saved earlier, which provides clear context. However, it does not explicitly mention when not to use it or alternatives among siblings, but the context is sufficient.

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

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

With no annotations, the description must disclose behavior. It explains that for type='company' the tool fans out to three sources in parallel, returns structured changes, total_changes count, and URIs. It also details the 'since' parameter format. It lacks info on auth or rate limits, but the parallel execution is well communicated.

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: first sentence states purpose, second describes functionality for the supported type, third explains parameters and output. It is concise, front-loaded, and every sentence adds essential information.

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

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

Given the tool's complexity (parallel fan-out, no output schema), the description adequately explains the output structure (structured changes, count, URIs). It does not address pagination or result limits, but for a change-monitoring tool, this is 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%, so the description adds limited value. It gives examples for 'since' (ISO vs relative) and notes typical values like '30d', but these are already in the schema description. For 'value', it only adds 'ticker or CIK' which is implied.

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: 'What's new about an entity since a given point in time.' It specifies the entity type (company) and the sources consulted (SEC EDGAR, GDELT, USPTO). This distinguishes it from sibling tools like 'entity_profile' or 'compare_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 description provides clear guidance: 'Use for "brief me on what happened with X" or change-monitoring workflows.' This gives a strong sense of when to use the tool, though it does not explicitly compare with alternatives 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?

No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: memory persistence depends on authentication (authenticated users get persistent, anonymous sessions last 24 hours). This is valuable context beyond the basic storage action.

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 concise sentences with no wasted words. It front-loads the purpose, then usage examples, then behavioral context. Every sentence adds value.

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

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

The description is complete for a simple key-value store tool with two well-documented parameters and no output schema. It explains purpose, usage, and persistence behavior. Could optionally mention that value is overwritten on same key, but not essential.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema's descriptions of 'key' and 'value'. The examples in the schema ('subject_property', etc.) already cover semantics well.

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 'Store a key-value pair in your session memory' which clearly identifies the verb (store) and resource (session memory). It distinguishes itself from siblings like 'recall' and 'forget' by mentioning 'save' and 'session memory', though not explicitly naming the 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?

The description explains when to use the tool ('to save intermediate findings, user preferences, or context across tool calls'), providing clear context for usage. However, it does not explicitly state when not to use it or mention alternative tools like 'recall' for retrieval.

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?

No annotations are provided, so the description carries full burden. It discloses return values (ticker, CIK, company name, URIs) and states it's a single call. However, it does not discuss error handling, what happens if the entity is not found, or any side effects. Given the tool is a read-only lookup, the description is adequate but not exhaustive.

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 that efficiently convey purpose, usage, example inputs, return values, and benefit. Every sentence earns its place with 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 tool with two parameters, no output schema, and no annotations, the description covers purpose, usage, return values, and benefit. It mentions version and v1 limitation, making it complete for the agent to decide when to use.

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

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

Schema description coverage is 100% (both parameters have descriptions). The description adds some context by repeating the enumeration and examples, but does not provide new information beyond the schema. Baseline 3 is appropriate as schema already documents the parameters well.

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 resolves an entity to canonical IDs across Pipeworx data sources in a single call. It specifies the verb (resolve), resource (entity), and context, with concrete examples for company type. It implicitly distinguishes from siblings by focusing on entity resolution, which is distinct from FRED or memory tools.

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

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

The description mentions that it replaces 2-3 lookup calls, indicating when to use for efficiency. It also notes v1 supports 'company' type, scoping usage. However, it does not explicitly state when not to use or mention alternatives beyond the implicit replacement of lookup calls.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the tool is known to be safe and read-only. The description adds behavioral context beyond annotations: it probes each entity with ai_visibility_check, ranks results, and surfaces scores with confidence and signal density. No contradiction.

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

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

The description is four sentences with clear structure: purpose, mechanism, use case, output. No redundant information; every sentence adds value.

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

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

There is no output schema, but the description mentions returns a ranked list with score, confidence, signal density per entity. The parameters and behavior are well covered. For a tool with 4 parameters and no output schema, the description is sufficiently complete.

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

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

Schema description coverage is 100%, so each parameter is documented. The description adds extra meaning, e.g., 'First entry treated as the subject' and explains the relationship between models and _apiKey. This provides useful context beyond the schema.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, using ai_visibility_check probes, ranking scores, and surfacing most/least recognized. It distinguishes from sibling ai_visibility_check and explicitly mentions 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 indicates the tool is useful for competitive AI-marketing audits, giving a concrete question ('does Claude know about us as well as our competitors?'). It implies when to use but does not explicitly state when not to use or provide alternative tools.

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

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

With no annotations, the description carries full burden. It fully discloses the tool's behavior: it's a read-only verification using SEC EDGAR + XBRL, outputs a verdict with citation and delta, and is limited to financial claims. No destructive actions or hidden behaviors are indicated.

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 adding distinct value: purpose, specific outputs, and comparative efficiency. No redundant or filler content.

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

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

Although there is no output schema, the description thoroughly explains all return values (verdict types, structured form, citation, delta). It also specifies the domain, data source, and the composite nature, making the tool fully understandable for an AI 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 100% and already explains the 'claim' parameter. The description adds clarifying examples ('Apple's FY2024 revenue...') and specifies it must be a natural-language claim, reinforcing semantics beyond the schema.

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

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

The description clearly states the tool fact-checks natural-language claims, specifies it supports company-financial claims for public US companies via SEC EDGAR+ XBRL, and lists exact outputs. It differentiates from siblings like ask_pipeworx by being a specialized, composite fact-checking tool.

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

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

The description explicitly states the domain (company-financial claims) and notes it replaces 4-6 sequential agent calls, implying it should be used for financial fact-checking instead of multi-step approaches. However, it does not directly contrast with siblings or give when-not-to-use scenarios.

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