Professor Sausages — Web & Documents

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

With no annotations provided, the description carries the full burden. It transparently discloses search scope, output contents (method, URL, price, how to call), and that it is free. It does not go into error handling or auth requirements, but for a read-only discovery tool the disclosure is solid.

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

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

The description is two sentences: the first instructs the user with varied examples, the second explains the search behavior and return value. Every sentence contributes value and is front-loaded with actionable guidance.

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 single-parameter tool with no output schema, the description covers the essential aspects: how to query, what the tool does internally, and what fields are returned. Minor omissions like no-match behavior are present but not critical for a discovery 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%, so the task parameter is already described. The description adds extra examples and contextual guidance ('plain language'), reinforcing how to phrase queries beyond the schema's bare description, which earns above-baseline credit.

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 a specific verb ('Searches') and resource ('this server's datasets first, then the whole Professor Sausages catalog'), and distinguishes itself from sibling tools by focusing on discovery rather than direct data retrieval. The title also reinforces the purpose.

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

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

The description gives clear context for when to use it ('Describe the data you need in plain language') and explains the search order. It does not explicitly name alternative tools for exclusions, but the examples and output format ('returns matching endpoints') imply it is a discovery tool preceding endpoint calls.

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

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

With no annotations provided, the description carries full behavioral disclosure. It transparently explains the two-step payment requirement and details what each view computes, including 'skipping weekends and holidays' for settle. It does not cover return formats or error handling, but the key behavioral traits are clearly stated.

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

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

The description is front-loaded with the primary purpose, then condenses view behaviors into a single semicolon-separated sentence, followed by the payment flow and a pointer to a free sibling. Every sentence contributes unique information with no redundancy, making it both concise 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?

For a tool with 8 parameters and a payment gate, the description covers all views, the payment two-step, and the free alternative. While no output schema exists, an agent receives sufficient guidance to select the correct view and invoke the tool correctly, including how to handle the paid flow.

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%, setting baseline 3. The description adds relational semantics by connecting parameters to views (e.g., `days` as N in T+N for settle, from/to for business_days, year for year, date for is_open). This integration goes beyond the static schema descriptions, which already partially reference views, by clarifying how the parameters interact and what the view outputs mean.

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

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

The description opens with 'Is a market open on a date, and why not if it isn't,' clearly stating the tool's core purpose. It then enumerates the four views (next_session, settle, business_days, year) with specific outputs, making it distinct from siblings like `pricing` which is explicitly called out as the pricing tool.

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

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

The description explicitly points users to the `pricing` tool for price listings ('The free `pricing` tool lists every price at once'), providing a direct alternative. It also gives a step-by-step payment workflow (call without x_payment, sign terms, call again with x_payment), telling the agent exactly how to proceed for paid access.

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

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

With no annotations provided, the description carries the full burden and it discloses the payment requirement, the two-step x402 flow, and the fact that results are icon ids rather than SVGs themselves. It does not mention rate limits or failure modes, but the core behavioral trait (paid, terms-based access) is clearly disclosed.

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 deliver the core purpose, result format, and payment workflow with zero filler. The payment steps are compressed into a single clear sentence, and 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 adequately explains the return type (matches with ids) and how to fetch render-ready SVGs. The payment workflow is also specified, so an agent understands the full sequence. It could mention error cases or pagination, but for this scope 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?

The schema already provides 100% parameter coverage with examples, enums, and defaults for all five parameters. The description adds meaningful context for 'q' (semantic search) and 'x_payment' (the exact flow), but does not deeply elaborate on set/style/limit beyond what the schema states. The baseline of 3 is appropriate because the schema does the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Semantic search across 12,900+ open-licensed icons', clearly distinguishing it from sibling tools like image_to_text or screenshot_url. It also states what is returned (matches with ids for SVG fetching), leaving no ambiguity about the tool's core 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 provides clear context on how to use the paid aspect: call without x_payment to receive terms, sign them, then call again. It also points to the 'pricing' tool as a free alternative for listing all prices. However, it does not explicitly compare against sibling search or data tools, though the icon-specific scope makes usage obvious.

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 transparency burden. It discloses the critical paid, two-step payment behavior ('call without x_payment to receive this call's exact terms... then call again with x_payment') and notes that the `pricing` tool is free. It does not mention output format or failure modes, but the main cost 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 three sentences, front-loaded with the primary purpose, followed by the payment workflow and a pointer to the pricing tool. Every sentence adds essential context, and there is no redundant repetition of schema 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?

This is a complex tool with a dual OCR/vision behavior and a payment mechanism. The description explains both behaviors and the full payment workflow, and it points to the pricing tool for exact costs. However, it does not explicitly state the return format (e.g., plain text string) or error handling, leaving a minor gap.

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 already provides 100% parameter coverage with detailed descriptions (e.g., x_payment explains the exact two-step flow). The tool description adds little beyond what the schema states, mostly rehashing the x_payment behavior. Baseline 3 is appropriate given the high schema coverage.

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

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

The description clearly states the tool's function with specific verbs: 'Transcribe an image to text (OCR) or describe it via a vision model'. It also indicates steerability with a custom prompt, and this function is unique among the siblings (no other OCR/image description 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 provides explicit guidance on the payment workflow: call without x_payment to receive terms, then call again with x_payment to settle. It also directs users to the free `pricing` tool for price lists, offering a clear alternative for pricing inquiries. It does not explicitly state when not to use this tool, but the context is clear.

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

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

With no annotations provided, the description fully carries the transparency burden. It discloses the data source nature (deduped, tiered direct-feed), that it's a snapshot not live search, and the complete paid invocation flow (call without x_payment to get terms, sign, then call again). This goes beyond typical descriptions by explaining an unusual two-step payment mechanism.

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

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

The description is dense but each sentence adds essential information. It is front-loaded with the primary purpose, then shifts to mode variations, then payment. While it is more than two sentences, every clause serves a purpose. Slightly run-on in spots, but overall 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?

The tool has moderate complexity (5 params, payment flow, multiple modes) and no output schema. The description covers the main usage patterns, payment terms retrieval, and caveats. However, it does not specify the exact structure of returned headlines (e.g., fields like title, URL, date), which would be useful given there is no output schema. Still, it answers most practical invocation questions.

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%, providing a baseline of 3. The description adds meaningful context beyond the schema by explaining how parameters interact: q switches to archive search, category='ai'/'crypto' are curated cuts, and x_payment requires a specific handshake. This helps the agent understand the parameter interplay, justifying a score above 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?

The description clearly states it provides 'Newest headlines from a deduped, tiered direct-feed pile' and explains the alternative archive search via q. It also distinguishes itself from a 'live web search,' clarifying its scope. This is a specific verb+resource with clear differentiation from potential siblings like read_url.

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 guides when to use each mode: 'Pass q to keyword-search the retained multi-day archive instead' and highlights special curated categories ('ai' or 'crypto'). It also details the payment workflow and points to the 'free `pricing` tool' as an alternative for price lists, offering clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden. It reveals that parsing happens in-Worker with no upstream service, describes exactly what each format returns, and explains the payment behavior including the required x_payment payload and the pricing tool shortcut. This is exceptionally 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 three sentences, each earning its place: the purpose and size limit, the format behaviors, and the payment workflow. It is front-loaded with the core action and not a single redundant word.

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 covers return values for both formats. It also addresses the payment flow, size limitation, and processing location, making it complete for a tool of this complexity (3 params, payment gate).

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

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

The schema already covers 100% of parameters, so baseline is 3. The description adds meaningful semantics for 'format' by specifying that text returns 'one clean plain-text string' and json returns 'per-page text array plus document metadata.' It also clarifies the x_payment usage context. This exceeds the 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?

The description opens with 'Extract any PDF up to 10 MB by URL,' a specific verb+resource statement that clearly differentiates this from sibling tools like image_to_text or read_url. It also explains the two format options, making the tool's purpose 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 gives clear context by specifying the file size limit and the exact two-step payment workflow (call without x_payment, then sign and call again). While it doesn't explicitly say 'use this instead of X,' the tool's purpose and the mention of the 'pricing' tool provide adequate usage guidance. Missing explicit alternatives, hence 4 rather than 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?

With no annotations, the description carries the transparency burden. It discloses that data is 'read live from the route table' (no caching) and that it is 'Free' (no cost). For a simple read-only list tool, this is sufficient 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, dense sentence that front-loads the purpose ('Every endpoint...') and includes key details (price, x402, USDC on Base, live, free). 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 simplicity (no params, no output schema), the description covers the essential context: what the tool returns (endpoints, prices, summaries), the data source, and cost. It could mention the response format (e.g., list vs. text) but that is not critical for an agent to invoke 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?

The tool has zero parameters, so the schema is empty. The description adds no parameter details because none exist. According to the rubric, no params gives a baseline score of 4, and the description does not need to compensate.

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

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

The description clearly states what the tool does: it lists every endpoint with its exact per-call USD price and a one-line summary, sourced live from the route table. This is specific and distinguishes the tool from sibling data-retrieval tools by focusing on pricing metadata.

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: use this tool to discover endpoint costs or get an overview of available endpoints. It notes 'Free' as a cost characteristic, but doesn't explicitly state when not to use it or name alternatives. Still, the context is clear enough for an agent to decide.

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

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

With no annotations, the description bears the full disclosure burden. It explains that JavaScript is executed in a headless browser, that the output is markdown, and it details the payment flow (call without x_payment to get terms, sign, then call again). This is substantial behavioral context, though it omits potential edge cases like 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?

The description is only three sentences, each earning its place. The core functionality is first, followed by a use case, then the payment mechanism. 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?

For a two-parameter tool with a straightforward read operation, the description is largely complete. It explains the payment workflow, which is the main complexity. It does not detail return value beyond 'markdown', but no output schema exists, so a brief format note would help; still, the essentials are 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% (both parameters are described in the schema). The description reinforces the purpose of x_payment but does not add new meaning beyond what the schema already states. Baseline of 3 is appropriate when the schema fully documents parameters.

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

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

The description clearly states the tool's function: 'Render a URL in a real headless browser' and 'return clean, LLM-ready markdown'. This specific verb and output format distinguish it from siblings like screenshot_url (captures an image) and request_data (likely simpler fetching).

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 a concrete when-to-use: 'Use this when fetch() gives you an empty shell or a bot wall'. It also points to the pricing tool for alternative cost info. However, it does not explicitly state when not to use this tool (e.g., if a simple fetch is sufficient), so it falls short of full when/when-not 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that requests feed a nightly ingestion queue, that filings are typically available within ~24 hours, that contact is optional for follow-up, and that the service is free. This provides useful operational context beyond the bare function, though it doesn't cover every possible edge case (e.g., request limits, confirmation behavior).

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 packed with purpose, examples, process, timing, and cost. Every word earns its place, and the friendly tone ('suggestion box', 'Free.') adds personality without bloat.

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 request tool with 3 parameters, no output schema, and no nested objects, the description is complete: it covers use cases, expected behavior, and constraints. It could mention response format or request limits, but these are not critical given the tool's simplicity, making this above the minimum viable.

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 three parameters have descriptions and examples), so the baseline is 3 even without additional info. The description adds only a small hint about contact being optional for hearing back, which slightly reinforces the 'contact' parameter but doesn't materially deepen understanding of the parameters.

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

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

The description states a specific verb ('ask for') and resource ('data we don't have'), with concrete examples ('pre-2015 filing, an uncovered ticker, an unsupported chain') that make the purpose unmistakable. It clearly distinguishes itself from sibling tools like find_data by framing itself as a 'suggestion box' for missing 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 clearly implies when to use: when data is not currently available, as shown by 'data we don't have' and the explicit examples. It also sets expectations via the nightly ingestion queue and ~24h turnaround. However, it doesn't explicitly name alternative tools or say 'use find_data for existing data', so it falls short of a full 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?

With no annotations, the description carries the full burden and discloses the payment requirement and negotiation flow, which is a significant behavioral trait. It also states the output type is PNG. Minor gaps remain, such as how invalid URLs are handled and whether the PNG is returned as binary or base64, but the core side effects are 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 two sentences: the first states the core action concisely, the second explains the payment flow with no redundancy. It is front-loaded with the primary purpose and 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?

The tool has 5 parameters and no output schema. The description covers the core outcome (a PNG screenshot), the payment process, and the alternative pricing tool. It does not specify the exact response format (e.g., binary vs base64), but for a screenshot tool, 'return a PNG screenshot' is mostly sufficient. Overall, it is complete for most user intents.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the x_payment parameter's semantics (omit to receive terms, then sign and include it), and it clearly correlates width/height with 'the size you ask for.' It also points to the pricing tool for cost overview, enhancing the payment parameter's context.

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 renders a URL in a headless browser and returns a PNG screenshot at a requested size. It uses a specific verb and resource, and the mention of 'Paid' and the pricing tool distinguishes it from siblings like pricing and read_url.

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 outlines the two-step paid usage flow: call without x_payment to get terms, then call again with the signed x_payment. It also provides an alternative by directing users to the free pricing tool for a full price list. However, it does not explicitly state when not to use the tool versus other content-gathering siblings, though it is implied.

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

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

With no annotations, the description fully discloses the tool's behavior. It explains the paid nature: 'call without x_payment to receive this call's exact terms ... then call again with x_payment.' It also reveals that the free `pricing` tool lists all prices, which is useful behavioral context. The description warns that a call without payment returns terms, not data, making the workflow 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 about 90 words and front-loaded with the primary purpose. It efficiently explains the views and the payment model without unnecessary filler. It is a bit dense, but every sentence contributes meaningful information. A slight grouping of the payment details could improve scannability, but it's 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?

The tool has 8 parameters, no output schema, and a paid workflow. The description covers the main views, the payment flow, and directs users to the `pricing` tool. It doesn't explicitly state the return format for each view, but enough is implied (e.g., 'offset' returns the offset, 'convert' returns the converted time). For the default 'now' view, it says 'current local time', which is sufficient. Given the complexity, this is fairly 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%, so the baseline is 3. The description adds semantic meaning by connecting parameters to views: 'at' for offset/business_hours, 'time' and 'to' for convert, and 'open'/'close' for business hours. It also clarifies the x_payment workflow, which the schema describes but the description reinforces. This exceeds 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?

The description opens with a clear statement of what the tool does: 'Current local time, UTC offset and DST state for an IANA zone.' It then enumerates the distinct views ('offset', 'convert', 'business_hours'), each with a specific behavior, which distinguishes it from sibling tools like weather or holidays. The verb 'answers', 'moves', and 'says' are specific and action-oriented.

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?

Although no alternative tools are explicitly named, the description makes the usage context clear: use 'offset' for a specific instant, 'convert' to move wall-clock time between zones, and 'business_hours' to check if an instant is within business hours. The default view 'now' is implied. This provides clear context but doesn't explicitly state when not to use the tool or point to alternatives, so it falls just short of a 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?

With no annotations, the description carries the full burden. It discloses the paid x402 payment flow, the US coverage limitation for alerts, and that forecast returns an hourly series. This is significant behavioral context, though it omits details like error handling or units.

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, each earning its place. It front-loads the core purpose, then provides necessary detail on views and the payment process, with 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?

For a tool with no output schema and no annotations, the description covers the main behaviors, payment workflow, and coverage limits. It lacks mention of error cases or units, but overall it is sufficiently complete for an AI agent to use it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the x_payment flow (omit to get terms, then call again) and clarifying the view options. It does not elaborate on lat/lon or hours, but those are already well-described 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?

The description clearly states the tool provides current conditions for a named place or coordinate, and distinguishes its forecast and alerts views. It also differentiates from the sibling `pricing` tool by noting it is free and lists all prices.

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 on when to use the paid feature vs the free `pricing` tool, and explains the two-step payment flow. However, it does not explicitly state when to use weather over other data-related siblings, so not a 5.

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