SnapRender

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by disclosing the async job model, immediate job-ID return, polling cadence, per-URL capture reservation at job start, refunds for failed URLs, and 24-hour link expiry — all operationally critical and not derivable from structured fields.

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 tight sentences, front-loaded with purpose and capped size, then the polling protocol, then the billing/refund rule, then the return format. Nothing is redundant and each sentence carries distinct operational information.

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

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

With no output schema, the description compensates by explaining what is returned (a job ID at once, no inline images) and how to retrieve results (get_batch_status plus 24-hour download links). Nothing needed to invoke and follow through is missing.

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

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

Schema description coverage is 100%, so ranges, defaults, enum values, and interactions (device overrides width/height; quality ignored for png) are already documented in the schema. The description only adds the 'same options applied to every URL' batching semantic, so the baseline 3 is correct.

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?

States a specific verb (Capture) and resource (URLs), plus the batching scope ('up to 50 URLs with the same options in one background job'), which cleanly separates it from the single-URL sibling take_screenshot.

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?

Prescribes the follow-up workflow explicitly: call get_batch_status every 2-5 seconds until the job is completed, and notes results come back as download links rather than inline images. It never explicitly states when to prefer take_screenshot instead of batching, so it stops short of full when/when-not routing.

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 and destructiveHint=false, so the safety profile is covered. The description adds value beyond that: it confirms nothing is captured, that the call is free, and that a cached hit reports capture time and expiry, which tells the agent what a positive result means.

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 short sentences, front-loaded with the core purpose and no filler; the standalone 'Free to call.' fragment still earns its place by stating a cost fact the agent needs. Slightly clipped phrasing keeps it just short of ideal.

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 14-parameter read-only probe with no output schema, the description covers what the tool does, what to pass, and what a cached result contains. It leaves the non-cached result shape and any TTL/prefetch guidance unstated, a minor gap given the rich schema.

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% across 14 parameters, so the schema carries the full parameter burden and the baseline is 3. The instruction to mirror take_screenshot's options adds useful framing but no new per-parameter semantics.

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?

States a specific verb and resource ('Check whether take_screenshot would return a cached copy') and explicitly names the sibling it mirrors, so an agent can distinguish it from take_screenshot without opening either schema. The 'without capturing anything' clause pins down the side-effect-free nature of the operation.

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

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

Clearly implies the use case: call this before take_screenshot to find out if a capture would be free, and it instructs the caller to pass the same options. It does not explicitly state an exclusion such as 'do not use this to actually retrieve the image', but the context is unambiguous for any reasonable 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?

Annotations only declare the safety profile (not read-only, not destructive, open-world), while the description adds genuinely new behavior: a hard cap of 5 webhooks per account, HMAC-SHA256 payload signing, and the fact that a secret is returned and must be stored to verify signatures. It stops short of describing failure behavior when the cap is hit or auth requirements, so it is strong but not exhaustive.

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

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

Five short sentences, each load-bearing: purpose first, then event semantics, then the quota cap, signing method, and the secret-handling instruction. No filler and no repetition of schema content.

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

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

With no output schema, the description correctly compensates by telling the agent the response contains a secret that must be saved. Combined with the quota cap, signing details, and full parameter coverage, the only gap is error/permission behavior when the 5-webhook limit is reached.

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

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

Schema description coverage is 100%, so the 3 baseline applies, but the description enriches the events enum with operational meaning (quota.warning = 80% used, quota.exceeded = 100% used, screenshot.completed = batch job done), which the bare enum values do not convey. The url parameter gains nothing beyond the schema's HTTPS requirement.

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 first sentence states a specific verb and resource ('Create a webhook subscription for event notifications'), which cleanly separates it from delete_webhook, list_webhooks and test_webhook without needing to name them. An agent can pick this tool from the sibling list on the verb alone.

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?

Usage is implied by the event catalog and the 'Max 5 webhooks per account' constraint, so an agent can infer when subscriptions make sense. However, there is no explicit when-to-use versus test_webhook or list_webhooks, and no stated precondition (e.g. verifying the endpoint first).

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description still adds value by stating the operation is irreversible, that webhooks are immutable, and that a missing ID produces an error rather than a silent no-op.

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 tight sentences, front-loaded with the action and the irreversibility warning, then the alternative path and the ID source. No filler.

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 one-parameter destructive tool with no output schema, the description covers purpose, irreversibility, the alternative workflow, ID provenance, and the return/error behavior. Nothing material is missing.

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

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

Schema coverage is 100% and the single parameter already documents itself, including its '(from list_webhooks)' provenance. The description only repeats that the ID comes from list_webhooks, adding no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Delete one of your webhook subscriptions by ID') plus the effect ('stops receiving events'). This clearly separates it from create_webhook and list_webhooks among the siblings.

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

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

Explicitly states the alternative workflow (webhooks cannot be edited; delete and use create_webhook instead) and where to obtain the ID (list_webhooks). This is exactly the when/when-not/alternatives routing an agent needs.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-redundant behavior: 'Uses one capture; failed extractions are free' (billing/retry semantics), the public-URL-only access limit, and the truncation behavior tied to max_length. It omits details like rate limits or JS-render timeouts, so not a full 5.

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?

Five compact sentences, front-loaded with purpose and format list before usage and constraints. The parenthetical format enumeration is dense but each clause carries information; only slight compression could be gained.

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

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

With no output schema, the description carries the return-value burden, and it does explain that content is returned as markdown/text/html/etc. up to max_length characters. Combined with full schema coverage and strong annotations, an agent has what it needs; the only gap is richer detail on failure modes.

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 every parameter is already documented in the schema, including the enum values, defaults and ranges. The description restates default max_length and a selector example but adds no format or syntax detail beyond the schema — the baseline 3 applies.

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

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

The description states a specific verb (extract/read) and resource (a public web page) with the output formats enumerated, and it explicitly contrasts itself with take_screenshot ('rendered in the same real browser'). An agent can distinguish this from all eleven siblings without opening a schema.

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

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

It names the sibling tool (take_screenshot) and the conditions that select each: 'after take_screenshot when you need the words, or on its own for research.' It also states the eligibility constraint ('Public URLs only'), leaving little to inference.

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 cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real behavioral value beyond them: polling cadence, the terminal status values, 24-hour download-link validity, and that calls are free. It stops short of describing pagination or the shape of non-terminal responses.

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 tight sentences with no filler; the core action is front-loaded and each following sentence carries distinct operational information (polling, link expiry, cost).

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

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

With no output schema, the description usefully notes that completed items carry 24-hour download links, partially covering return expectations. It leaves out the full status value set and non-terminal response contents, so it is not fully exhaustive for a polling 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?

Only one parameter (job_id) with 100% schema description coverage, so the schema fully documents it and the description adds no syntax or format detail. Baseline 3 applies since the schema does all the work.

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?

States a specific verb (get) and resource (status of a batch job) and explicitly ties it to batch_screenshots as the originating job creator, which cleanly distinguishes it from the sibling that starts the job.

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?

Gives concrete operational guidance: poll until status is 'completed' or 'failed' with a 2-5 second interval. It clearly implies the when-to-use context (after launching a job via batch_screenshots) but does not explicitly state when not to call it or name an alternative status mechanism.

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/destructiveHint, but the description adds genuinely non-structured behavior: counts are live, the call is free (no quota cost), resets_at is UTC, and unverified email sign-ups get limit_reason/verify_at. It stops short of describing rate limits or caching, but the added context is substantive.

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 dense paragraph that front-loads what is read and what is returned before moving to usage guidance. Every sentence carries information, though the return-field enumeration is long and could be tightened.

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

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

No output schema exists, so the description carries the return-value burden and does so fully, listing every field, its meaning (screenshots_remaining includes extra_credits), and the UTC convention. Nothing needed to call this tool correctly is missing.

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

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

Schema coverage is 100% and already documents the YYYY-MM format and current-month default, so baseline is 3; the description adds the semantic purpose ('pass month to read an earlier month'), telling the agent why it would override the default.

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?

States a specific verb+resource ('Read how many captures the account has used and has left') and enumerates the returned fields (plan, screenshots_used, screenshots_limit, screenshots_remaining, period, resets_at), distinguishing it from every sibling, none of which read account-level quota.

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?

Gives explicit when-to-use conditions ('before a large batch_screenshots job, or when a capture says the month is used up') and names the sibling tool it pairs with, plus the month parameter's use case for historical reads.

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. Description adds that it returns specific fields, which is helpful but not deep behavioral detail like pagination. No contradiction.

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

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

Single sentence, front-loaded with purpose, 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?

For a simple list tool with no parameters, the description covers purpose and output adequately. No missing context.

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?

No parameters in schema, so description doesn't need to add param details. Baseline 4 for zero-param tools.

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 the action (list), resource (webhook subscriptions), and return fields. Distinguishes from sibling tools like create_webhook and delete_webhook.

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 or alternatives. Usage is implied as listing subscriptions, but no when-not-to-use or comparison with other list 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 establish it's a read-only, non-destructive operation, so the bar is lower. The description still adds valuable billing and caching context: 'Creating the link is free. Opening it renders the page and uses one capture from this account (a recent cached copy is served free).' This tells the agent that opening the link consumes credits, not just creating it. Missing explicit mention of auth requirements beyond 'no API key needed.'

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

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

Three sentences, front-loaded with what the link is and does. Efficient, but the billing/caching detail could be slightly tighter.

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

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

For a tool with a rich 15-param schema (100% coverage), the description covers the key non-schema concerns: sharing purpose, cost model, and link expiration. No output schema exists, but for a link-creation tool the output (the signed URL) is self-evident. Adequate.

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

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

Schema coverage is 100%, so the input schema already documents all 15 parameters thoroughly. The description only adds the expires_in default behavior ('default: 1 day'), which the schema also states. Baseline 3 is correct when 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?

States a specific verb+resource ('Create a signed link that renders a screenshot') and distinguishes from siblings by noting it's a shareable link requiring no API key, unlike take_screenshot which presumably returns an image directly.

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?

Clear context for when to use: 'for emails, documents or sharing with others.' Does not explicitly exclude use cases or name alternatives, but the sharing-with-others framing is sufficiently differentiated.

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 cover safety (readOnlyHint, openWorldHint, destructiveHint), and the description adds substantial context beyond them: credit consumption ('Uses one capture', 'captures left this month'), caching semantics for fresh:false within 24 hours, a ~30 second loading timeout, and inline base64 output for pdf.

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?

Dense but front-loaded: the core action and return format come first, then option hints, then the cost/constraint details. Every sentence carries information, though it is longer than strictly necessary.

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 15-parameter tool with no output schema, the description covers return format (inline image, pdf as base64, trailing capture-count line), timeout behavior, cost, caching, and access restrictions. An agent has what it needs to invoke successfully.

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, but the description adds real meaning: device for phone/tablet views, full_page for the whole page, and format-specific output behavior (PNG inline vs pdf as base64). It does not restate ranges, but it clarifies intent for the higher-level options.

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?

States a specific verb and resource ('Renders the URL in a real browser') and describes the output ('returns the image inline'). It explicitly distinguishes itself from the sibling extract_content ('To read the words, use extract_content'), so an agent can route correctly without opening a schema.

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?

Gives explicit when-to-use (see a page visually), when-not (reading words -> extract_content), an alternative-cost path (fresh: false for a free cached copy), and a hard constraint ('Public URLs only: localhost and private network addresses are refused'). Nothing is left to inference.

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 adds behavioral context beyond annotations: it sends a test payload and returns delivery status and HTTP response code. Since annotations already declare readOnlyHint=false, destructiveHint=false, the description's mention of a test action with non-destructive consequences is appropriate and adds value.

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, no filler, and front-loaded with the core action. Every word is necessary and informative.

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 tool with one parameter and no output schema, the description is complete: it explains the action, the return value (delivery status and HTTP code), and the parameter is fully described in the schema. Annotations provide additional safety context.

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

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

Schema coverage is 100% with one parameter (webhook_id) described as 'The webhook ID to test (from list_webhooks)'. The description mentions 'webhook endpoint' but adds little beyond the schema. Baseline 3 is appropriate since the schema already fully documents the parameter.

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 action: sending a test payload to a webhook endpoint to verify event reception. It names the specific verb 'send' and resource 'test payload', and distinguishes from sibling tools like create_webhook (creation) and list_webhooks (listing).

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

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

The description indicates the tool is used to verify that a webhook receives events correctly, providing clear context. However, it does not explicitly state when not to use it or suggest alternatives, such as checking webhook configuration via list_webhooks before testing.

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