Tides

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

Disclosures go beyond annotations: explains costs for Anthropic, direct API key passing, and return fields (score, confidence, signals, raw_response). No contradiction with annotations (readOnlyHint, openWorldHint, idempotentHint).

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

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

Four sentences, each adding unique information: purpose and output, model options, return structure, use cases. No redundancy or fluff.

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

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

Complete enough for this tool: covers purpose, parameters, return fields, and use cases. Could mention any rate limits or limitations, but not essential. Output schema absence is partially compensated by description of return fields.

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

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

Schema has 100% coverage, providing good parameter descriptions. Description adds value by explaining the default free model and that Anthropic requires a BYO key and incurs costs, which is not in the schema.

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

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

Description clearly states the tool probes LLMs for entity knowledge and scores visibility per model. It lists use cases (audits, brand checks, monitoring) and distinguishes itself from siblings like 'scan_competitor_ai_presence' by focusing on multiple models and scoring.

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 (visibility audits, brand checks) and provides context on default vs paid models. However, it does not mention when not to use or suggest 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?

The description discloses that the tool 'picks the right tool, fills the arguments, and returns the result,' indicating autonomous decision-making. Since no annotations are provided, the description carries full burden, but it lacks details on limitations, potential errors, 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) and front-loaded with the main action. It includes examples for clarity, though the examples could be slightly more integrated.

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 input schema (one string parameter) and no output schema, the description adequately explains the tool's behavior. It covers the purpose, usage, and example queries, leaving little 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?

Schema coverage is 100% and the parameter description is clear ('Your question or request in natural language'). The description adds value by explaining how the parameter is used (e.g., 'just describe what you need' with examples), but it doesn't add substantial semantic detail 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: it answers plain English questions by selecting the best data source. It distinguishes itself from other tools by centralizing access to multiple sources, and it explicitly mentions that users don't need to browse tools or learn schemas, which contrasts with sibling tools like discover_tools or list_stations.

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 the tool: 'just describe what you need' and provides examples. However, it does not explicitly state when not to use it or mention alternative tools for specific scenarios.

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

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

Annotations already indicate readOnlyHint and destructiveHint false, so the description correctly implies no side effects. It adds detailed behavior: market resolution, classification, fan-out to packs, and output format (evidence packet + comparison). This goes beyond annotations to provide a clear mental model of the tool's operation.

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 lengthy but each sentence serves a purpose: main action, input format, detailed process, use cases, and value statement. It is front-loaded with the primary function. Minor redundancy with schema descriptions and a marketing sentence could be trimmed, but overall it is well-structured.

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

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

Given the tool's moderate complexity (2 params, no output schema), the description adequately covers the return format ('evidence packet plus market-vs-model comparison') and the fan-out logic. It does not explain potential size limits or the structure of the evidence packet, but for an agent the description is sufficient to understand the tool's purpose and basic output.

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

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

Both parameters (market, depth) are fully described in the input schema, achieving 100% coverage. The description repeats this info without adding new meaning. Per guidelines, baseline is 3 when schema description coverage is high, and the description does not compensate beyond reiteration.

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 researches a Polymarket bet by pulling Pipeworx data. It details the process: resolves market, classifies bet, fans out to relevant data packs, and returns an evidence packet with market-vs-model comparison. This specific verb+resource distinction separates it from sibling tools like ask_pipeworx (general query) or get_predictions (likely model predictions).

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

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

Explicit use cases are given: 'should I bet on X?', 'what does the data say about this Polymarket market?', 'is there edge in this bet?'. While it doesn't explicitly state when not to use it, the examples and positioning as the core bet research tool imply it is the go-to for betting context. A brief exclusion for general data queries would elevate it to 5.

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

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

No annotations are provided, so the description carries the burden. It discloses that it returns paired data and URIs and is a batch operation, but does not mention potential side effects, authentication needs, or data freshness. Adequate but not thorough.

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, zero waste. Every part adds value: purpose, per-type data, output format, and efficiency claim.

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

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

No output schema, so description covers return values ('paired data + URIs') and specifics per type. For a comparison tool, this is fairly complete. Could mention pagination or response size, but not necessary 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?

Schema coverage is 100%, so the baseline is 3. The description adds context on what data is returned per type but does not provide new details about the parameters themselves beyond what the schema already describes (enum, min/max, examples).

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: comparing 2–5 entities side by side, with specific data per type (company vs drug). It distinguishes from sibling tools by noting it replaces 8–15 sequential calls, and siblings are generic (ask, discover, etc.).

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 context for when to use: comparing entities, and what data each type returns. It mentions efficiency gains over sequential calls but does not explicitly state when not to use or list alternatives; however, the sibling list provides contrast.

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 states the tool returns 'most relevant tools with names and descriptions,' implying a search/recommendation behavior. However, it doesn't disclose details like whether it uses semantic search, any latency, or side effects. It's adequate but not rich.

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, no fluff. The most critical instruction ('Call this FIRST') is front-loaded. Every sentence adds value: what it does, how it returns results, and when to use it.

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 nested objects, no output schema), the description is complete. It explains the tool's role in a workflow (call first when many tools exist) and the input format. No gaps are apparent for an agent to misuse it.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of the query parameter through an example ('analyze housing market trends'), which helps agents formulate effective queries. The limit parameter is also clarified with default and max values, but the description doesn't repeat schema details beyond that.

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: searching the Pipeworx tool catalog by describing a need. It explicitly says it returns the most relevant tools with names and descriptions, distinguishing it from other tools by its search-and-retrieve function.

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 tells when to use it: 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task.' This provides clear guidance on prioritization and context, differentiating it from siblings like ask_pipeworx which likely answer questions directly.

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

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

No annotations provided, so description carries full burden. Discloses it returns citation URIs and bundles multiple data types, indicating read-only behavior. Minor gap: no mention of error handling or rate limits.

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

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

Two dense sentences with no filler. Front-loads purpose and enumerates data sources efficiently.

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 is comprehensive for a read operation, noting return of citation URIs and listing contents. Lacks output structure details (e.g., format of returned data) but sufficient for an agent to decide to use it.

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

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

Both parameters are well-described in schema, and the description adds valuable context: type limited to 'company', value accepts ticker or CIK, and suggests using resolve_entity for names. This significantly aids correct invocation.

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 a full entity profile across multiple packs, listing specific data types (SEC filings, XBRL, patents, news, LEI). It contrasts with sibling tools and advises an alternative for federal contracts.

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

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

Explicitly says when to use (for comprehensive entity data) and when not (for federal contracts, use usa_recipient_profile). Also hints at prerequisite: use resolve_entity if only a name is available.

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 of behavioral disclosure. It states deletion is destructive but provides no details on effects (e.g., irreversible? requires confirmation? error handling for non-existent keys?). The description is too minimal.

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?

A single, front-loaded sentence. Every word is necessary and sufficient. No fluff.

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

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

Given the tool is destructive (delete) with no annotations, the description is incomplete. It lacks context on return values, idempotency, or behavior when key doesn't exist. Sibling tools like 'remember' likely have similar minimal descriptions, but a deletion tool needs more detail.

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 does not need to add much. It repeats 'key' as the memory identifier, which aligns with the schema description. No additional semantics beyond what the schema provides.

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

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

The description 'Delete a stored memory by key.' clearly specifies the action (delete) and the resource (stored memory by key). It is distinct from siblings like 'remember' (store) and 'recall' (retrieve), though it could explicitly name these alternatives.

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

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

No guidance on when to use this tool versus alternatives. The description does not mention when deletion is appropriate or any prerequisites (e.g., memory must exist).

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 fully discloses behavior: fetches the page, extracts title/description/key links, outputs standard markdown. This goes beyond the annotations (readOnlyHint, etc.) by detailing the extraction process and output readiness. 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 concise, front-loaded with the main action, and each sentence serves a purpose. No redundant or vague statements.

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 two parameters and no output schema, the description provides sufficient context: purpose, use cases, output format, and behavioral details. An agent can correctly invoke it without additional information.

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 descriptions. The description adds value by specifying default max_links=25 (not in schema) and mentioning the URL parameter implicitly. This extra context justifies a score above the baseline of 3.

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

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

The description clearly states the tool generates an llms.txt file for a URL, explains the purpose for AI crawlers, and specifies the output format. No sibling tool performs a similar function, so no confusion.

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

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

The description lists explicit use cases (getting a client's site indexed, drafting for own project, auditing competitor). It does not define exclusions or alternatives, but the context is clear enough for an agent to decide when to use this tool.

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

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, any rate limits, or what happens if data is unavailable. It only specifies date format, leaving safety and side effects unclear.

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 purpose. The date format note is relevant but could be shorter. No wasted words.

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

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

Given the tool's moderate complexity (3 params, no output schema, no nested objects), the description is minimally adequate. It lacks detail on return format, error handling, or station ID lookup hints, but covers core functionality.

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

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

Schema description coverage is 100% (all three parameters have descriptions). The description adds the date format note (YYYYMMDD) which is already in the schema, so minimal extra value. Baseline 3 is appropriate.

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

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

The description clearly states the verb (get) and resource (hi/lo tide predictions for a NOAA station) and specifies the date range constraint. This distinguishes it from siblings like get_water_levels which retrieves water level data.

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

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

The description mentions date format requirements but does not explicitly guide when to use this tool vs alternatives (e.g., get_water_levels). There is no exclusionary 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, description carries full burden. It accurately indicates a read operation (Get) but doesn't disclose other behaviors like data freshness, data format, or any rate limits. Adequate but minimal.

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, concise sentence with no filler. All words are meaningful and front-loaded with the key 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?

Given the tool's simplicity (single required parameter, no output schema), the description is minimally adequate. Could benefit from mentioning output format or data recency, but not severely lacking.

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 the station_id parameter well-described in schema. Description adds no extra parameter 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?

Description clearly states the verb 'Get', resource 'latest observed water level', and scope 'NOAA station'. Purpose is specific and unambiguous, though it doesn't explicitly distinguish from sibling tool 'get_predictions' which could be inferred as providing predictions vs observations.

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 retrieving current water levels but provides no explicit guidance on when to use this tool vs alternatives like 'get_predictions'. No exclusions or prerequisites mentioned.

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 indicates a read-only operation (listing) and specifies what is returned (IDs and names). With no annotations, this is adequate but lacks details on data freshness or pagination.

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 sentence that efficiently conveys the tool's purpose and output, with no unnecessary words.

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

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

Given the tool has no parameters, no output schema, and simple behavior, the description is nearly complete. However, it could mention the source (NOAA) and that the list is comprehensive.

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 no parameters, so the description's mention of 'all NOAA tide prediction stations' adds context that the tool returns the entire set without filters. This is clear and sufficient.

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

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

The description clearly states the tool lists all NOAA tide prediction stations, providing IDs and names. The verb 'list' and resource 'stations' are specific and unambiguous.

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

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

The description implies usage for retrieving a list of stations but does not provide guidance on when to use this tool versus alternatives like get_predictions or get_water_levels.

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 rate limit of 5 messages per day and states it is 'free'. No annotations provided, so description carries full burden; adequately explains behavior 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?

Three concise sentences: purpose, usage guidelines, and rate limit. Front-loaded with most important info, 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?

Provides enough context for an agent to use the tool: what to send, how to format, and constraints (rate limit, avoid prompts). No output schema needed; response confirmation not critical for feedback 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 already has 100% description coverage for all parameters. Description adds high-level usage context but does not significantly enhance parameter understanding beyond schema.

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

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

Description clearly states 'Send feedback' and enumerates specific categories (bug, feature request, etc.). It differentiates from sibling tools like ask_pipeworx or discover_tools by being the dedicated feedback channel.

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 (bug, feature, data_gap, praise) and gives instructions on what to include (tools/data context) and exclude (end-user prompt). Mentions rate limit but lacks explicit alternatives for when not to use this tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that it's derived from CF analytics, contains no PII, and has cache times (5min-1h), providing valuable behavioral details 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?

Two sentences, front-loaded with core functionality, then use cases, then data source. Every sentence adds value with zero fluff.

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

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

No output schema, but the description states the output includes top tools, top packs, and total call volume. It could specify the structure (e.g., ranked lists) but is sufficient for a straightforward trending tool.

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

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

Schema coverage is 100% for the single parameter (window). The description adds semantics like 'shorter windows surface what's hot right now; longer windows show steady-state demand', enriching the enum values meaningfully.

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

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

The description explicitly states the tool returns 'top tools, top packs, and total call volume' over configurable windows, clearly distinguishing it from sibling tools like bet_research 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?

Three use cases are listed: discovering hot data sources, confirming canonical choices, and checking alignment. This provides explicit context for when to use this tool vs alternatives.

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

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

Annotations indicate read-only and non-destructive behavior. The description adds details on how the tool processes markets (walking child markets, extracting dates, sorting, checking inequality). It does not contradict annotations and provides useful 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 focused paragraph that front-loads the purpose. It is concise but packs necessary detail without being overly verbose. Could be slightly improved by breaking into shorter sentences.

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 one parameter and safe annotations, the description covers the logic and return format sufficiently for an agent to use it correctly. Lacks explicit edge-case handling, but is complete 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 single parameter 'event' is fully covered by the schema. The description adds value by clarifying it accepts slug or URL and gives an example, which helps the agent use it correctly.

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: finding arbitrage opportunities via monotonicity violations. It specifies the resource (Polymarket event) and distinguishes from siblings like 'polymarket_edges' by focusing on internal event 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?

The description explains when to use (events with multiple date/threshold markets) and provides a clear rule for arbitrage detection. It does not explicitly mention when not to use or list alternative tools, 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?

Beyond annotations (readOnlyHint, openWorldHint, destructiveHint), the description details the internal process: scans top markets by volume, groups by asset, fetches price history once, computes model probability via lognormal model, and ranks by edge magnitude. It also notes the scope ('V1 covers crypto-price bets'). This provides substantive 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 paragraph of four sentences, front-loading the main purpose. Every sentence contributes meaningful information. Could be slightly more structured (e.g., bullet points) but remains efficient and readable.

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 the algorithm and output (top N ranked with suggested direction) but lacks explicit detail on returned fields (e.g., market name, edge percentage). It covers the main workflow but leaves some ambiguity about the exact data structure. Additional completeness would improve usability.

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 clear descriptions for 'limit', 'window', and 'min_edge_pp'. The tool description adds no additional parameter-specific semantics beyond context already in the schema (e.g., 'Top N edges' is restated). 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 tool scans Polymarket markets and returns those with largest disagreement between Pipeworx data and market price. It specifies the use case ('what should I bet on today') and distinguishes from siblings like 'polymarket_arbitrage' and 'bet_research' by emphasizing Pipeworx's model and edge calculation.

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 positions the tool for discovering opportunities without manual browsing, saying it's 'built for the what should I bet on today question'. However, it does not explicitly state when not to use it or compare to alternatives like 'polymarket_arbitrage' for arbitrage vs edge opportunities.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds valuable behavioral context: two modes, auto-fetching logic for topics, typical spread range (2-25pp), and return fields (leg-by-leg prices and spread). No contradiction with annotations.

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

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

The description is concise (~5 sentences) and well-structured: purpose, motivation, modes, return format. No filler. Front-loads critical 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?

Given no output schema, the description covers return values (prices, spread) and explains the spread condition. It lacks an example response or full output field list but is mostly complete for agent usage. Annotations handle safety and idempotency.

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% (all parameters described), baseline 3. Description adds modal behavior: topic mode vs explicit override, relationship between parameters, and list of topic shortcuts. This provides significant meaning beyond schema, justifying a 4.

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

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

The description explicitly states the tool's purpose: 'Cross-venue spread between Kalshi and Polymarket for the same resolving question.' It distinguishes from siblings like polymarket_arbitrage by focusing on spread calculation and two distinct modes (topic vs explicit). The verb 'calculate spread' is specific and the resource is 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 clearly explains when to use each mode: topic for pre-mapped shortcuts (e.g., 'fed', 'btc') and explicit for custom pairings. It also highlights the spread as a 'real arb signal' implying usage context. However, it does not explicitly mention when NOT to use or compare with sibling tools like polymarket_arbitrage or polymarket_edges.

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 the description carries the burden. It discloses the tool is for retrieval, not mutation, which aligns with the verb 'recall'. However, it does not state what happens if the key doesn't exist or whether memories persist across sessions, leaving some ambiguity.

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 action, no redundant words. Each sentence adds value: first explains the action, second explains when to use.

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

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

Given the simple tool (one optional parameter, no output schema), the description is adequate. It explains both retrieval modes and usage context. Slightly more could be said about return format or error behavior, but 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 the schema already defines the key parameter well. The description adds context that omitting the key lists all memories, which is useful but not essential 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 retrieves a memory by key or lists all memories when key is omitted. It explicitly distinguishes from siblings like 'remember' and 'forget' by focusing on retrieval.

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 (retrieve context saved earlier) and implies when not to use (for listing all, omit key). However, it does not explicitly mention when to prefer other tools like 'discover_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 discloses the parallel fan-out behavior, accepted date formats, and return structure (structured changes + count + URIs). Could mention rate limits or auth, but core behavior is well covered.

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

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

The description is a single well-structured paragraph that front-loads purpose, then details behavior, parameters, returns, and use cases. No superfluous sentences.

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 moderate complexity (multi-source fan-out) and no output schema, the description covers all key aspects: entity type, date handling, value formats, return contents, and use cases. Could add more on error handling or response size, but 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% with parameter descriptions. The description adds context: explains that since accepts ISO or relative dates, type is limited to company, and value can be ticker or CIK, along with usage tips ('Use 30d or 1m for typical monitoring').

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' and details the specific resources involved (SEC EDGAR, GDELT, USPTO). It distinguishes from sibling tools like entity_profile by focusing on change monitoring.

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

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

The description provides explicit usage cues: 'Use for brief me on what happened with X or change-monitoring workflows' and explains supported entity types ('Only company supported today'). However, it does not explicitly mention when to use 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?

With no annotations, description discloses behavioral traits: memory persistence based on authentication status and session duration (24 hours). This is critical for understanding data retention. 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?

Three sentences, each adding value: first defines purpose, second lists use cases, third notes persistence. Could combine first two for even tighter structure.

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

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

Given no output schema and simple parameters, description adequately covers purpose, usage, and behavioral context. Missing only output format details, but for a store tool, success is implied.

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

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

Schema coverage is 100%, so baseline is 3. Description does not add further parameter details beyond schema, but schema examples are helpful. No additional value provided.

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 'store' and clear resource 'key-value pair in session memory'. It distinguishes from sibling tools like 'forget' and 'recall' by focusing on saving data.

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

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

States when to use ('save intermediate findings, user preferences, or context across tool calls') and provides context about persistence differences between authenticated and anonymous users. Lacks explicit when-not-to-use or alternatives.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It details the accepted inputs, supported version (v1), and return fields (ticker, CIK, name, URIs). It lacks explicit mention of idempotency or error handling, but still provides substantial 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 three sentences long, front-loaded with the main action, and includes a version note and practical examples. Every sentence adds value without redundancy, making it highly efficient.

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

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

For a simple lookup tool with 2 required parameters and no output schema, the description covers inputs, outputs, and benefits. It could be improved by noting what happens on error or missing data, but overall 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 descriptions for both parameters. The description adds significant value by providing concrete examples (e.g., 'AAPL', '0000320193', 'Apple') and explaining the purpose of canonical IDs, which goes beyond the schema's basic definitions.

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: resolving entities to canonical IDs across data sources. It specifies the supported type (company) and input formats (ticker, CIK, name), making it distinct from sibling tools like 'ask_pipeworx' which are more general.

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 when to use this tool (for entity resolution) and highlights its efficiency by noting it replaces 2-3 lookup calls. However, it does not explicitly state when not to use it or mention alternative tools, which would improve guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds that it probes each entity with ai_visibility_check, ranks results, and returns score/confidence/signal density. No contradictions.

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

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

Two sentences plus an example in parentheses; no wasted words. Front-loaded with main action and result structure.

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

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

No output schema, but description fully explains return values (ranked list with score, confidence, signal density). Also mentions internal call to ai_visibility_check. All relevant aspects covered.

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

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

Schema coverage is 100%, but description adds value: notes first entity is 'subject', models supported with default and API key requirement, context disambiguates common names. Provides meaning beyond schema.

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

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

The description clearly states it compares AI visibility across multiple entities, ranks them, and identifies the most/least recognized. It gives a specific use case ('competitive AI-marketing audits') and distinguishes from sibling tools like ai_visibility_check.

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

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

Provides clear context for when to use (comparing multiple entities for competitive audits) but does not explicitly state when not to use or name alternatives. Implicit differentiation from single-entity check 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?

No annotations provided, so description carries burden. It discloses the data sources (SEC EDGAR + XBRL), output includes a citation, and explains it replaces multiple agent calls. Does not address potential errors or limitations beyond domain.

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-load the core purpose and then provide specifics. No redundant or extraneous 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 one required parameter and no output schema, the description adequately covers input, output, and domain. Could mention limitations (only US public companies) but is sufficient for a simple tool.

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

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

Schema coverage is 100% with a parameter description, so baseline 3. Description adds example claim snippets and clarifies the domain scope (company-financial), enhancing 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 it fact-checks natural-language claims against authoritative sources, specifies supported domain (company-financial for US public companies), and lists the returned verdict and structured data. This distinguishes it from sibling tools 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?

It specifies the supported claim types (company-financial, US public) and mentions it replaces sequential agent calls, indicating efficiency. It lacks explicit when-not-to-use but provides clear domain limitations.

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