Octocrawl

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

Annotations cover the safety profile (non-read-only, non-idempotent, open-world, non-destructive), and the description adds genuinely useful behavior: asynchronous taskId return, the 1-1000 bound, and that URLs must be distinct. It does not mention validation failures, rate limits, or duplicate-URL handling, which for a non-idempotent batch submit would be nice to have.

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 tight sentences with the verb and scope front-loaded and the follow-up tools in the second sentence. The phrase 'with the reviewed JSON schema' is vague jargon that slightly muddies rather than clarifies.

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 discloses the return (taskId) and the two companion tools needed to consume the result, which is what an agent needs for an async batch tool. Missing only edge behavior such as failure modes or partial-batch handling.

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

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

The single parameter has no schema description (0% coverage), so the description must carry the semantic load, and it does add real constraints: count range and 'distinct', plus the Amazon.sg product URL restriction. That is meaningful beyond the bare array-of-strings schema, though it omits URL format requirements.

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 (queue) and resource (Amazon.sg product URLs) with a bounded count of 1-1000. It is clearly the product-specialized batch entry point versus generic batch_scrape, though it never explicitly contrasts itself with that sibling.

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 the operational workflow by naming wait_batch as the wait step and get_batch_items as the paging step, so an agent knows what to call next. It does not state when to prefer this over batch_scrape or scrape_product, so it falls short of explicit alternatives.

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

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds genuinely new behavior: the job is asynchronous and returns only { taskId } immediately, invalid URLs are surfaced as invalidURLs when ignoreInvalidURLs is set, appendToId re-runs a completed batch, and idempotencyKey is retained 24 hours. The candid admission that result retention 'is not stated' is useful, though concurrency/rate-limit behavior is left unaddressed.

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?

Front-loaded with the one-sentence purpose and return contract, then a workflow sentence, then parameter notes. Dense but essentially waste-free; the long middle sentence enumerating delegated scrape options is the only place readability suffers.

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?

An output schema exists, so the description need not explain return values, yet it usefully summarizes the immediate { taskId } response and the invalidURLs variant. For a 33-param, nested-object tool it covers purpose, async lifecycle, and the sibling chain adequately; the acknowledged gaps (result retention, quotas) are the remaining holes.

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?

With 33 parameters at only 42% schema description coverage, the description compensates by declaring the shared option set ('formats, onlyMainContent, includeTags, waitFor, timeout, verify, actions and the rest; their descriptions are on scrape'), which is the single most valuable thing it could say here. It also clarifies appendToId and idempotencyKey beyond their one-line schema text. Many parameters (maxAge, webhook, lockdown, maxConcurrency, robotsOverrides, includeSubdomains) remain undocumented in both places, so it is not exhaustive.

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 with scope: 'Run 1-1000 known URLs as one persistent job.' The word 'known' implicitly separates it from crawl-style discovery, and naming the sibling follow-ups (wait_batch, get_batch_items, get_batch_errors) pins down its place in the workflow. An agent can distinguish it from scrape and crawl 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 clear operational routing: use appendToId to add to an existing batch, idempotencyKey to make a retry safe, and the three named tools for waiting/paging/errors. It does not state when to prefer crawl or scrape_product instead, nor any exclusion (e.g. 'do not use for URLs you must discover'), so it stops short of a full when/when-not statement.

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 idempotentHint=true, so the safety profile is covered. The description does add one genuinely non-obvious fact beyond them: items already read remain readable after cancellation, implying partial results survive. It says nothing about in-flight items, error/partial-failure behavior, or permissions, so a 3 is warranted.

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

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

A single front-loaded sentence with two clauses, both of which carry information (the handle and the post-cancel state). No filler or preamble, though it is terse enough to leave the reader wanting more on usage.

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 mutation tool with annotations covering safety and no output schema, the essentials are present, and the note about surviving items is helpful. It still leaves open what happens if the batch already finished and whether cancellation is immediate, which idempotentHint only partially covers.

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

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

Schema coverage is 0% and the single parameter is named "id" with no schema description, so the description carries the burden. It does clarify that the id is the batch's taskId, which adds real meaning, but gives no format, source, or example of where to obtain it.

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

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

States a specific verb and resource ("Cancel a batch") and identifies the required handle as a taskId, so the agent knows exactly what operation this is. It does not explicitly differentiate itself from sibling cancellers like cancel_crawl or cancel_monitor_run, but the resource noun makes the target 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?

No guidance on when to cancel versus alternatives such as wait_batch, get_batch, or hand_off_batch is given. The agent must infer that this is the abort path for an in-progress batch, and no preconditions or exclusions are stated.

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, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: 'Completed pages remain queryable,' telling the agent that cancel is non-rollback and already-scraped data persists. It stops short of explaining whether a cancelled crawl can be resumed via resume_crawl.

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 short sentences, zero waste, with the action and the key post-condition front-loaded. Nothing redundant or padded.

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

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

For a single-parameter mutation with no output schema, the description is adequate on what happens to existing data but omits parameter sourcing and resumability behavior. An agent can call it, yet its required argument and follow-up options remain underspecified.

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 single parameter 'id' is undocumented in both schema and description. The description never states whether the id refers to a crawl task id and where to obtain it (e.g., from crawl or list_active_crawls), leaving the required identifier semantics unexplained.

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+resource ('Cancel a crawl task'), which is unambiguous about the operation. It does not, however, distinguish this from sibling cancel-style tools (cancel_batch, cancel_monitor_run) or clarify what 'a crawl task' means relative to get_crawl/resume_crawl.

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?

There is no guidance on when to cancel versus alternatives such as resume_crawl or simply letting the crawl finish, nor any preconditions (e.g., must the crawl be running). The agent is left to infer all usage context.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds the run-state precondition (queued or running) but says nothing about what happens to partial results, whether the cancellation is reversible, or failure modes for an already-finished run.

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?

One short sentence with the verb and resource front-loaded and zero filler. Nothing could be cut without losing meaning.

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?

A destructive mutation with two undocumented, required string identifiers and no output schema. Annotations cover the safety dimension, but the description leaves the id-versus-runId relationship unresolved, so an agent could easily pass the wrong value.

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?

With 0% schema description coverage and two required identifiers, the description must carry the burden of explaining parameters. It never disambiguates which ID is the Monitor and which is the run — the single most important ambiguity an agent faces when calling this tool.

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 (cancel a Monitor run) and narrows scope to 'queued or running'. That is enough to distinguish it from siblings like cancel_crawl and cancel_batch, though it never contrasts itself with pause_monitor/resume_monitor, the closest non-cancel 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?

'Queued or running' implies the valid states for cancellation, which is mild when-to-use guidance. There is no statement of when to prefer pause_monitor over cancellation, nor any prerequisite (e.g., required permissions or ownership) for the call.

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 annotations already declaring it non-read-only, open-world, non-idempotent, the description adds real behavioral context beyond them: the async taskId return, that the 100-page default is echoed back, that retention duration is unknown to the client, and that collapsed/refused links are still tallied in get_crawl's discovery. It does not discuss idempotencyKey semantics or rate/robots constraints.

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 dense sentences with the traversal scope front-loaded and the deferred workflow immediately after; little padding. The 'Returns { taskId }' sentence slightly overlaps an existing output schema, but the appended maxPages detail makes it earn 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?

For a 40-parameter tool with annotations and an output schema, it covers the essentials: what it traverses, what it returns immediately, how to retrieve results, and where page-option semantics live. The remaining gaps (most boolean/array flags, retention policy) are acknowledged or handled by the schema rather than silently omitted.

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?

With 40 parameters at 50% schema coverage, the description can only partially compensate. It adds meaning for maxPages (the default comes back in the response), maxDepth, and URL folding, and cross-references scrape for the page options, but the bulk of the option surface is left to 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?

It names a specific verb and resource ('Start crawling a section of one site') and bounds the scope precisely (start path's subtree, own host + www twin). That scope description implicitly separates it from scrape (one page) and map (URL discovery only), though it never names those siblings explicitly.

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 gives clear operational context: it returns { taskId } at once, so wait_crawl, then get_crawl_pages, is the intended follow-up chain. It also routes page-option questions to scrape's parameter descriptions. It stops short of stating when NOT to crawl (e.g. use map for URL listing, scrape for a single page).

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 (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower, and the description adds genuinely new context: the endpoint must be HTTPS and the secret must be referenced by environment-variable name rather than transmitted. It does not disclose what happens on re-registration despite idempotentHint=false, nor what is returned.

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 short sentences, the primary action first and the credential rule second. No filler, and the security-critical caveat is stated directly rather than buried.

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 a write tool with 6 undocumented parameters, no output schema, and no annotation-backed detail on repeat registration, the description is thinner than the complexity warrants. The secret-handling rule is essential and present, but semantics for maxAttempts/enabled and the effect of duplicate registration are left uncovered.

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% across 6 parameters, so the description carries the burden and only partly discharges it: secretEnv is explained well (it names an operator environment variable) and url is implicitly constrained to HTTPS. monitorId, id, enabled, and maxAttempts (including its 1-100 bounds) get no explanation in either the schema or the 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?

States a specific verb and resource ('Register an HTTPS webhook for a Monitor'), and clarifies what a 'delivery destination' actually is (an HTTPS webhook), which resolves the main ambiguity in the tool name. It doesn't explicitly name sibling destinations like pause_delivery_destination or list_delivery_destinations, so it stops short of full differentiation.

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 context is only implied through 'for a Monitor' and the secret-handling caveat; there is no statement of when to create a destination versus using the pause/resume/list siblings, nor of prerequisites before registering. The 'never send the secret value' line is a real instruction but is about parameter input rather than tool selection.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description still adds non-obvious behavior: the paused default and the prerequisite that a delivery destination be configured first, which is real setup context not present in the schema or 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?

Three short sentences, front-loaded with the action and immediately followed by the two practical setup notes. No filler or repetition; each 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?

This is a mutation tool with 9 parameters, no required fields, an undocumented nested 'config' object, and no output schema. The description explains the paused default and preset but leaves an agent without guidance on the remaining parameters or the config shape, which is inadequate for a tool of this complexity.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate. It only touches the 'preset' enum value and obliquely references the paused/enabled default; url, config (a nested object), revision, monitorId, intervalMs, ruleVersion, and staleAfterMs are left entirely unexplained in both description and 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 ('Create a public-document Monitor'), so an agent knows the operation and target domain. It does not differentiate from siblings like preview_monitor or list_monitors, so the disambiguation work falls to the caller.

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 gives contextual hints — the monitor defaults to paused so a delivery destination can be configured first, and the firecrawl-introduction preset should be used on first use — which implies the intended setup flow. However, it names no alternatives (e.g., preview_monitor before committing) and states no when-not conditions.

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 establish this as a safe, idempotent, non-destructive read (readOnlyHint, idempotentHint, destructiveHint false), so the safety profile is covered. The description adds that status includes item counts and waitingForPerson, which is useful, but it doesn't disclose pagination, freshness, or error behavior when the id is unknown.

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

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

A single front-loaded sentence that leads with the action and identifier, with zero filler. The parenthetical 'waitingForPerson' is jargon but functions as a field name, which is acceptable in a one-line definition.

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?

An output schema exists, so return-value detail is not required, and annotations cover the safety profile. For a one-parameter read tool the description supplies enough to call it correctly, with the only gap being when to prefer the item/error siblings.

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

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

Schema coverage is 0% and the single parameter is named 'id', yet the description calls it 'taskId' — a partial clarification of what the id refers to, but the mismatch in naming could cause confusion. It does not state format, source, or whether the id is the batch id returned by batch_scrape.

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 ('Read') and resource ('batch's status') plus the fields returned (state, item counts, waitingForPerson). It distinguishes itself reasonably from get_batch_items and get_batch_errors by framing itself as the status view, though it never names those siblings explicitly.

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?

There is no when-to-use guidance and no mention of alternatives, despite many close siblings (get_batch_items, get_batch_errors, wait_batch, batch_scrape). The agent must infer from the noun 'status' that this is the lightweight polling call rather than the item/error detail 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?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavior beyond that: results span every attempt, are paginated at up to 1000 per page, and robotsBlocked carries robots.txt refusals while governance/SSRF refusals remain in errors — a subtle distinction an agent could not guess.

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 filler, and the purpose is front-loaded before pagination and return-shape detail. The second sentence is dense but each clause (page size, pagination keys, robotsBlocked carve-out) 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?

With no output schema and 0% schema coverage, the description correctly compensates by enumerating the returned error fields and the robotsBlocked list. Minor gaps remain: no mention of ordering, retry linkage, or whether the list is cumulative across attempts vs current-only.

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%, so the description must carry parameter meaning. It explains cursor/limit as the pagination pair and states the page ceiling, which partially compensates, but never describes what id refers to (batch id) or whether cursor is opaque.

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 with scope: 'a batch's items that did not succeed, across every attempt.' The word 'errors' plus 'did not succeed' cleanly separates it from the success-oriented sibling get_batch_items and from get_crawl_errors (a different resource).

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 when-to-use or when-not; the agent must infer that this is the failure-inspection call for a batch. It never names alternatives such as get_batch, get_batch_items, wait_batch, or cancel_batch, and gives no precondition (e.g., batch finished vs still running).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and a closed-world scope, so the safety profile is covered. The description adds real behavioral detail beyond that: that maxResults causes the tool to iterate cursors itself, and the shape of the answer ({ items, nextCursor, hasMore, stoppedBy }). That auto-pagination behavior is the key non-obvious trait.

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

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

A single dense sentence that front-loads the primary action and tucks the mode difference into a parenthetical clause. Efficient, though the trailing response-shape list makes it slightly overloaded for one sentence.

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 read-only paginated fetch with full annotation coverage and an output schema present, the description supplies what is needed: the paging model, the auto-follow option, and the result envelope. Nothing critical for correct invocation is missing, since return values are also covered by the output 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 only 20% (just maxResults), so the description must compensate, and it does add meaning for cursor, the 50-item limit, and maxResults' follow-cursors behavior. But it leaves 'id' and 'debug' unexplained, and it calls the id a 'taskId', which does not match the schema key and could mislead. Partial compensation warrants a mid score.

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: paging through a batch's results, with the identifier it keys on and the pagination modes. It is distinguishable from get_batch (metadata) and get_batch_errors (errors), though it never names those siblings explicitly to reinforce the boundary. Minor wrinkle: the text says 'by its taskId' while the required parameter is 'id'.

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 by contrasting the two paging modes (manual cursor/limit vs maxResults auto-follow), which is genuinely helpful context. However, it gives no explicit when-to-use guidance versus siblings like get_batch, get_batch_errors, or wait_batch, so selection still requires 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the bar is low. The description adds only that the read is keyed by taskId and returns counters for collapsed/refused links; it discloses nothing about staleness, caching, or behavior for an unknown id.

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

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

A single tight sentence with the keyed lookup front-loaded and no filler. It is dense but every clause names a distinct returned datum, so nothing is wasted.

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?

A one-parameter read tool with full schema coverage, complete annotations, and an output schema that already defines the return shape. The description adds the useful framing that this is the report view of a crawl, and nothing an agent needs to call it 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?

One parameter with 100% schema description coverage ('taskId from crawl'), so the schema already carries the meaning and baseline is 3. The description restates 'by its taskId' but adds no format, source, or lookup guidance 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 (Read) and resource (a crawl's report) plus what the report contains: status, page counts, and discovery counters. It is distinguishable from get_crawl_pages, get_crawl_errors, and wait_crawl by describing the report's contents, though it never names those siblings explicitly.

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 only implied: the agent gathers it should call this with a taskId to inspect a crawl. There is no statement of when to prefer this over wait_crawl (blocking) or get_crawl_pages/get_crawl_errors, so routing among the crawl-read siblings 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that results are paginated, which is useful beyond the annotations, but says nothing about ordering, error fields returned, or whether pagination is cursor-only. With annotations carrying the safety profile, a 3 fits.

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

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

A single front-loaded sentence with no filler, which is appropriate for a simple list tool. The brevity is efficient rather than padded, though one more clause on pagination or attemptId would have paid for itself.

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?

There is no output schema and zero schema description coverage across four parameters, so the description is the only place attemptId and cursor semantics could be explained — and it is silent on both. For a paginated error-listing tool an agent will likely misuse or omit attemptId on the first call.

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

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

Schema coverage is 0%, so the description must carry the parameter burden. It explains 'id' (task id) and hints at pagination via 'paginated', but 'attemptId' is never mentioned and 'limit'/'cursor' get no syntax or bounds (1-1000 maximum) beyond the raw schema types.

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?

Specific verb and resource: 'Read a paginated list of crawl errors by task id.' It clearly scopes to crawl tasks, which separates it from get_batch_errors and get_crawl_pages without naming them. It stops short of explicit sibling differentiation, but the resource is 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 phrase 'by task id' implies a prerequisite crawl task but states no conditions for when to call this versus get_crawl, wait_crawl, or get_crawl_pages. No alternatives or exclusions are named, leaving the agent to infer the intended situation.

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?

Adds substantial behavior beyond annotations: default omission of routing audit/trace, default suppression of status-duplicate pages, automatic cursor following when maxResults is set, and the exact response envelope. Annotations cover the safety profile while the description covers the data-shaping behavior, which is exactly the split needed here.

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?

Tight and front-loaded: purpose first, then two conditional filters, then the pagination mode. Every clause carries information, though the final sentences are densely packed with nested conditions that a reader must parse carefully.

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?

Covers the operation, its default filters, pagination semantics, and the key response fields even though an output schema exists. The one residual gap is how limit and maxResults relate when both are supplied, which matters for a 7-parameter paging tool.

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

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

Schema description coverage is only 29%, so the description carries most of the load: it explains the attemptId default, the debug and includeDuplicates filters, and the maxResults cursor-following semantics including stoppedBy. It leaves 'limit' vs 'maxResults' interaction and 'cursor' unexplained, so it doesn't fully close the coverage 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?

States a specific verb and resource: 'Read a paginated list of crawl page results by task id'. The scoping detail ('the latest attempt's unless attemptId is given') makes it distinguishable from get_crawl and get_crawl_errors. It never names a sibling explicitly, so differentiation is inferred from the resource rather than stated.

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 conditional usage for three flags: debug is needed to see routing audit and trace, includeDuplicates is needed to see repeated-content pages, and maxResults switches the tool into self-following cursor mode. There is no explicit when-not or named-alternative guidance, but the default behavior of each option is clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds one genuinely useful behavioral detail — that retry attempts are included in the response — but says nothing about not-found/error behavior or response shape.

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

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

A single front-loaded sentence with no filler; the useful detail (retry attempts) is placed immediately after the core purpose.

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 and zero parameter documentation in the schema, the description is the only source of parameter meaning, yet it leaves 'debug' entirely undefined and omits failure behavior. Rich annotations cover safety, but not enough to make this definition complete for correct 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 description coverage is 0%, so the description must carry parameter meaning and does not. The required 'id' is only inferable from the tool name, and the 'debug' boolean is completely unexplained — an agent cannot tell what it changes or when to set it.

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

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

The verb 'Inspect' plus the resource 'one delivery' is specific, and 'and its retry attempts' scopes what comes back, distinguishing it from list_deliveries and retry_dead_letter. It does not explicitly name the sibling it replaces, but the singular scoping makes the distinction inferable.

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 only implied by the singular 'one delivery' phrasing; there is no explicit statement of when to call this versus list_deliveries or how to obtain the required id. No exclusions or prerequisites are given.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds useful content about what data comes back (baseline, latest run, latest event, next schedule), which is meaningful beyond the annotations, though it omits any detail on error behavior or what happens for a nonexistent id.

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

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

A single tight sentence that front-loads the resource and lists the returned facets with no filler. Efficient, though extremely terse for a tool whose parameters are entirely undocumented.

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 read-only tool with no output schema, the description usefully previews the returned fields and annotations cover safety. However, the total absence of parameter explanation for both id and debug leaves a real gap for correct 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 description coverage is 0% for two parameters, and the description never mentions 'id' or 'debug'. With low coverage the description is expected to compensate, but it provides no hint about what the id refers to (monitor UUID, slug, etc.) or what debug does.

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 names a specific resource (Monitor) and enumerates the facets it retrieves (baseline, latest run, latest event, next schedule). 'Check' is a slightly soft verb, but the returned-fields list makes the intent concrete and separates it from list_monitors, get_monitor_run, and create_monitor.

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?

There is no guidance on when to use this tool versus siblings like get_monitor_run, list_monitors, or preview_monitor, and no prerequisites or exclusions are stated. The agent must infer usage from the name alone.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. With no output schema, the description does carry some return-content burden and partially meets it by naming evidence and failure reasons, but it says nothing about pagination, result size, or what happens if the run is still in progress.

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

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

A single tight sentence with the key content (assessment, evidence, failure reasons) front-loaded and 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 read tool with two required identifiers and an undocumented debug flag plus no output schema, the description leaves too much unspecified. An agent cannot tell which identifier to use or what debug changes, and there is no output-shape information to fall back on.

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% for three parameters (id, runId, debug), and the description explains none of them. 'Inspect a run' loosely implies runId identifies the run, but the distinction between id and runId, and the purpose of the debug flag, remain completely undocumented.

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 names a specific verb ('Inspect') and resource ('a run'), and adds that it surfaces field assessment, evidence, and failure reasons. That is clearer than a bare 'Get a Monitor run', though it never contrasts itself with get_monitor or get_crawl/get_scrape.

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?

There is no indication of when to call this versus siblings like get_monitor, run_monitor, cancel_monitor_run, or list_monitors, nor any prerequisite such as needing a completed run. Usage has to be inferred entirely from the name.

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

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds real behavioral content beyond them: it enumerates what the record holds (request with header names substituted, verdict, lanes tried, usage, warnings), states the explicit boundary 'no page body', and discloses the retention policy ('kept without a time limit'). It stops short of auth or rate-limit detail, so not a 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?

Two sentences, front-loaded with the core action and identifier before the content inventory. The list of held fields is dense but each item is informative; nothing is pure filler, though the inventory is slightly long.

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?

An output schema exists, so return values needn't be explained; the description nonetheless covers purpose, record contents, the page-body exclusion, and retention. For a single-parameter read tool this is complete, missing only explicit alternative-tool routing.

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

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

Schema description coverage is 100%, so the schema already documents the single id parameter and the description only echoes that it is 'metadata.scrapeId on the response'. Marginal added value, consistent with the baseline 3 when structured fields do 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 (Read) and resource (one scrape call's record) and keys it to the scrapeId, clearly distinguishing it from the scraping sibling (scrape) and from get_crawl/get_batch record readers by resource. An agent can select it without opening the 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?

The definition implies usage ('by its scrapeId, which is metadata.scrapeId on the response') so an agent knows it is a post-scrape lookup, but it names no alternative tools or when-not conditions (e.g., versus get_batch_items or get_crawl_pages for other record types). Usage is inferable rather than stated.

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

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

Beyond the annotations, it discloses substantial behavior: waits up to waitMs per page (default 600000), reads a page only after the person interacts in its tab, requires local server plus remote debugging and a one-time Allow click, and explicitly states Octocrawl itself does not pass checks. It also documents the return shape.

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?

Front-loaded with the core action and scoped tightly; every sentence carries information about timing, prerequisites, or return values. The long semicolon-chained sentences and dense clauses slightly reduce scannability.

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 supplies the return fields ({ id, handedOff, through, notThrough, items }) and covers prerequisites, timing defaults, and post-interaction behavior. An agent has everything needed to invoke 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 description coverage is 0%, so the description must carry parameter meaning. It does explain waitMs well (default 600000, per-page wait, bounded by the schema's min/max), but the required 'id' parameter is never explicitly identified as the batch id — it is only inferable from 'a finished batch's items'.

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 and resource ('hand ... items that a check stopped to the person'), plus scope details ('one tab at a time', 'in their own Chrome'). It is clearly distinguishable from siblings like get_batch and wait_batch, which only report or wait on batches.

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 defines the triggering condition precisely — items flagged by a check (captcha, challenge, login wall) surfaced via get_batch's waitingForPerson — and states prerequisites: local server only, Chrome remote debugging enabled, person must click Allow once. It stops short of explicitly naming which sibling to use instead when no check is blocking.

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 mark it non-readonly/destructive/non-idempotent; the description adds the real behavioral context: local-server-only, it blocks waiting on the person (up to 2 minutes default), Chrome shows an approval prompt, and it replaces any existing login for the domain. It also pre-empts a security concern by stating the response never contains a cookie or stored 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?

Dense but front-loaded: the purpose and effect land in the first clause, then prerequisites, then the return shape. The semicolon-chained sentences are information-rich, though the return-field enumeration ('...') is slightly loose 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?

With no output schema, the description still describes the return shape (domain, savedAt, cookieCount, localStorage, sessionSha256) and what it never returns. Prerequisites, timeout, approval flow, and replace-on-conflict semantics cover everything needed to invoke 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 0%, so the description carries the full burden and does: 'site' is defined as a domain or a page URL on it, and 'approveTimeoutMs' is explained as the Chrome approval wait with a stated default of 120000. Both of the two parameters gain meaning absent from 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 (save the person's login to a site) and immediately names the downstream effect ('so mode authed reads its pages signed in as them'), which separates it from list_logins and remove_login at a glance. The scope detail (domain or page URL) is concrete rather than tautological.

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 clear conditional context: the person must be signed in to Chrome's default profile with remote debugging on, and the agent must 'ask the person first and name the site'. It also supplies a when-not rule ('a site a page led you to is not theirs to save'). It stops short of explicitly naming sibling alternatives, so 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real behavioral context: only process-local crawls, including startup-resumed ones, and an explicit empty-result state. It does not mention pagination or result ordering, keeping it short of a 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?

A single dense sentence, front-loaded with the verb and the scope qualifier, and the returned fields are appended compactly. The nested parenthetical is slightly clunky but nothing is wasted.

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 does so by enumerating id, start URL, status, pages so far, and start options. Combined with the explicit empty-state note, an agent has everything needed to call and interpret this 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?

The tool takes zero parameters, so the baseline is 4 per the rubric. There is nothing for the description to disambiguate, and it correctly avoids inventing 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 (list) and resource (crawls) with a precisely scoped qualifier: crawls the API process is running, including those resumed at startup. The parenthetical 'never a batch' distinguishes it from batch-oriented siblings, so an agent can separate it from get_batch/get_crawl 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?

The 'never a batch' clause gives an implicit exclusion and 'Empty when nothing runs' hints at the precondition, but no alternative is named for the single-crawl case (get_crawl) or the batch case. Usage is implied rather than stated, which is the definition of a 3.

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 establish readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds that results are paged and default to 20 'compact' results, which is useful context. It omits pagination semantics (cursor behavior), auth requirements, and what state/failure data actually looks like.

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

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

A single front-loaded sentence with no filler that leads with the verb and the paging/default behavior. It is dense but readable; the parenthetical 'jobId, the taskId' phrasing is slightly awkward and mildly muddies an otherwise tight statement.

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 7-parameter list tool with no output schema and no required params, the description covers the primary selectors and the default result size, and output format need not be explained. It is missing guidance on cursor usage and the purpose of destinationId and debug, and the stray taskId reference is an incompleteness.

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%, so the description carries the burden for 7 params. It does add selector meaning for monitorId and jobId and implies the state filter and the limit default of 20. But it leaves debug, destinationId, and cursor unexplained, and confusingly references a 'taskId' that does not appear in the schema — a notable gap given zero 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?

States a specific verb (page through) and resource (deliveries) with scope (state and failures), and names the two selecting entities (monitorId for monitors, jobId for crawl/batch). This distinguishes it from get_delivery (single item) and retry_dead_letter in the sibling set. It stops short of explicitly contrasting with list_delivery_destinations, which is a different resource.

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 by explaining the two scoping modes (a monitor vs a crawl/batch), which tells the agent when each id applies. However, it gives no explicit when-to-use guidance against sibling tools like get_delivery or retry_dead_letter, and no exclusions. Usage is inferable but not stated.

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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds a non-obvious behavioral fact beyond structured data: custom header names are returned but never their values — a privacy guarantee an agent would otherwise not know. Pagination and result shape remain undisclosed.

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

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

A single front-loaded sentence with the primary purpose first, the optional filters second, and the header-value caveat last. No filler or restatement of the title.

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-param read-only list tool with no output schema, the essentials are present: what is listed, how it is scoped, and a key caveat about header values. Missing only minor items such as pagination and the exact returned fields.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does explain both parameters: monitorId scopes to one Monitor, jobId scopes to a crawl or batch task. The phrasing "jobId, the taskId" is slightly ambiguous about whether those are the same identifier, and it doesn't state whether the two filters are mutually exclusive.

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+resource ("List webhook destinations") and immediately qualifies scope by filter. An agent can distinguish it from create/pause/resume destination siblings by the verb alone, though no sibling is named explicitly and the potentially confusable list_deliveries is not addressed.

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 states that filtering is optional and maps the two filter modes (per-Monitor vs per crawl/batch), which is genuine usage context. However, it never says when to prefer this over list_deliveries or get_delivery, nor what happens if both filters are supplied, so routing guidance is only 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?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety bar is lower. The description adds genuine value beyond them by disclosing the record shape and the security-relevant boundary 'never a cookie or a stored value', which tells the agent what sensitive data is NOT exposed. It omits pagination and auth details, keeping it short of a 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?

It is a single dense sentence with no filler, and the key caveat ('never a cookie or a stored value') is placed last for emphasis. The inline JSON shape makes the sentence run-on, but since there is no output schema that information 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?

With no output schema, the description correctly carries the return-value burden and enumerates the fields (domain, savedAt, cookieCount, localStorage, sessionSha256), so the agent knows what it receives. The only real gap is usage routing, which leaves it just short of 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 tool takes zero parameters, which sets the baseline at 4. The description appropriately spends its budget on return contents rather than parameters, and there are no parameters that need semantic clarification.

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 identifies the resource precisely ('The person's saved logins') and names the sibling that populates them ('import_login, octocrawl login import'), so an agent can tell this is a read of imported login records. It stops short of an explicit list verb and only partially distinguishes itself from remove_login, so it is clear but not fully sibling-differentiated.

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?

There is no explicit guidance on when to call this versus alternatives; the agent is left to infer usage from the name and the mentioned import_login relationship. remove_login is a natural comparison point but is never referenced, and no preconditions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's addition of "current state and freshness" hints at a data-staleness trait that annotations do not convey, but it is not elaborated (how fresh, refreshed when, pagination, ordering).

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

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

A single front-loaded sentence with no filler or repetition. It is efficient, though "freshness" is left undefined, which costs it the top score.

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 read-only list tool with full annotation coverage this is minimally viable, but with no output schema the agent gets no sense of what fields (state, freshness, identifiers) come back, and the `debug` flag is unexplained. It is adequate but has clear gaps.

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

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

Schema description coverage is 0% and the description never mentions the single `debug` parameter, so nothing in the text clarifies its effect on output or behavior. The parameter name is fairly self-evident, which prevents a 1, but the description does not compensate for the coverage 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?

States a clear verb+resource ("List ... Monitor") and adds scope ("current state and freshness"), which an agent can distinguish from get_monitor or preview_monitor by the standard list-vs-get convention. It does not explicitly name siblings or clarify what a "monitor" is in this product, so it falls short of a 5.

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 no when-to-use guidance, no conditions selecting it over get_monitor, and no prerequisites. Usage is only inferable from the verb "List" and the sibling naming pattern, which is weaker than explicit 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?

Goes well beyond the annotations (readOnly/openWorld/idempotent/non-destructive) by disclosing deadline semantics (partial results, stoppedBy timeout), exactly what is folded or counted, robots.txt handling, and the compact-vs-debug output difference. This is the kind of behavioral context annotations cannot express.

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?

Front-loaded with the core action and tightly packed with no filler sentences; every clause carries a distinct fact. The multi-clause sentences in the middle are dense enough to demand a re-read, which keeps it just short of a 5.

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 16-parameter tool with an output schema already covering the return shape, the description supplies the missing operational context: scope rules, deadline behavior, filtering, and output verbosity. An agent has everything needed to call 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 the schema already documents all 16 parameters and the baseline is 3. The description reinforces the behaviorally significant ones (ignoreRobotsTxt, debug/compact default, the deadline interaction with timeout), adding coupling context rather than mere restatement.

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 ('List a site's URLs') and immediately bounds scope: start page links plus declared sitemap entries, read without fetching page bodies. It also excludes itself from sibling tasks ('Not for: reading pages'), so an agent can separate it from scrape/crawl 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 a clear exclusion ('Not for: reading pages, as one page body is read at most') and states conditional behavior (robots.txt applies unless ignoreRobotsTxt is set), which guides tool selection. It stops short of naming the alternative sibling tools (scrape/crawl) explicitly, leaving that routing 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 declare this is a non-read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds real behavioral value beyond that by disclosing what happens to in-flight work: pending deliveries are held rather than dropped, which matches destructiveHint=false and tells the agent this is reversible. It still says nothing about permissions 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?

A single sentence that front-loads the action and immediately qualifies its scope. No filler, no restatement of the title.

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 state-mutation tool with no output schema, the description adequately conveys the effect on new and pending deliveries. However, it leaves the `debug` parameter completely unexplained and gives no signal about what a successful pause returns or how to confirm the new state.

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% across two parameters. The description never mentions the required `id` or the optional `debug` flag, so an agent gets no guidance on what `debug` changes or what format `id` takes. With two undocumented parameters, the description fails to compensate for the coverage 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?

States a specific verb and resource ("Stop new deliveries to a webhook destination") and even hints at the inverse operation via "until it resumes," which points at resume_delivery_destination. It is clear on its own but never names the sibling, so an agent must infer the pairing.

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 clause "pending ones wait until it resumes" implies this is the pause half of a pause/resume pair, giving implied usage. There is no explicit statement of when to pause versus cancel or retry dead-letter deliveries, nor any prerequisites.

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 idempotentHint=true, so the safety profile is covered. The description adds real value by specifying what is destroyed — the active execution — but omits auth requirements, reversibility (that resume_monitor can undo it), and any side effects on queued runs.

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

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

A single compact sentence that front-loads the operation and its consequence. 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?

No output schema exists, so return values need not be described, and annotations carry the safety profile. However, with undocumented parameters, no usage routing, and an unstated relationship to resume_monitor, the definition is only minimally sufficient for a mutation tool.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and does not. The required 'id' is self-evident, but the optional 'debug' flag is undocumented in both schema and 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?

States a specific verb+resource (pause a monitor) and pinpoints the two effects: it stops scheduling and cancels the in-flight execution. This distinguishes it from resume_monitor and cancel_monitor_run without opening schemas, though it never names those siblings explicitly.

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

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

No guidance on when to pause versus cancel_monitor_run or resume_monitor, and no prerequisites or state conditions are given. The agent must infer usage from the operation name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld, so safety is covered. The description adds the useful 'nonpersistent sample' cue (a dry-run that does not persist), which is real context beyond the annotations, but says nothing about permissions, side effects of `url`/`config`, or what the preview response contains.

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 short sentences with no filler; the start-with-preset instruction is front-loaded after the purpose. It is tight, though the first sentence is dense with undefined terms rather than being wastefully long.

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 9-parameter tool with nested objects, zero schema description coverage, and no output schema, the two-sentence description leaves most of what an agent needs undocumented. The only actionable detail is the preset starting point; parameter formats and expected preview output are absent.

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

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

Schema coverage is 0% across 9 parameters including a nested `config` object, so the description must compensate and largely does not. It only echoes the single enum value for `preset` and never explains `url`, `config`, `revision`, `monitorId`, `intervalMs`, or `staleAfterMs`.

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 gives a verb ('Capture') and describes outputs ('identity, fields, evidence, and missing reasons') plus the 'nonpersistent' nature, but never names the resource — that it previews a monitor's behavior is only inferable from the tool name and title. 'Assess identity, fields, evidence, and missing reasons' is jargon that doesn't crisply distinguish it from siblings like run_monitor or get_monitor.

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?

'Start with preset firecrawl-introduction' hints at an initial invocation path, but there is no when-to-use vs when-not guidance and no mention of alternatives such as run_monitor or create_monitor. The agent gets no explicit signal about when a preview is preferred over actually running or creating a monitor.

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, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds useful scoping context (a site can be a domain or a page URL), but says nothing about whether removal is permanent, whether a domain removes logins for all URLs on it, or what happens when no login exists.

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

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

A single front-loaded sentence with no filler; the scope clarification is packed into a parenthetical rather than bloating the text.

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

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

For a one-parameter, no-output-schema tool whose annotations already convey destructiveness and idempotency, the description covers the essentials. The only meaningful gap is the domain-vs-URL removal scope.

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%, so the description must carry the param meaning and it does: "site" accepts either a domain or a page URL on it. What remains unclear is whether passing a page URL forgets only that login or all logins for the domain, which limits it below a 5.

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 ("Forget") and resource ("the person's saved login to a site"), so an agent immediately understands this is a removal operation on stored credentials. It does not explicitly name the neighboring tools (import_login, list_logins) it should be chosen against, but the verb is 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?

There is no guidance on when to use this versus import_login or list_logins, nor any prerequisite such as authentication or the login needing to already exist. Usage is only inferable from the verb.

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 (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds real behavioral value beyond them: the resume reuses the original start options (so no reconfiguration is possible) and the call returns { taskId } rather than results, requiring polling. It does not mention auth or rate limits.

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

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

Two short sentences, zero filler, with the core action front-loaded and the essential follow-up workflow packed into the second sentence.

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 supplies the return shape ({ taskId }) and the polling instruction, which the agent needs to call this correctly. Missing only edge-case behavior such as what happens when resuming an already-running crawl or whether existing results are preserved.

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 with 0% schema description coverage, so the description carries the burden for 'id'. It implies the id selects the paused/failed crawl to restart, but gives no format, type, or source (e.g. from crawl/get_crawl) guidance, so it only partially compensates.

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?

Specific verb (Restart) plus resource (crawl) plus the state constraint that makes it applicable (paused or failed). It distinguishes itself from crawl/get_crawl/cancel_crawl by naming the target state, and it names get_crawl as the follow-up polling 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 precondition 'paused or failed crawl' tells the agent when this tool is valid, and 'poll get_crawl' tells it what to do next. There is no explicit when-not (e.g. behavior if the crawl is running or completed), so it stops short of full routing guidance.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description does add one genuine behavioral detail beyond structured data — that pending deliveries are included, not just future ones — but says nothing about permissions, timing, or effects on previously failed deliveries.

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

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

A single efficient sentence that front-loads the action. Nothing is wasted, though it is arguably a touch thin for a mutating operation.

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?

Annotations carry the safety profile and no output schema exists, so the description needn't explain returns. However, for a state-changing endpoint it omits the required id's role and any consequence for deliveries that were already dropped, leaving a modest 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?

Schema description coverage is 0% for two parameters, so neither 'id' nor 'debug' is explained anywhere. The description provides no parameter meaning at all, leaving the agent to guess what 'debug' does.

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?

Specific verb+resource: resume deliveries to a paused webhook destination, with the extra scope of pending deliveries. It clearly stands apart from pause_delivery_destination, though it doesn't name that sibling explicitly.

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 phrase 'to a paused webhook destination' implies the precondition for use, so context is implied but never stated as an explicit rule. No alternative tool is named for the opposite action.

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 annotations already declare this is a non-read-only, open-world, non-idempotent, non-destructive operation. The description adds useful behavioral context that the first run becomes due immediately, but it does not cover permissions, return behavior, 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 a single front-loaded sentence with no wasted words. It states the action and the key scheduling effect immediately.

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 mutation tool with two parameters and no output schema, the description is too sparse. It communicates the core action but leaves parameter meanings, especially the required monitor id and the debug flag, undocumented.

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 does not mention either parameter. The required 'id' is only loosely inferable from context, while the optional 'debug' parameter is entirely unexplained in both the schema and the 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 states a specific verb and resource: 'Resume Monitor scheduling.' It also adds scope by noting the first run becomes due immediately, which helps distinguish it from simply running the monitor. Sibling differentiation is implicit through the pause_monitor and run_monitor siblings, but no sibling is named explicitly.

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 does not state when to use this tool versus alternatives such as run_monitor or resume_crawl. It implies the action of resuming a paused monitor, but no prerequisites, exclusions, or alternative-selection guidance are provided.

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 disclose the key traits: readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true. The description adds nothing beyond that — it does not warn that a non-idempotent retry may produce duplicate deliveries, nor explain what happens if the retry fails again. With annotations already carrying the safety profile, this is a thin contribution.

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?

One short, front-loaded sentence with the action stated first. 'Explicitly' is mildly redundant filler but the description is otherwise tight.

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 mutating, non-idempotent retry with no output schema, the description omits essential context: the state a delivery must be in, whether retries can duplicate deliveries, and what the caller gets back. Annotations cover safety hints but not the operational behavior an agent needs before invoking it.

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

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

Schema coverage is 0% for the single required parameter, so the description must compensate. Calling it an 'eventId' does convey that the id identifies the event being retried, which is more than the bare schema offers, but the name mismatch with the schema's 'id' risks confusing the agent about what value to pass.

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 (retry) and resource (a dead-letter delivery), which is enough to distinguish it from the surrounding scrape/crawl/delivery-listing siblings. It is slightly clouded by referring to 'the same eventId' when the sole schema property is named 'id', leaving ambiguity about whether these are the same identifier.

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?

There is no statement of when to use this tool versus alternatives, no prerequisites (e.g., the delivery must be in dead-letter state), and no mention of when not to retry. The word 'Explicitly' hints at manual triggering but gives no operational context.

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

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

With annotations already declaring readOnly=false, idempotent=false, openWorld=true, and destructive=false, the description still adds real behavioral context: the run is queued asynchronously (runId returned immediately) and survives client disconnection. This durability/async semantics goes beyond what the structured fields convey.

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 short sentences, zero filler, and the most decision-relevant fact (immediate runId return) is front-loaded right after the action statement.

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 reasonably covers the return value (runId) and the async/durability behavior. However, for a state-mutating tool with two fully undocumented parameters and an unexplained triggerKey, the definition stops short of what an agent needs to call 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 description coverage is 0% for two parameters, so the description must compensate — and it does not. Neither `id` (the monitor identifier) nor `triggerKey` (plausibly a dedupe/correlation key, especially given idempotentHint=false) is explained, so the agent is guessing about their formats and interaction.

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 action ("Queue a durable manual run") and the title confirms the resource is a Monitor, so an agent knows this enqueues a monitor execution. It does not, however, differentiate itself from close siblings such as preview_monitor, create_monitor, or get_monitor_run, leaving the agent to infer the distinction from names 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?

There is no explicit when-to-use guidance and no named alternative. The word "manual" hints that this contrasts with scheduled runs, but nothing tells the agent when to prefer this over preview_monitor (likely a dry run) or whether a monitor must already exist.

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

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

Annotations cover openness (openWorldHint) and mutation profile, and the description meaningfully extends them: HTTP-first with browser fallback when a page needs scripts, compact-by-default with debug expanding to a full audit, and named warnings (client_rendered_suspected, robots_overridden) plus agentHints. It stops short of stating auth, rate-limit, or failure-mode behavior (timeout/partial) that a 29-param fetcher could exhibit.

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?

Front-loaded with the core read and its return artifact, then exclusions, then output-shape notes. Dense but every clause carries information; the proofreader texture (parenthetical field lists) is slightly heavy but not wasted.

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 29-parameter tool with nested objects and a dedicated output schema, the description covers the important non-schema context: the HTTP/browser execution ladder, the default-return posture, and the meaning of warnings and hints. Return-value explanation is rightly delegated to the output schema, leaving little 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 97%, so parameters are already thoroughly documented and the baseline is 3. The description adds output-side semantics (compact vs. debug, warnings, agentHints, scrapeId for get_scrape) but no extra meaning for the input parameters themselves.

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 ("Read one URL as Markdown") plus the exact artifact returned (the Evidence Record with its fields), and distinguishes itself from siblings with an explicit "Not for: many URLs or a whole site section." An agent can separate this from crawl, batch_scrape, and map without opening any 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?

The "Not for" clause gives a clear exclusion that routes the agent to crawl/batch, and "metadata.scrapeId names the call's record for get_scrape" implies the read-back path. However, it never names crawl or batch_scrape explicitly, so the alternative-routing is inferential rather than spelled out.

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 readOnly, idempotent, openWorld and non-destructive. The description adds useful extra context by noting access is anonymous (no login needed) and that no schema/model setup is required, but it says nothing about rate limits, throttling, or failure behavior for invalid URLs.

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 short sentences, front-loaded with the core action and scope. The trailing 'No schema or model setup needed' is mildly promotional but still informative about setup 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?

For a simple single-URL scrape tool this covers the essentials, but with no output schema the description gives only 'JSON' with no hint of the returned fields, and the undocumented debug parameter leaves a gap an agent cannot resolve.

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%, so the description must carry the parameter burden. It partially does by revealing the URL shape (/dp/{ASIN} on amazon.sg), but the optional 'debug' parameter is never explained in either schema or 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?

States a specific verb and resource: fetch JSON for one anonymous Amazon.sg /dp/{ASIN} product. The 'one product' scope implicitly separates it from batch_products and the generic scrape sibling, though it does not name them.

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?

There is no explicit when-to-use / when-not-to-use guidance and no named alternative. A reader must infer that this is the single-product path versus batch_products or the generic scrape tool based on the word 'one'.

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 readOnly, idempotent and non-destructive, so safety is covered. The description adds the traits that matter here: bounded blocking behavior, the default timeout (30000), the hard cap (120000), and the fact that a timeout returns partial status rather than failing. It does not say whether the call holds a connection open or whether repeated waits are rate-limited, which is minor.

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

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

A single dense sentence with the blocking behavior, timeout bounds, and fallback action front-loaded in that order. No filler, and every clause carries unique 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 an output schema present, return values need not be explained, and annotations cover the safety profile, so the description is nearly complete for a two-parameter polling tool. The only missing piece is a pointer to get_batch for a non-blocking status check versus this blocking wait.

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%, so the description must carry the load. It fully documents the non-trivial parameter timeoutMs (default 30000, maximum 120000) and implies the required 'id' is the batch identifier via 'a batch to finish'. That adds the default value and blocking semantics the schema lacks, though 'id' itself is never explicitly described.

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 ('wait') plus resource ('batch') and the exact semantics: block until finished or timeout, then return current status. It also names the sibling get_batch_items as the place to go for items, so an agent can distinguish it from get_batch without opening either 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 gives clear operational guidance: if the timeout elapses, either call wait again (polling pattern) or read get_batch_items. That covers the follow-up action explicitly, but it never contrasts itself with the non-blocking get_batch sibling, so the choice of when not to use a blocking wait is left implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: it is a blocking call with a timeout (default 30000, ceiling 120000) and it may return a partial report rather than failing, which is the key non-obvious trait for an agent to plan around.

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

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

A single dense sentence with the default/max values front-loaded and the timeout fallback at the end. Nothing is padding; every clause (wait, timeout bounds, report return, partial result, next step) carries distinct 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?

An output schema exists, so return-value shape need not be described, and annotations carry the safety profile. Given that, the description covers everything needed to invoke and recover correctly: the blocking semantics, the timeout bounds, and the follow-up path after a partial return.

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 only 50% – timeoutMs has a type and bounds but no description. The description compensates by supplying the default (30000) and the effective cap (120000), which is the operationally important information. It does not restate the 'taskId from crawl' meaning of id, which the schema already covers.

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 names a specific verb (wait) and resource (a crawl) and states the outcome: it blocks until the crawl finishes and returns its report. It also implicitly separates itself from the plain get_crawl status check by emphasizing the blocking/waiting semantics and by routing to get_crawl_pages when incomplete.

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 gives clear usage context: 'at the timeout it returns the report so far, so wait again or read get_crawl_pages.' That tells the agent exactly what to do when the wait does not complete, which is the main decision point for this tool. It stops short of an explicit when-not-to-use statement versus get_crawl or wait_batch.

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