Yc Rejection

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: the tool calls external LLMs, returns per-model data including raw responses, and notes that Anthropic calls require the user's own API key with direct payment. This goes beyond the annotations.

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

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

The description is concise, using only a few sentences. It front-loads the core action and return shape, then adds usage details. Every sentence provides useful information without 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?

Despite no output schema, the description sufficiently covers return values: per-model {score, confidence, signals, raw_response} plus a combined view. It explains API key handling and default behavior, making it complete for an agent to use without guessing.

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

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

Schema description coverage is 100%, so parameters are well-documented. The description adds value by explaining the default model ('Workers AI Llama-3.3-70b free'), clarifying that `_apiKey` is only needed for Anthropic, and that `context` helps disambiguate. It also lists possible model values, compensating for the lack of enums.

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: probing LLMs for knowledge about a business/brand/product/topic and scoring visibility. It uses specific verbs ('probe', 'score') and identifies the resource (LLMs). It distinguishes from sibling tools like `scan_competitor_ai_presence` by focusing on visibility scoring across multiple models.

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 mentions use cases: AI-marketing audits, pre-launch brand checks, competitive monitoring. It explains the default model and how to use Anthropic with a BYO API key. While it doesn't explicitly state when not to use it or compare to alternatives, the context is clear enough for an AI agent to decide.

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

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

The description discloses key behavioral traits: Pipeworx picks the right tool, fills arguments, and returns the result. This explains the automatic routing and argument filling. With no annotations provided, the description carries the burden and does 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?

The description is concise at two sentences plus examples. It is front-loaded with the core purpose, then expands with examples. 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 tool's complexity (simple interface with one parameter, no output schema), the description is complete. It explains what the tool does and how it works. However, it could mention that there is no guarantee of correctness or source transparency.

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 schema already documents the single 'question' parameter. The description adds context that the question should be in natural language and provides examples, which is helpful but not strictly necessary 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: asking natural language questions to get answers from the best data source. It uses specific verbs like 'ask' and 'get an answer', and distinguishes from sibling tools that are for tool discovery, memory, or rejection handling.

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 usage context: 'No need to browse tools or learn schemas — just describe what you need.' It gives examples of what to ask. However, it doesn't explicitly say when NOT to use this tool 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 provide readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds: resolves market, classifies bet, fans out to relevant packs, returns comparison. No contradiction. Adds context beyond annotations.

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

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

Description is dense but well-structured, front-loading the core action. Every sentence adds value. Slightly verbose but justified by complexity.

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

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

Given complexity (multi-step, classification, fan-out), description covers inputs, outputs, and behavior. No output schema, but return values are described. Annotations cover safety. Comprehensive for agent usage.

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%. Description adds meaning: depth defaults to thorough, market accepts three formats, gives examples. This enriches 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?

The description clearly states the tool's purpose: research a Polymarket bet by pulling Pipeworx data in one call. It specifies input types (slug, URL, question text) and output (evidence packet + comparison). Distinguishes itself from siblings by being a composite, bet-optimized tool.

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

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

Description explicitly lists use cases: 'should I bet on X?', 'what does the data say?', 'is there edge?'. It implies preference over manual pack discovery. Lacks explicit 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?

No annotations are provided, so the description carries the full burden. It states the tool returns paired data and resource URIs from SEC EDGAR and FDA, but does not disclose potential error conditions, data freshness, authentication needs, or non-destructive nature. The transparency is 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?

The description is three concise sentences with no redundant words. The first sentence immediately states the core purpose, followed by type-specific details and a benefit statement. It is perfectly sized and 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 no output schema, the description covers return data (revenue, net income, cash, long-term debt for companies; adverse-event reports, FDA approvals, active trials for drugs) and mentions resource URIs. It is complete for a tool with only two parameters, though it omits error handling and data freshness.

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, and the description adds significant meaning: it explains what data each type returns and provides concrete examples (e.g., tickers for companies, drug names). This goes beyond the schema alone.

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

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

The description clearly states the tool compares 2-5 entities side by side, specifies two entity types (company and drug) with distinct data fields, and mentions it replaces multiple sequential calls. The verb 'compare' and resource list make the purpose unmistakable.

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

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

The description explains when to use the tool (comparing 2-5 entities) and notes efficiency gains, but does not provide explicit guidance on when not to use it or mention alternative tools like ask_pipeworx. The context is clear but lacks exclusions.

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

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

Although no annotations are provided, the description adds behavioral context: it returns 'the most relevant tools with names and descriptions' and acts as a search/filter mechanism. It does not mention any destructive effects or side effects, which is appropriate for a search tool. A small gap is that it doesn't clarify if the tool requires any authentication or has rate limits, but given the simplicity of a search, this is acceptable.

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

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

The description is three sentences, each adding value: first states the action, second describes output, third gives usage guidance. No filler or redundancy.

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

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

Given the tool's complexity (simple search, two parameters, no output schema, no annotations), the description is fairly complete. It explains the purpose, when to use, and what to expect. It could mention whether results are ordered by relevance, but that is implied. Overall, adequate for an agent to use correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it provides a high-level use case ('analyze housing market trends') but no further details on parameter semantics. Since the schema already covers both parameters adequately, this score 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 ('Search the Pipeworx tool catalog') and clearly states the tool's purpose: returning relevant tools with names and descriptions. It also distinguishes itself from siblings by positioning as the first call to find tools among 500+ 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 need to find the right ones for your task.' This provides clear context and differentiates from siblings that likely serve different purposes.

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?

Despite no annotations, description discloses return format (pipeworx:// URIs), bundling behavior, and data source coverage. It also notes exclusion of federal contracts due to slowness. Could mention 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?

Single paragraph front-loaded with core purpose, followed by detailed data list, return format, and exclusion note. No redundant 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?

For a complex bundling tool, description covers what data is included, return format, and key exclusion. No output schema needed as description sufficiently sets expectations.

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

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

Schema coverage is 100% and description repeats schema details (type enum, value examples, name restriction). Adds no new parameter-level insights beyond what schema already provides.

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

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

Description clearly defines tool as a full entity profile aggregator, listing specific data sources (SEC, XBRL, patents, news, LEI) and stating it replaces 10-15 sequential calls. It distinguishes from sibling usa_recipient_profile by directing federal contracts elsewhere.

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 (full profile needed), when not to (federal contracts - use usa_recipient_profile), and prerequisites (names require resolve_entity first). Mentions efficiency benefit of bundling.

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 must carry full burden. It does not disclose whether deletion is irreversible, if any confirmation is needed, or if associated data (e.g., memory metadata) is also removed. The description is 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?

The description is a single sentence, front-loaded with the action and resource. It is concise and efficient, 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 tool's simplicity (one required param, no output schema), the description is functional but lacks behavioral details (e.g., error cases, idempotency). An agent might need to infer what happens if the key does not exist.

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 single parameter described as 'Memory key to delete'. The description adds no extra meaning beyond what the schema already provides. 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 action ('Delete') and the resource ('stored memory by key'). It effectively distinguishes from siblings like 'remember' (create) and 'recall' (retrieve), though it does not explicitly differentiate from 'forget' itself.

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

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

No explicit guidance on when to use vs. alternatives, but the purpose is clear enough that an agent can infer it's for deletion. The sibling context (recall, remember) provides implicit differentiation.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds that it fetches the page and extracts content, but doesn't elaborate on behavioral traits beyond what's implied by annotations.

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

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

Description is 4 sentences, front-loads the purpose, and avoids unnecessary detail. Efficient and 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 no output schema, description mentions output format and use cases. Lacks error handling or prerequisites, but tool is simple with only 2 parameters, making it reasonably 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?

Input schema has 100% coverage for both parameters (url and max_links). Description does not add additional semantics beyond what the schema provides, achieving baseline.

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 generates a production-ready llms.txt file for any URL, and specifies the output format and purpose. It distinguishes itself from sibling tools by focusing on a specific AI indexing task.

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

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

Provides explicit use cases: getting a client's site indexed, drafting for own project, auditing competitor. No exclusions or alternatives mentioned, but the examples give clear context for when to use.

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

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

With no annotations, the description discloses rate limit, cost (free), and privacy guidance (omit prompt). However, it does not explain what happens after submission (e.g., auto-ticket, response) or whether identity is tracked beyond rate limiting.

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 concise sentences, each serving a purpose: purpose, use cases, content rules, rate limit/cost. No redundant or vague language.

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, description covers purpose, guidelines, and limitations. Lacks details on authentication or confirmation, but schema handles context parameter. Output schema absent but acceptable for submission-only 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 covers all parameters (100% coverage). Description adds value by specifying message content guidelines ('describe what you tried in terms of Pipeworx tools/data'), which is not in schema. Baseline 3 plus extra nuance equals 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 clearly states 'Send feedback to the Pipeworx team' and lists specific use cases (bug reports, feature requests, missing data, praise). This distinguishes it from sibling tools like ask_pipeworx, which is for 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?

Explicitly tells when to use (for feedback types) and gives content guidelines (describe what you tried, omit user prompt verbatim). Rate limit is stated, but no explicit mention of when not to use or alternatives; however, the context with siblings implies distinction.

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, destructiveHint. The description adds value beyond annotations by explaining data source (CF analytics-engine), privacy (no PII), and caching behavior (5min-1h). 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 four sentences, front-loaded with the core functionality. Each sentence adds value: purpose, use cases, data source, caching. 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?

Despite no output schema, the description explains return values (top tools, packs, call volume, (pack, tool, count)). For a simple parameter, the coverage is complete and sufficient for agent 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% for the single 'window' parameter, but the description adds context: 'Shorter windows surface what's hot right now; longer windows show steady-state demand.' and mentions default and caching. This enriches meaning beyond the schema enum description.

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

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

The description clearly states it returns top tools, packs, and call volume over a window, specifying the verb 'returns' and the resource 'trending data on Pipeworx'. It differentiates from siblings by focusing on what other AI agents are calling, and provides three concrete use cases.

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

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

The description explicitly lists three specific scenarios when to use the tool (discovering hot data sources, confirming canonical choice, checking alignment). While it does not explicitly say when not to use it or name alternative tools, the provided guidance is clear and actionable.

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

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

Annotations declare readOnlyHint=true, consistent with a read operation. The description adds behavioral context: walks markets, searches across events, groups them, and checks monotonicity. It explains cross-event mode's advantage and mentions return of ranked opportunities with reasoning. 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 at six sentences, front-loading the core purpose and clearly explaining two modes. It avoids fluff but could be slightly more streamlined while retaining all necessary details.

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

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

Despite no output schema, the description mentions the return format ('ranked opportunities with suggested trade direction + reasoning'). For a read tool with two modes and external data access, it provides sufficient context for an AI agent to understand and use the tool.

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

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

Schema coverage is 100% with descriptions. The description adds value by providing examples (event slug, topic) and explaining how each parameter is used in the respective mode, going 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 finds arbitrage opportunities by checking monotonicity violations across related Polymarket markets. It distinguishes two modes (`event` and `topic`) with specific verbs and resources, making it distinct from sibling tools like `polymarket_edges`.

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 explains when to use each mode: single event slug for `event`, or a topic/seed question for `topic` to catch cross-event cases. It provides rationale for cross-event mode. However, it does not mention when not to use this tool 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?

Annotations declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds methodology details: groups by asset, fetches price history once, uses a lognormal model from FRED and live coinpaprika price, computes model probability per market, and ranks by |edge|. It also notes return includes suggested trade direction. No contradictions with annotations.

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

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

Description is well-structured: starts with a clear one-sentence purpose, explains methodology, then output and use case. Every sentence adds value. Slightly long but not excessively so.

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

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

Tool is complex (scanning markets, grouping, fetching history, computing model, ranking). Description covers what it does and why. No output schema exists, but description explains return: top N ranked by edge magnitude with suggested trade direction. This is sufficient given the tool's nature.

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

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

Input schema has 100% coverage with descriptions for all three parameters (limit, window, min_edge_pp). Description mentions default values and max (limit max 25, window default 1wk, min_edge_pp default 0.5), which are already in the schema. It does not add significant new 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?

Description clearly states the tool scans high-volume Polymarket markets and returns those where Pipeworx data disagrees most with market prices. It specifies the verb (scan, return), resource (Polymarket markets), and outcome (ranking by |edge|). This distinguishes it from sibling tools like polymarket_arbitrage.

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

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

Description explicitly states it is built for the 'what should I bet on today' question, providing clear context. It does not explicitly mention when not to use it or alternatives, but the use case is well defined.

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

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

Annotations already declare read-only, idempotent, and open-world hints. The description adds context about the price difference range (2-25pp) and specifies the return format (leg-by-leg prices and spread), which is beyond the annotations and valuable for an agent.

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 numbered modes and bullet points for topic options. It front-loads the purpose in the first sentence. However, the detail about the 2-25pp range could be considered slightly verbose, but overall it is concise and effective.

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

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

For a tool with no output schema, the description fully covers return values (leg-by-leg prices and spread). Combined with rich annotations, it provides a complete picture of behavior, parameters, and output, making it sufficient for an agent to use correctly.

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

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

Schema coverage is 100% with descriptions, but the description adds meaning by explaining the dual mode (topic vs explicit) and how explicit tickers override topic mapping. This goes beyond the schema's individual parameter descriptions, enriching semantic understanding for the agent.

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 computes cross-venue spreads between Kalshi and Polymarket for the same resolving question. It explains two modes and distinguishes from siblings by focusing on this specific arbitrage signal, using precise verb ('Cross-venue spread') and resource specification.

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 usage modes (topic vs explicit) and implies when each is appropriate (common events vs custom pairings). However, it does not explicitly exclude use cases or compare to sibling tools like polymarket_arbitrage, so it is slightly less than perfect.

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 the burden. It reveals that omitting key lists all, which is a behavioral trait. However, it does not state if retrieval is read-only, if it affects the memory state, or any side effects.

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

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

Two sentences, front-loaded with action and key behavior. Every word is necessary and no filler. Perfectly concise.

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

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

Given the tool's simplicity (one optional parameter, no output schema), the description is complete enough. It explains the two modes of use. No further detail is needed for a straightforward retrieval 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 'key', with a clear description in the schema. The description adds meaning by explaining the effect of omitting the key (list all), which is beyond the schema's description.

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

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

The description clearly states the tool retrieves a memory by key or lists all memories if key is omitted. It distinguishes from siblings by mentioning 'previously stored memory' and 'earlier in the session', which is distinct from remember (store) and forget.

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

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

The description tells when to use (retrieve context saved earlier) and implies when not (omit key to list all). It does not explicitly mention alternatives or when to avoid, but the context is clear enough for an agent.

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

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

No annotations exist, so the description carries full burden. It discloses parallel execution across sources, supported date formats (ISO and relative), and return values (structured changes, count, URIs). It does not mention rate limits or auth requirements, but for a read-like tool, the core behavior is transparent.

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

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

The description is extremely concise: three sentences front-loading purpose, then behavior, then usage. No wasted words, every sentence earns its place.

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

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

Given no output schema, the description fully explains return structure (structured changes, count, URIs). Input parameters are fully described both in schema and description. The tool's complexity (multi-source fan-out) is adequately 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%, and the description adds value by detailing 'since' format examples and clarifying 'value' input (ticker or CIK). This goes beyond the schema descriptions, aiding correct parameter usage.

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

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

The description clearly states the tool's purpose: 'What's new about an entity since a given point in time.' It specifies the entity type (company) and details the fan-out to three sources (SEC EDGAR, GDELT, USPTO). This distinguishes it from siblings like entity_profile or compare_entities.

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

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

Provides explicit usage guidance: 'Use for "brief me on what happened with X" or change-monitoring workflows.' It contextualizes the tool but does not explicitly state when not to use or mention alternatives among siblings, which is a minor gap.

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 persistence difference between authenticated (persistent) and anonymous (24-hour) sessions. With no annotations, the description carries full burden and does well, though it could mention if values overwrite on same key or if there are size 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?

Three sentences, each serving a clear purpose: what the tool does, when to use it, and persistence behavior. 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?

For a simple 2-parameter tool with no output schema, the description is thorough. It explains persistence, which is critical for session memory. Could add a note about overwriting behavior or maximum key/value length.

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

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

Schema coverage is 100%, and the description adds context by giving examples of key values (subject_property, target_ticker) and explaining the value can hold any text. This goes beyond the schema's generic descriptions.

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

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

Clearly states it stores a key-value pair in session memory, with specific use cases like saving findings, preferences, or context. Distinguishes from sibling tools like recall (retrieve) 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?

Provides explicit when-to-use: 'save intermediate findings, user preferences, or context across tool calls'. Also explains persistence behavior for authenticated vs anonymous sessions, which helps the agent decide 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?

With no annotations, the description carries full burden. It discloses return values (ticker, CIK, name, pipeworx:// URIs) and version limitations. However, it does not mention error handling, rate limits, or behavior for ambiguous inputs.

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

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

Two sentences with no wasted words. The description is front-loaded with the purpose and efficiently provides key usage details.

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

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

The description covers the basic return values but lacks details on response structure or behavior for ambiguous names. With no output schema, it should be more explicit about the format of canonical IDs and potential multiple matches.

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 value by explaining that 'type' v1 only supports 'company' and that 'value' accepts ticker, CIK, or name, with 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 verb 'resolve', resource 'entity to canonical IDs', and specifies it's for Pipeworx data sources. It distinguishes itself from siblings by focusing on entity resolution in a single call, unlike ask_pipeworx or other tools.

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

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

The description explains when to use it (replaces 2-3 lookup calls) and provides examples for type='company'. However, it does not explicitly state when not to use it or mention 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?

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds behavioral context: it probes each entity, ranks by score, surfaces most/least recognized. No contradictions with annotations.

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

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

The description is two sentences plus an illustrative quote, with front-loaded purpose. Every sentence adds value: purpose, mechanism, use case, return format. 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 4 parameters all documented in schema and no output schema, the description provides sufficient context: it explains return format (ranked list with score, confidence, signal density) and usage context. It could mention dependence on ai_visibility_check but sibling context makes it 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?

Schema coverage is 100% so baseline is 3. The description adds value by explaining that the first entity in 'entities' is treated as subject, 'context' disambiguates common names, and 'models' supported list. This enhances understanding beyond schema descriptions.

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

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

The description clearly states the tool compares AI visibility across multiple entities side-by-side, using a specific verb 'compare' and resource 'AI visibility'. It distinguishes itself from sibling 'ai_visibility_check' by noting it probes each entity with that tool and ranks results.

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

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

The description explicitly states it is useful for competitive AI-marketing audits and gives an example question. It implies use when comparing multiple entities rather than checking one, but does not explicitly state when not to use or alternative tools beyond the sibling mentioned in purpose.

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

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

No annotations are provided, so the description carries the burden. It mentions supported claim types and return format but does not explicitly state that the tool is read-only or disclose potential limitations (e.g., only US companies, specific metrics).

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 and front-loaded with the purpose. Every sentence adds value, though it could be slightly more streamlined 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?

Given the simple single-parameter schema, no output schema, and no annotations, the description is fairly complete. It covers the tool's function, domain, return values, and even its efficiency advantage.

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% description coverage, but the description adds value by explaining the natural-language nature of the 'claim' parameter and providing examples, which aids agent understanding.

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

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

The description clearly states the tool's purpose: fact-check natural-language claims against authoritative sources. It specifies the domain (company-financial claims for public US companies) and distinguishes from siblings as the only fact-checking tool.

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

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

The description explains when to use (for fact-checking financial claims) and even mentions it replaces sequential agent calls. However, it does not explicitly state when not to use or provide alternatives for non-financial claims.

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

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

With no annotations, the description carries the full burden. It only discloses that encouragement is insincere but does not reveal other behavioral traits like how parameters affect output, whether it is deterministic, or any side effects. This is insufficient for a tool with 6 parameters.

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

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

The description is very short (two sentences) and front-loads the purpose. However, it could be more concise by omitting 'this tool is for' phrasing if present, but here it is direct. The structure is efficient but at the cost of missing essential details.

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

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

Given the tool has 6 parameters and no annotations, the description is incomplete. It does not explain the significance of input fields or how they affect the rejection output. The presence of an output schema is not leveraged by the description, and the behavioral note is 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 description coverage is 0%, and the description provides no information about any parameters. The agent cannot infer the meaning or role of optional fields like traction, pivot_count, etc., which is a critical gap.

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

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

The description clearly states it provides 'Instant YC rejection for any startup idea,' specifying the verb (generate rejection) and resource (YC rejection). It distinguishes itself from unrelated siblings and includes the humorous note about insincere encouragement, which adds clarity.

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 a user wants a rejection for a startup idea. There is no explicit guidance on when not to use or mention of alternatives, but siblings are unrelated, so the context is sufficient for a basic connection.

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