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

With no annotations, the description carries the full burden and delivers: server-side execution model, returned structured trace plus success/failure status, plan gating (Starter+), metered cost model (2 base + 1 per step), session reuse vs ephemeral browser, credential redaction, and a security posture (untrusted page text, prompt-injection resistance, tighten allowedDomains, avoid destructive flows). This is unusually rich behavioral disclosure.

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 mechanism, then routing, then cost/plan, then security. Despite being dense, every sentence carries distinct actionable information (what it does, when to prefer it, pricing, safety). 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 complex 6-param, nested-object, no-output-schema tool, the description covers everything an agent needs: execution model, return shape (trace + status), cost, plan eligibility, session semantics, and security constraints. Nothing essential is missing.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including the credentials sub-object and its redaction behavior. The description reinforces the goal concept with examples and advises scoping allowedDomains tightly, but adds little parameter syntax or meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Give PageBolt a URL and a plain-English GOAL') and precisely delineates its role — the 'hands' on top of observe_page (the 'eyes') — with a clear description of the observe→plan→act→verify loop. It is immediately distinguishable from siblings like observe_page and run_sequence.

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

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

Explicitly names the alternative ('use run_sequence when you already know the exact deterministic steps/selectors (cheaper)') and gives the selecting condition ('when you only know the OUTCOME you want'), backed by two concrete goal examples. This is exactly the when-to-use vs alternative guidance the dimension asks for.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks usage and limits, implying a read-only operation, but doesn't specify if it requires authentication, returns real-time data, includes rate limit information, or has any side effects. This leaves gaps in understanding the tool's behavior beyond the basic purpose.

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, clear sentence: 'Check your current PageBolt API usage and plan limits.' It is front-loaded with the core purpose, has zero waste, and is appropriately sized for a tool with no parameters. Every word earns its place by conveying essential information without fluff.

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

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

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks details on behavioral aspects like authentication needs or return format. Without annotations or output schema, the description should ideally provide more context on what 'check' entails, but it's adequate for a simple read operation, though with 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?

The tool has 0 parameters, and the schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it appropriately avoids unnecessary details. A baseline score of 4 is applied as it efficiently handles the lack of parameters without redundancy.

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

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

The description clearly states the tool's purpose: 'Check your current PageBolt API usage and plan limits.' It specifies the verb ('check') and resource ('PageBolt API usage and plan limits'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'list_sessions' or 'list_devices', which might also involve checking or listing resources, though those are more specific to sessions and devices rather than API usage.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, such as needing an active session or authentication, nor does it suggest scenarios where checking usage is appropriate (e.g., before running resource-intensive operations). With no explicit when/when-not statements or named alternatives, it leaves usage context implied at best.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return type ('Returns an image') but lacks critical details: whether this is a read-only operation, if it has rate limits, what happens with invalid inputs, authentication requirements, or error behavior. For a 12-parameter generation tool, this leaves significant behavioral gaps.

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 perfectly concise - two sentences that directly state the tool's function and return value with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the key capabilities without unnecessary elaboration.

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

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

For a complex 12-parameter image generation tool with no annotations and no output schema, the description is incomplete. While it states what the tool does, it lacks crucial context about the returned image format, error handling, authentication needs, and practical usage scenarios. The high parameter count and generation nature demand more comprehensive guidance than provided.

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 all parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'built-in templates or custom HTML' which aligns with the template and html parameters, but doesn't provide additional semantic context. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Generate') and resource ('Open Graph / social card image'), distinguishing it from siblings like generate_pdf or take_screenshot. It explicitly mentions both built-in templates and custom HTML options, providing a comprehensive purpose statement.

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

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

The description provides no guidance on when to use this tool versus alternatives like generate_pdf or take_screenshot. It doesn't mention prerequisites (e.g., Growth plan+ for HTML), typical use cases for social cards, or when to choose templates over custom HTML. The agent receives no contextual usage instructions.

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

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

No annotations are provided, so the description carries the full burden, and it delivers real operational facts: plan gating, state persistence across calls, a 10-minute inactivity expiry with a 30-minute hard cap, and that the returned session_id must be passed to consumers. It omits cleanup semantics (that destroy_session should be called) and any failure/auth error behavior.

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

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

Four sentences, all earning their place: purpose, mechanism, handoff instruction, and expiry limits. The final sentence restates the use case already implied earlier and could be trimmed, but the description is well front-loaded.

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

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

With no output schema, the description usefully discloses that a session_id is returned and how long the session lives, plus the plan requirement. For a stateful resource-creating tool it could go further on teardown and resource/memory implications, but an agent has enough 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 100%, so cookies, stealth, and viewport are already documented in the schema (including the stealth memory warning). The description adds no parameter-level meaning beyond the flow of the returned session_id, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Create a persistent browser session') and immediately scopes the concept of persistence: a live page keeping cookies, localStorage, and auth state. It differentiates itself from siblings by naming the consumers (take_screenshot, run_sequence) and by implying the lifecycle opposite of destroy_session/list_sessions.

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 concrete when-to-use scenario ('AI agent workflows that log in once and then take multiple screenshots of authenticated pages') and a prerequisite (Starter+ plan required). It does not state when NOT to use it, e.g. that a one-off screenshot should call take_screenshot directly without a session.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a destructive operation ('destroy', 'frees immediately'), explains the benefit ('free up capacity'), and clarifies timing ('before it expires'). However, it doesn't mention potential side effects or error conditions.

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 perfectly concise with three focused sentences that each add value: first states the action, second explains immediate effect, third provides usage guidance. No wasted words, and information is front-loaded appropriately.

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 destructive single-parameter tool with no annotations and no output schema, the description provides good context about purpose, timing, and benefits. It could be more complete by mentioning what happens if the session doesn't exist or if destruction fails, but overall it's quite helpful for the agent.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.

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

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

The description clearly states the tool's purpose with specific verbs ('destroy', 'frees') and identifies the resource ('persistent browser session'). It distinguishes from siblings like 'create_session' and 'list_sessions' by focusing on termination rather than creation or listing.

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

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

The description explicitly states when to use this tool ('when you are done with a session to free up capacity') and provides a clear alternative scenario (letting it expire naturally). It also distinguishes from siblings by focusing on session termination rather than other session-related operations.

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

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

With no annotations, the description carries the burden and does well: it discloses the return artifact (JSON to paste into Import JSON), the optional persistence side effect (save:true lands in Saved Automations and the Library), and that it is non-executing and quota-free. It omits failure modes and any auth/permission requirements, so it falls 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?

Front-loads the core transformation and return value, then layers usage and safety guidance. Dense but the two sentences are long and include some parenthetical detail; still, no sentence is 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 9-parameter tool with nested objects and no output schema, the description explains the nature of the return (JSON for import) and the key side effect, which is the right level of detail. It does not sketch the JSON shape or note limits (e.g., 100-step cap), leaving minor 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 100%, so baseline is 3, but the description adds real meaning beyond the schema by explaining save:true's destination and by giving a safety rule for step contents ('Put {{username}}/{{password}} placeholders in fill steps instead of real credentials; never include cookies').

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 concrete verb+resource: turning a list of steps into an editable, re-runnable PageBolt sequence and returning JSON for the dashboard Sequence Builder. It explicitly differentiates from siblings by saying it does not run the sequence, unlike record_video / run_sequence.

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 an explicit trigger ('Use it after you have planned a video/sequence'), the benefit for the user (tweak steps/highlights/narration), the follow-up tools (record_video / run_sequence), and a clear exclusion ('Does not run the sequence or consume quota').

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the PDF is saved to disk and returns a file path, which is useful. However, it doesn't address critical behaviors like error handling, performance characteristics, file system permissions needed, whether the operation is idempotent, or what happens if the URL is inaccessible.

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 appropriately concise with two sentences that efficiently convey the core functionality and outcome. It's front-loaded with the primary purpose. However, it could be slightly more structured by separating input options from output behavior.

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

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

For a tool with 14 parameters and no annotations or output schema, the description is minimally adequate. It covers what the tool does and the basic output (file path), but doesn't address the complexity of the many configuration options or provide guidance on their interactions. The absence of output schema means the description should ideally explain return values more thoroughly.

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 all 14 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'custom margins, headers/footers, page ranges, and scaling' - which are already covered in the schema. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose with specific verbs ('Generate', 'Saves', 'returns') and resources ('PDF', 'URL or HTML content', 'file path'). It distinguishes itself from sibling tools like 'take_screenshot' or 'record_video' by focusing on PDF generation from web content rather than visual capture.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare to sibling tools, or specify scenarios where this tool is preferred over others. The agent must infer usage from the purpose 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?

With no annotations, the description carries the full burden, and it does well: it discloses the state-dependent return behavior (status while pending/processing, output URLs when completed) and that the call is free with no request quota — a genuinely useful operational trait. It stops short of covering failure cases (invalid id, failed job) or auth requirements.

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

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

Two dense sentences with the core purpose front-loaded, followed by return semantics and cost. No filler, and the example (async video render via record_video) earns its place by anchoring the abstract 'job' concept.

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, so the description must explain return values — and it does, describing both the pending status and the completed output URLs. Combined with the cost note and the record_video linkage, 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?

Schema description coverage is 100% for the single job_id parameter, so the baseline is 3. The description's note that the id is 'returned when a video is enqueued as an async job' echoes the schema's own wording, adding little new meaning.

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 (fetch) and resource (status/output of a single async job by id), and the 'single ... by id' scoping implicitly distinguishes it from the sibling list_jobs. An agent can tell immediately this is a point lookup, not an enumeration.

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 concrete usage context — polling a job enqueued by record_video — and explains the pending vs. completed phases, which tells the agent this is a polling tool. It does not explicitly name list_jobs as the alternative for enumerating jobs, so the routing guidance is clear but not exhaustive.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the endpoint 'does NOT consume request quota', that save:false returns translated steps without persisting, and what the dry run returns. It stops short of documenting error/failure behavior or auth requirements, so it is strong but not exhaustive.

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

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

Verb+resource is front-loaded, and each subsequent sentence adds a distinct fact (trace shape, selectors option, dry-run flag, quota note, workflow pairing). It is dense but nearly every clause earns its place; slightly long but not 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 complex tool with five parameters, a nested trace object, and no output schema, the description covers the trace input, selectors resolution, persistence control, and side-effect profile well. It leaves the exact return payload shape somewhat implicit, which keeps it from a 5.

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 every parameter. The description largely restates the trace entry shapes and the selectors map origin that the schema already provides, adding only marginal framing. Baseline 3 is appropriate.

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

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

The opening sentence names a specific verb and both resources: 'Convert a page-agent/browser-use action trace into a re-runnable PageBolt sequence.' This is unambiguous and clearly distinct from siblings like observe_page, run_sequence, and export_sequence.

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 prescribes the exact workflow 'observe_page (format:"flatdomtree") → run an agent → import_agent_trace', explains the dry-run condition (save:false), and describes the intended outcome (turn an ad-hoc agent run into a deterministic, replayable sequence). An agent knows when and why to reach for this tool.

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

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

With no annotations, the description carries the full burden and does add genuine behavioral traits: the result is text not an image, it is fast and cheap, and it costs 1 API request — useful cost/latency disclosure an agent cannot get elsewhere. Gaps remain: no mention of auth/tier requirements beyond the session_id schema note, and no warning that injectJs/injectCss execute arbitrary code on the page.

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

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

Three tight sentences, each earning its place: what it does and returns, when to call it relative to siblings, and its cost profile. Nothing is front-loaded poorly or 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 33-parameter, no-output-schema tool, the description covers purpose, output shape, sibling ordering, and cost, which is enough for correct invocation given 100% schema coverage. It could say more about session reuse and the risk profile of the injection parameters, but nothing critical is missing.

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

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

Schema description coverage is 100% across all 33 parameters, so the schema already documents url/html mutual requirement, viewport, cookies, blocking, and session behavior. The description adds no parameter-level syntax or format detail beyond what the schema provides, which is the baseline 3 case.

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 (inspect) and resource (web page) and enumerates the exact output contents: interactive elements, headings, forms, links, images, each with a unique CSS selector. This is clearly distinguishable from take_screenshot (image) and observe_page 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?

Explicitly says to use it BEFORE run_sequence or record_video to discover elements and obtain reliable selectors, which is a real workflow prescription naming alternatives. It stops short of saying when NOT to use it or how it relates to the similarly-scoped observe_page sibling, so it is clear context rather than complete routing.

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

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

With no annotations provided, the description carries full burden. It effectively discloses that this is a read-only listing operation (implied by 'List all available'), though it doesn't mention potential limitations like rate limits, authentication requirements, or whether the list is static/dynamic. The description adds practical context about how the output is used with another tool.

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

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

Two tightly focused sentences with zero waste. The first sentence states the purpose with helpful examples, the second provides crucial usage guidance. Every word earns its place, and the structure is front-loaded with the core functionality.

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 parameterless read-only tool with no output schema, the description provides excellent context about what the tool does and how to use its output. It could slightly improve by mentioning the return format (e.g., array of strings) or any limitations, but given the simplicity of the tool, it's nearly 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 has 0 parameters with 100% schema description coverage. The description appropriately doesn't waste space discussing nonexistent parameters. It instead focuses on the tool's purpose and output usage, which is the correct emphasis for a parameterless 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?

The description clearly states the specific verb ('List') and resource ('all available device presets for viewport emulation'), with concrete examples (iphone_14_pro, macbook_pro_14). It distinguishes from sibling tools by focusing on device preset enumeration rather than screenshot capture, PDF generation, or session management.

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

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

The description explicitly states when to use this tool ('Use the returned device names with the viewportDevice parameter in take_screenshot'), providing a clear alternative context. It directly links to a specific sibling tool (take_screenshot) and explains the relationship between tools.

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

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

With no annotations, the description carries the burden and does disclose the return shape (id, type, status, timestamps) and the quota profile ('Free (no request quota)'). It stops short of stating how far back 'recent' reaches, whether results are paginated, or whether job history is scoped per session.

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, each earning its place: purpose+example, return shape, then routing to the sibling with a cost note. The core purpose is front-loaded.

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

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

For a parameterless list tool with no output schema, the description covers purpose, return fields, sibling routing, and cost. Only the undefined scope of 'recent' and any pagination/limit behavior are left unspecified.

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 per the rubric baseline is 4. There is no argument syntax the description needs to explain.

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 ('recent async jobs') with an explicit example tying it to the producer sibling record_video. An agent can distinguish it from get_job or list_sessions 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?

Names the alternative (get_job) and the exact condition that selects it ('to fetch a specific job's full output'), and adds a cost/quota note that helps an agent decide whether to call it freely.

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

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

With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it lists active sessions only, returns specific data (session IDs, creation times, expiry times), and implies it's a read-only operation (no destructive hints). It could improve by mentioning rate limits or authentication needs, but it covers essential traits adequately.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a concise usage guideline. Every sentence earns its place without redundancy, making it efficiently structured and appropriately sized for the tool's simplicity.

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

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

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is nearly complete: it explains what the tool does, what it returns, and when to use it. It could slightly improve by detailing the output format more explicitly, but it's sufficient for effective use.

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

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

The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description adds no parameter information, which is fine here as there are no parameters to document, and it appropriately focuses on the tool's purpose and output.

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

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

The description clearly states the specific action ('List all active persistent browser sessions') and resource ('for your API key'), distinguishing it from siblings like 'list_devices' or 'create_session'. It provides exact scope and purpose without being vague or 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?

The description explicitly states when to use this tool ('Useful for checking which sessions are still alive before reusing them'), providing clear context. However, it does not specify when not to use it or name alternatives among siblings, such as 'destroy_session' for cleanup, which prevents a perfect score.

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

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

With no annotations, the description carries full burden and does well: it discloses the cost ('1 API request'), the token-budgeting behavior, and that the page is loaded/emulated. It implies a read-only, side-effect-free perception step but does not state auth requirements or rate limits explicitly.

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 purpose and return shape, then routing and cost. Four dense sentences, all earning their place, with only mild redundancy between 'token-budgeted' and 'token-efficient'.

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

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

No output schema exists, and the description compensates by describing the returned structure and the opt-in extras. It names run_sequence as the follow-up tool, though it could say more about how the classification/suggested-actions groups map to next actions.

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 baseline is 3. The description groups the optional output toggles ('readable content (Markdown), the ARIA tree, and a screenshot') but adds no syntax or format meaning beyond what the schema already documents for each parameter.

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

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

States a specific verb (observe/get) and resource (web page) and explicitly enumerates the return payload (id-indexed elements, page-type classification, suggested actions). It also positions itself against the obvious siblings (take_screenshot, inspect_page) by contrasting with 'a raw screenshot or full DOM', so an agent can route correctly without opening other schemas.

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?

Says to use the returned selectors with run_sequence to act, and frames itself as the fastest way to understand an un-instrumented page. It implies when it beats a screenshot/DOM but never gives an explicit use-this-not-that rule against inspect_page or take_screenshot.

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

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

With no annotations, the description carries the full burden. It usefully discloses cost ('Costs 3 API requests') and the side effect ('Saves to disk'), plus output formats, which is real value beyond the schema. However it omits the async-vs-sync default behavior, job polling, quota/limits, and how the result is delivered when no save path is given — significant for a 24-param rendering tool.

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

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

Front-loaded with purpose, then cost/side effects, then actionable best practices — a sensible ordering. The feature enumeration ('cursor highlighting, click effects, ... gradient/glass backgrounds, and more') is slightly padded with 'and more', but the whole description is dense and every section is useful.

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

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

For a complex 24-parameter tool with no output schema, the description covers purpose, cost, disk output, and the most error-prone usage patterns (step count, wait steps, zoom). It stops short of explaining the async job lifecycle and result delivery, but the rich per-parameter schema text compensates substantially.

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 every parameter thoroughly, and the baseline is 3. The description's guidance on wait/zoom/pace reinforces but does not add new semantics beyond what the schema fields already state.

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: 'Record a professional demo video of a multi-step browser automation sequence.' This clearly separates it from siblings like take_screenshot (single image) and run_sequence (no recording), though it never names those siblings explicitly, keeping it just below 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?

It provides strong how-to guidance (keep 5-15 steps, don't pad with wait steps, don't use zoom unless requested), but that governs parameter usage rather than tool selection. It never states when to choose record_video over take_screenshot, run_sequence, or export_sequence, so the when-to-use-vs-alternatives dimension 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?

With no annotations, the description carries the full burden. It does disclose two useful traits not in the schema body: everything runs in a single browser session and each output counts as 1 API request (billing/cost behavior). It omits error behavior, plan-limit enforcement, and session reuse, though the schema's steps/session_id descriptions cover the latter two, lowering the marginal value added 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?

Three tight sentences, front-loaded with the core capability and ending on the cost model, with no filler. It is appropriately sized for a tool this broad, though the diff sentence could be folded in more economically.

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

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

For a complex 12-parameter tool with deeply nested step objects and no output schema, the description covers purpose and cost but says nothing about what the call returns, how outputs are delivered, or failure/plan-limit handling. The rich schema compensates for parameters, but the description is thin relative to the tool's 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 100%, so the baseline is 3. The description adds only a high-level grouping of the action enum (click, fill, select) and one note about the diff step, which does not add syntax or semantics beyond the already thorough per-property schema descriptions.

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

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

States a specific verb (Execute) and resource (multi-step browser automation sequence) and enumerates the action families it covers (navigate, click/fill/select, screenshot/PDF/diff). An agent can distinguish it from single-purpose siblings like take_screenshot or act_on_page, but the description never names those siblings to make the contrast explicit.

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 one concrete usage hint (use the "diff" step to compare the current page state against another URL after automation), which is genuine guidance. However, it never says when to prefer this over act_on_page or take_screenshot, nor when a single-step tool is the better choice, leaving the core routing decision 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?

With no annotations, the description carries the full burden and does disclose the return artifact ("Returns an image (PNG, JPEG, or WebP)"), which is genuinely useful. But it omits auth needs, rate limits, and paid-tier gating, and closes with a vague "and more" rather than concrete behavior.

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

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

Three sentences, front-loaded with the core action and its inputs before the feature list. The trailing "and more" is filler that could be cut, keeping it out of 5 territory.

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 47-parameter tool with no annotations and no output schema, the description covers the return format and the major capability groups, and the schema handles parameter detail exhaustively. Missing only operational context (auth, tier limits) that an agent would want before invoking.

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 all 47 parameters in detail. The description's feature list (device emulation, blocking, geolocation, styling) is thematic rather than parameter-level and adds little beyond what the schema states.

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 ("Capture a screenshot") and the three input source types (URL, HTML, Markdown). It does not differentiate itself from capture-adjacent siblings like generate_pdf, record_video, or create_og_image, so it stops 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 lists capabilities but gives no when-to-use guidance, no indication of when to prefer take_screenshot over record_video or generate_pdf, and no mention of session prerequisites despite session_id being Starter+ only. An agent gets no routing help.

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

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

With no annotations, the description carries the full burden and does disclose concrete behavior: exact return values (diff image, changed pixel count, percentage changed) and the cost of 1 API request, neither of which appear in the schema. It omits auth/session prerequisites and timeout/reversibility behavior, but the cost and output disclosure is genuinely beyond structured data.

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

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

Four sentences, front-loaded with the purpose, then capabilities, returns, and cost. Generally efficient, though the 'and all screenshot-like options' clause is vague filler against a schema that already enumerates those options.

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 must explain returns and it does (diff image, changed pixel count, percentage). For a 43-param tool with full schema coverage, the only meaningful gap is operational context such as session/auth prerequisites and failure behavior.

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

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

Schema description coverage is 100% with 43 parameters, so the schema already documents every option. The description's mention of full-page capture, device emulation, and element selectors only gestures at parameter groups without adding format or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (compare), resource (two web pages or HTML strings), method (pixel-by-pixel), and output (a diff image highlighting differences). This clearly distinguishes it from the sibling take_screenshot, which captures one page, so an agent can route 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 description implies its use case (diffing two pages/HTML strings) but never states when to prefer it over take_screenshot or how it fits a session workflow. No explicit alternatives or exclusions are named, leaving usage to inference.

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