Performance Review

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

Adds context beyond annotations: default free model, BYO key for Anthropic with cost implication, return structure per model. Annotations already indicate idempotent and non-destructive. No contradictions. Could mention rate limits or failure behavior, but overall good disclosure.

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

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

Concise and well-structured: first sentence states purpose, second explains defaults and key, third describes output, fourth gives use cases. No fluff, each sentence adds value. Front-loaded with core 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?

Despite no output schema, description fully covers return values (per-model score, confidence, signals, raw_response + combined view). Addresses model selection, key requirement, and context disambiguation. Complete for an informational probe tool with no pagination or complex error states.

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

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

Schema coverage is 100%, so baseline is 3. Description adds practical meaning: e.g., explains the context parameter 'helps disambiguate common names', and for _apiKey clarifies 'BYO key — you pay Anthropic directly'. These go beyond schema descriptions, justifying a 4.

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

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

Description clearly states the tool probes LLMs for knowledge about an entity and returns a visibility score per model. Specific verb (probe) and resource (LLMs, entity) with a clear outcome (score 0-100). Distinguishes from siblings like 'scan_competitor_ai_presence' by focusing on generic brand/product/topic probing rather than competitor-specific 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 mentions use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. Also provides guidance on when to use the API key (only if probing Anthropic). However, no explicit alternatives or when-not-to-use compared to siblings, which deducts slightly.

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 mentions that Pipeworx picks the right tool and fills arguments, implying autonomous behavior, but since no annotations are provided, the description carries full burden. It lacks details on limitations, error handling, or data freshness.

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

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

The description is concise (3 sentences) with clear examples front-loaded. Every sentence adds value.

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

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

Given the simple single-parameter schema and no output schema, the description is adequate but lacks details on return format, confidence, or source attribution.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds that the parameter is a natural language question, which is already clear from the schema description. No additional semantic 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 accepts plain English questions and returns answers from the best data source, distinguishing it from sibling tools like discover_tools or recall which serve different purposes.

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

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

The description explains when to use it (asking natural language questions) and provides examples, but does not explicitly state when not to use it or mention alternatives among siblings.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds transparency on internal behavior: resolves market, classifies bet, fans out to packs, returns evidence packet and comparison. It does not contradict annotations, but lacks details on error handling or pack availability.

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 informative but somewhat lengthy (4 sentences). It front-loads the purpose and workflow, then lists use cases. Could be more concise, but 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?

Without an output schema, the description adequately explains the return value (evidence packet plus market-vs-model comparison). It covers the main workflow and outcomes, though details on pack selection criteria are minimal.

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

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

Schema coverage is 100%, but the description adds value by elaborating on the 'market' parameter (accepts slug, URL, or question text) and explaining the 'depth' parameter's quick vs thorough behavior. 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 researches a Polymarket bet by pulling Pipeworx data, and distinguishes it from siblings by specifying it's a one-call solution for bet context. The verb 'Research' and resource 'Polymarket bet' are specific and actionable.

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

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

Explicitly provides 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 when not to use (e.g., for general questions, use ask_pipeworx) by positioning itself as the core demo product for bet-related 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?

With no annotations, the description carries full behavioral burden. It discloses that the tool returns paired data and pipeworx:// resource URIs, and details the data provided for each type. While it doesn't cover potential errors, rate limits, or authorization needs, it sufficiently describes the key behavioral traits for a read/comparison tool.

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

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

The description is three sentences, front-loaded with the primary action (compare 2-5 entities side by side). Each sentence provides essential information: the allowed types and their data, the return format (paired data + URIs), and the efficiency gain (replaces sequential calls). No redundant or unnecessary text.

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

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

Given the tool has only 2 parameters and no output schema, the description does a good job explaining the input (type and values) and output (paired data with URIs). However, it lacks details on error handling (e.g., what if an entity is not found or invalid) and edge cases. Overall, it is adequate for typical 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?

The input schema has 100% coverage with descriptions for both parameters (type enum and values array). The description adds value by explaining what data is returned for each type, going beyond the schema's parameter-level descriptions. This helps the agent understand the semantics of the output, which is not documented in an output 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 2-5 entities side by side for two types (company and drug), specifying the data returned (revenue, net income, etc. for companies; adverse-event counts, FDA approvals, etc. for drugs). It also notes it replaces 8-15 sequential agent calls, implicitly distinguishing it from siblings that would do single entity queries.

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 when to use the tool: for comparing 2-5 entities in one call instead of multiple sequential calls. However, it does not provide explicit when-not-to-use conditions or name alternative tools for different scenarios (e.g., single entity query), but the context is clear enough for an agent to infer appropriate use.

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

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

With no annotations, the description carries the burden. It discloses the search behavior (returns most relevant tools with names and descriptions) but does not detail any side effects or limitations beyond what is stated.

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 efficiently conveying purpose and usage. Front-loaded with key action and result. 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 no output schema, the description explains what the tool returns ('tools with names and descriptions'), which is sufficient for a search tool. The sibling tools are diverse, so differentiation is clear.

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

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

The schema already covers both parameters with descriptions (100% coverage). The description adds the default and max for limit but not much else beyond schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Search' and resource 'Pipeworx tool catalog', clearly stating its purpose. It also differentiates from siblings by positioning itself as a tool discovery mechanism to be called first when many tools are available.

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 this tool ('Call this FIRST when you have 500+ tools available') and provides context for its purpose, guiding the agent to use it before other 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 provided, but description covers expected behavior: fetches multiple data sources, returns URIs, and notes a performance caveat for federal contracts. Could mention if it's read-only or any rate limits, but still transparent enough.

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?

Concise, well-structured sentences. Front-loaded with purpose, then details and caveats. 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?

Good for a profile tool with no output schema; mentions return of citation URIs. Could add more about response structure or pagination, but sufficient given complexity.

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

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

Schema coverage is 100%, and description adds meaning: explains value can be ticker or CIK, names not supported, suggests resolve_entity. Clarifies type is only 'company' for now.

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 for an entity, lists data sources (SEC, XBRL, patents, news, LEI), and replaces multiple calls. It distinguishes itself from siblings like resolve_entity and 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?

Provides clear when-to-use (comprehensive profile) and when-not (federal contracts, use usa_recipient_profile). Advises to use resolve_entity for names, and notes it replaces 10-15 sequential 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?

With no annotations provided, the description carries the full burden. It clearly states the tool deletes a memory, which is a destructive action, but does not disclose whether deletion is permanent, requires confirmation, or affects other data. The description is adequate but not rich in 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?

The description is a single, concise sentence with no wasted words. It is front-loaded with the action and target.

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

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

Given the tool's simplicity (1 required parameter, no nested objects, no output schema), the description is nearly complete. It could mention whether the key must exist or what happens if the key is not found, but overall it covers the essential action for a straightforward deletion tool.

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

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

Schema description coverage is 100%: the input schema already describes the 'key' parameter as 'Memory key to delete'. The description adds no additional semantic meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description uses a clear verb ('Delete') and specific resource ('stored memory by key'). It distinguishes from sibling tools like 'recall' and 'remember' which imply retrieval and storage respectively, making its purpose unmistakable.

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

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

The description implies usage (when you need to delete a memory) but does not provide explicit guidance on when not to use it or alternatives. Given siblings like 'recall' and 'remember', the description could mention that this tool is for deletion, not retrieval or storage, but it lacks 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about what the tool does (fetches, extracts, emits) without contradicting annotations. It does not detail potential side effects like rate limiting, but given the annotations provide a solid safety profile, the description complements them well.

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: first states core purpose, second describes the process and output, third lists specific use cases. Every sentence adds value, no fluff. Front-loaded with the key 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?

With 2 parameters, no output schema, and clear purpose, the description is largely complete. It describes the output as 'a single text blob' and explains the use cases. A slight improvement could be noting the output format more precisely, 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 the parameters are already well-documented. The description implicitly refers to them ('fetches the page' suggests url, 'link entries' suggests max_links) but adds no explicit meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb+resource ('Generate a production-ready llms.txt file') and clearly states the tool's function: fetching a page, extracting metadata, and emitting the standard format. It differentiates itself explicitly from sibling tools by not overlapping with any similar function like ai_visibility_check or scan_competitor_ai_presence.

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

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

The description provides explicit use cases: 'getting a client's site indexed by AI, drafting llms.txt for your own project, or auditing...'. It also indirectly indicates when not to use (e.g., if you don't need an llms.txt), giving clear context for appropriate usage.

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

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

No annotations are present, so the description carries full burden. It does not disclose side effects, authentication requirements, or any behavioral traits beyond stating it returns a complete review text. This is insufficient for a mutation-like 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 short (two sentences) and front-loaded with purpose, but the second sentence introduces misleading or missing parameter details, reducing effectiveness. It earns its place but could be more precise.

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 5 parameters including an enum and an output schema, the description is incomplete. It does not cover all inputs (e.g., role, rating, actual_performance) and provides no context on how the output schema relates to the returned text.

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%, and the description does not explain individual parameters. It mentions 'review period' and 'accomplishments' which are not schema properties, and the enum for rating is not described. The description fails to compensate for the lack of property 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?

Description states 'Generate a formatted performance review document' which is clear verb+resource, but mentions inputs like 'review period' and 'accomplishments' that do not exactly match the schema properties (e.g., actual_performance, what_manager_wants_to_say). This mismatch reduces clarity and could mislead the agent about expected parameters.

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 siblings like entity_profile or feedback. The description only lists inputs but fails to provide context for appropriate usage 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?

With no annotations provided, the description carries full burden. It discloses rate limiting ('5 messages per identifier per day') and that it is free. It explains content guidelines (describe in terms of Pipeworx tools/data, avoid verbatim prompts). No contradictions noted.

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 states purpose, second provides usage guidelines, third mentions rate limit. It is front-loaded and contains no unnecessary words, making it easy to read and understand.

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 without an output schema and with clear input parameters, the description is fully adequate. It covers purpose, usage, constraints, and content rules, leaving no ambiguity 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?

The input schema has 100% coverage with detailed descriptions for all parameters. The description adds rate-limit and free information but does not enhance understanding of parameter meaning beyond the schema. Baseline of 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool's purpose: 'Send feedback to the Pipeworx team.' It lists specific use cases (bug reports, feature requests, missing data, praise) and distinguishes itself from sibling tools like ask_pipeworx (for queries) and discover_tools (for 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 specifies when to use the tool (for feedback types) and provides a negative guideline: 'do not include the end-user's prompt verbatim.' It also mentions rate limits. However, it does not explicitly state when not to use it or suggest alternatives for other purposes, though the sibling context implies appropriate use.

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

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

Annotations already indicate safe read-only idempotent behavior. The description adds valuable context: data source (CF analytics-engine), no PII, caching duration (5min-1h), and aggregated nature. 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?

Approximately 100 words, front-loaded with purpose, then bulleted use cases, then technical details. No superfluous 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?

For a single-parameter tool with no output schema, the description covers purpose, use cases, parameter, caching, and data source. No obvious gaps.

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

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

Schema coverage is 100%, but the description adds semantic meaning for the 'window' parameter (hot vs steady-state, default 24h), going beyond enum values.

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

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

The description clearly states the tool returns top tools, packs, and call volume over a window, with specific use cases. It distinguishes from siblings by focusing on aggregate agent behavior.

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

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

Three explicit use cases are listed, and window length guidance is given. However, it does not explicitly state when not to use this tool or mention alternatives by name.

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

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

The description discloses the internal logic (walking child markets, extracting dates/thresholds, sorting) and return format (list of entries). Annotations already indicate readOnlyHint and openWorldHint, and the description adds valuable behavioral context beyond them.

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

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

The description is thorough and well-structured, explaining concept, method, and output. While slightly verbose, each sentence adds value, and it remains informative without redundancy.

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

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

Despite lacking an output schema, the description specifies the return format and fields. The logic and input are fully covered, making the tool's behavior complete and understandable for an agent.

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

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

The single parameter is fully described in the schema with an example. The description adds how the parameter is used (event slug or full URL) and its role in the tool's logic, exceeding 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 finds arbitrage opportunities in Polymarket events via monotonicity violations, with concrete examples of price ordering. It distinguishes from sibling tools like 'polymarket_edges' by its specific purpose.

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

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

The description explains the condition for usage (price ordering violations) and the input (event slug or URL). It does not explicitly exclude usage cases or mention alternative tools, but 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 provide readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds significant context: groups by asset, fetches price history once, computes model probability per market, ranks by |edge|, and suggests trade direction. 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, information-dense paragraph. It front-loads the purpose and efficiently explains the algorithm and output 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?

No output schema exists, but the description explains return format (ranked edges with trade direction). It covers scope, model, and usage scenario, making it complete for a tool returning a list of opportunities.

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 good parameter descriptions. The description adds only general process context (e.g., 'returns top N') but no parameter-specific semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states it scans Polymarket markets to find where Pipeworx data disagrees with market price, returns top edges for betting. It specifies scope (crypto-price bets) and method, distinguishing it from siblings like 'polymarket_arbitrage' and 'bet_research'.

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

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

The description explicitly says it's built for the 'what should I bet on today' question and avoids manual paging. While it doesn't compare to alternatives, the context implies it's for initial opportunity scanning. A clear when-to-use is present.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that it returns leg prices and spreads, but does not disclose additional traits like rate limits or authentication requirements. Minimal value added beyond annotations.

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

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

The description is well-structured with a short introduction, two clear modes, and return format. It is slightly verbose but front-loads the core purpose. Each section earns its place.

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

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

No output schema exists, so the description adequately explains return values (leg prices and spread). Given the tool's complexity (two venues, two modes), the description is complete and leaves no ambiguity about inputs or 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?

The schema already has 100% coverage for all three parameters. The description adds context on how topic and explicit parameters interact (override logic) and the format expectations, which provides meaningful additional guidance.

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

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

The description clearly identifies the tool as a cross-venue spread calculator between Kalshi and Polymarket, specifically highlighting the arbitrage signal. It distinguishes itself from sibling tools like polymarket_arbitrage by focusing on inter-venue spreads.

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 pre-mapped topic mode versus explicit tickers, and implies use for arbitrage detection. However, it does not explicitly state when not to use this tool or compare it to alternatives like 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?

No annotations provided, so description carries full burden. Describes behavior: retrieves by key or lists all. Could add more about data persistence or scope, but sufficient for typical use.

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?

Very concise: two sentences, front-loaded with key action, no wasted words. Effectively conveys functionality.

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

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

Given low complexity (1 optional param, no output schema), description is complete enough. Explains both retrieval modes and use case.

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 description adds value by explaining the effect of omitting the key. However, it doesn't add extra details 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 the tool retrieves stored memories by key or lists all memories when key is omitted, distinguishing it from related tools like 'remember' (write) and 'forget' (delete).

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

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

Explicitly says to use for retrieving context saved earlier, and mentions omitting key to list all. Does not explicitly mention when not to use, 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?

With no annotations, the description carries full burden. It discloses the parallel fan-out, accepted date formats (ISO and relative), and return structure (structured changes, total_changes count, pipeworx:// URIs). It lacks explicit mention of being read-only, but the context makes it clear.

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

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

The description is two sentences long, front-loaded with purpose, and uses bullet-like structure for details. Every part is necessary and informative, 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 no output schema, the description explicitly states what is returned: structured changes, total_changes count, and pipeworx:// URIs. It covers inputs, behavior, and output sufficiently for agent decision-making, even for a moderately complex tool with multiple data sources.

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

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

Schema coverage is 100% and each parameter has a description, but the description adds valuable context: suggests default relative formats ('30d', '1m') for 'since' and gives examples of ticker and CIK for 'value'. 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 'What's new about an entity since a given point in time' and then details the specific behavior for company type, including parallel fan-out to SEC EDGAR, GDELT, USPTO. It distinguishes itself from sibling tools by focusing on recent changes across multiple sources.

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

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

Explicit guidance is given: 'Use for "brief me on what happened with X" or change-monitoring workflows.' It also implies when to use via the supported entity type and date formats. However, it does not explicitly mention when not to use or compare to alternatives like entity_profile.

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

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

With no annotations provided, the description effectively covers key behavioral traits: it stores data, session memory, and persistence rules (authenticated vs anonymous). It does not mention any destructive behavior or limitations like key uniqueness or overwrite behavior, but the core transparency is solid.

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, each adding unique value: first defines what the tool does and when to use it, second clarifies persistence rules. No wasted words; highly front-loaded.

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

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

Given the tool's simplicity (2 string params, no output schema, no annotations), the description is complete enough: it explains storage mechanism, use cases, and persistence. It could mention overwrite behavior or key collision, but that is not essential for a basic key-value store.

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 with descriptions for both 'key' and 'value'. The description adds value by explaining the purpose of the tool and providing example keys ('subject_property', 'target_ticker'), which helps the agent choose appropriate keys. It does not repeat schema info but augments it.

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

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

The description clearly states the verb 'Store', the resource 'key-value pair in your session memory', and the purpose 'save intermediate findings, user preferences, or context across tool calls'. It effectively distinguishes from siblings like 'recall' and 'forget' by specifying the write operation.

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

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

The description provides explicit context on when to use ('save intermediate findings, user preferences, or context') and notes persistence differences for authenticated vs anonymous users. However, it does not explicitly say when not to use or name alternatives like 'recall' or 'forget', though the distinction is implied.

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?

In the absence of annotations, the description fully discloses the read-only nature (returns IDs and URIs), input constraints (v1 only company), and output fields (ticker, CIK, name, URIs). It omits details like authentication or rate limits but is sufficient for a simple lookup 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?

Two efficient sentences: first defines purpose and scope, second details input/output and benefit. Every word earns its place; no fluff or redundancy.

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

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

For a tool with 2 parameters and no output schema, the description covers input format, output format, versioning, and efficiency gain. It is complete and leaves no obvious gaps for an AI agent to understand 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%, but the description adds substantial value: it explains the v1 versioning, clarifies that 'value' accepts ticker, CIK, or name, provides concrete examples (AAPL, etc.), and describes the return values 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 resolves an entity to canonical IDs, specifies v1 supports type='company', and lists accepted value formats (ticker, CIK, name). It distinguishes itself by noting it replaces 2-3 lookup calls, making the purpose specific and actionable.

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 context by explaining when to use (to get canonical IDs efficiently) and the benefit (replaces multiple calls). However, it does not explicitly state when not to use or compare against sibling tools like ask_pipeworx or discover_tools, leaving some ambiguity.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds value by explaining the internal use of ai_visibility_check, the ranking logic, and the output fields (score, confidence, signal density). 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 composed of 5 sentences that are front-loaded with the main action. It is concise with no redundant information. However, it could be slightly more compact without losing clarity.

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 explains the return value (ranked list with score, confidence, signal density) and the process (probing with ai_visibility_check). It also notes the first entity as subject. This is fairly complete, though it could detail the output format more precisely.

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 semantics by explaining that the first entity in the 'entities' array is treated as the subject and that 'workers-ai' is the free default for 'models'. This provides clarity 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 compares AI visibility across multiple entities, probes each with ai_visibility_check, ranks by score, and surfaces most/least recognized. It uses a specific verb ('compare') and resource ('AI visibility across multiple entities') and distinguishes itself from sibling tools like ai_visibility_check (single entity) and compare_entities (generic comparison).

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

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

The description provides a clear use case: 'competitive AI-marketing audits: does Claude know about us as well as our competitors?' It implies when to use this tool over ai_visibility_check (when comparing multiple entities). However, it does not explicitly state when not to use it or mention alternatives like 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It details the return values (verdict, structured form, actual value with citation, percent delta) and discloses that this replaces multiple agent calls. It also notes the v1 limitation. However, it omits error handling or rate limit information, which is acceptable for the scope.

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

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

The description is two sentences long, front-loaded with the purpose, and every phrase adds value. It is highly concise and structured efficiently 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 complexity of the tool and the lack of an output schema, the description covers the input format, output details, and supported domain well. It could be more complete by discussing error scenarios, but overall it is sufficient for an agent to 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 description coverage is 100%, so the baseline is 3. The tool description does not add additional parameter meaning beyond the example in the schema. The example is helpful but not transformative, so a 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 that the tool fact-checks natural-language claims against authoritative sources, specifically company-financial claims for US public companies, and lists the types of verdicts returned. This is a specific verb+resource combination that distinguishes it from siblings like 'compare_entities' or 'entity_profile'.

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

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

The description specifies that the tool is for company-financial claims in v1, giving clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives for unsupported claim types, which prevents a perfect score.

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