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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds useful behavioral context: it reads data tied to the current API token and never returns API token values. This goes beyond the annotations with a meaningful security-relevant guarantee.

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 compact and front-loaded: it states the resource, the exact data available, the supported question types, and an important safety guarantee in just two sentences. Every clause earns its place with no fluff.

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

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

For a simple two-parameter read-only tool with a full input schema and rich annotations, the description is complete. It tells the agent what data the tool returns, how to select the sub-reading via examples, and that no credentials are exposed, which is sufficient for safe and 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 100%, so the action enum and _prompt are already well documented. The description adds conceptual mapping between user questions and the action, but does not substantially extend the parameter semantics beyond what the schema already provides.

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

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

The description is highly specific: it names the exact resource (Browserless account behind the current API token) and the exact information returned (plan, unit balance, billing period, API key names). It also cites concrete user questions the tool answers, making its purpose unmistakable and easily distinguishable from operation-focused 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?

The description clearly states when to use the tool by mapping it to natural-language questions like 'what plan am I on' and 'which keys exist'. It does not explicitly name sibling tools or describe when not to use it, but the context is clear enough for an agent to route to it correctly.

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 (readOnlyHint=false, destructiveHint=true, openWorldHint=true) indicate a mutating, side-effecting operation, and the description goes far beyond them: open sessions hold a concurrent browser slot until idle timeout, snapshot staleness and diff semantics, proxy config read once at session creation, premature close discarding page state, never-guess-selectors rules, and empty-state-as-precondition-failure. This is rich behavioral context with specific consequences, exactly what an agent needs. No contradiction with annotations.

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

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

Very long, but the complexity justifies it — this documents 30+ command methods, 11 top-level params, proxy, auth, skills, and file transfers. It is well-structured with numbered steps, clear headers, bold warnings, and concrete examples, front-loading the critical Core Loop and mandatory close rule. Minor redundancy exists (proxy and file-transfer details partly repeat schema text and each other), so it is not maximally tight, but every major section 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?

For a tool this complex with no output schema, the description is remarkably complete: session lifecycle, batching rules, snapshot validity/staleness, selector rules, iframes, tabs, links, content extraction, upload/download (including runtime-mode-specific stdio guidance), async waits, error recovery categories, and a non-obvious methods list. It also names the companion skill (browserless_skill) for edge cases like shadow-dom and captchas. 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?

Schema coverage is 100%, but the description adds substantial meaning beyond the JSON Schema: sessionId must be echoed on every subsequent call or the browser is abandoned; proxy must be a top-level argument and never a commands method (silent no-op); profile must be passed on every call or the session looks logged out; rationale has a hard 50-char budget with examples. These are behavioral semantics the schema cannot express, and they materially change how parameters are used.

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?

Opens with a specific verb+resource: "Execute browser commands in persistent agent session." The Core Loop (plan → skill check → goto → snapshot → batch → close) makes the tool's role unmistakable, and the persistent-session concept clearly distinguishes it from siblings like browserless_smartscraper, browserless_crawl, and browserless_skill. An agent can tell exactly what this tool is for.

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?

Exceptionally explicit about when and how to use the tool: step 0 mandates checking browserless_skill for site recipes before any goto, the closing rules specify when to close vs. ask vs. keep open, proxy guidance gives concrete signals (geo-restriction, 403/captcha) for when proxy args are required, and the auth section tells the agent when to load the autonomous-login skill. It even names the sibling tool (browserless_skill) as the alternative for recipes. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the return type ('scraped content (markdown/HTML) for each page along with metadata') and key behaviors like depth control and sitemap handling. No contradiction.

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

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

Three sentences front-load the primary action, add operational details, and conclude with use cases. Every sentence is informative with no redundancy. Ideal conciseness for an AI agent.

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

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

Despite the tool having 17 parameters and a nested object (scrapeOptions), the description only covers a few high-level features (depth, sitemap, filtering, scraping). It omits important context like the async behavior (waitForCompletion), profile authentication, retries, limits, and delays. No output schema exists, so the description should provide more detail on return structure.

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 description does not need to repeat parameter details. It adds high-level context by mentioning sitemap, filtering, and scrape options, which reinforces the schema but does not introduce new meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

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

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

The description clearly states it crawls a website and scrapes discovered pages, starting from a seed URL with configurable depth. It mentions sitemap discovery, path filtering, subdomain handling, and custom scrape options, effectively distinguishing it from siblings like browserless_search or browserless_agent.

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 notes the tool is 'useful for comprehensive site analysis, content extraction, and data gathering,' which implies usage context. However, it does not explicitly state when not to use it or provide alternatives among the sibling tools, leaving room for ambiguity in 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 (readOnlyHint, openWorldHint, destructiveHint) indicate safe read operation. Description adds that it uses /export API, auto-detects content type, and can bundle resources with includeResources. No contradictions.

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

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

Three sentences, front-loaded with main purpose, no redundant information. Every sentence contributes value.

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

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

Given no output schema, the description explains return formats (HTML, PDF, image, ZIP) and mentions profile and resource bundling. Missing error behavior or return structure, but adequate for the 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 coverage is 100%; all parameters have descriptions. The description adds context for includeResources and profile, but adds little beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool exports a webpage via Browserless /export API, returns native format, and auto-detects content type. It distinguishes from siblings like browserless_crawl and browserless_search by focusing on single-page export.

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

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

No explicit guidance on when to use this tool versus siblings. It implies usage for single-page export but does not compare with other Browserless tools or state 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 indicate destructiveHint=true and openWorldHint=true, and the description adds context on binary output types, text caps, and return format. It doesn't contradict annotations and adds value beyond them, but could be more explicit about potential side effects or 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?

The description is well-structured: starts with main purpose, then details return requirements, binary handling, and text limitations. Every sentence adds value with no redundancy. It is appropriately sized for the tool's complexity.

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

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

Despite no output schema, the description covers execution, return, and constraints well. Missing elements include error handling, behavior on code exceptions, and more details on the profile parameter's lifecycle. Overall, very good but not exhaustive.

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

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

Schema description coverage is 100%, so baseline is 3. The description significantly enriches understanding by explaining the return format ({ data, type }), binary handling, and text cap, which are not in the schema. This adds substantial context for agent usage.

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

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

The description clearly states the tool executes custom Puppeteer JavaScript code, with specific verb 'Execute custom Puppeteer JavaScript code'. It distinguishes itself from sibling tools by emphasizing custom code for complex scraping, form filling, or automation, while siblings like browserless_smartscraper or browserless_search target simpler or specific tasks.

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

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

The description provides clear context on when to use: 'complex scraping, form filling, or any browser automation that requires custom code.' It also gives return format instructions and text limitations. However, it does not explicitly state when not to use or compare to sibling alternatives, leaving some guidance 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description agrees by stating 'Read-only.' It adds useful behavioral context beyond the annotations: the plan-dependent retention window, server refusal boundaries, and what data is recorded. This is transparent and does not contradict the annotations.

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

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

The entire tool description is three tight sentences with no fluff. It opens with the primary action and then layers the diagnostic purpose, the plan-window caveat, and the read-only safety hint. This is efficient, well-structured, and every sentence earns its place.

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

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

Even with no output schema, the description tells the agent exactly what the log entries will include and what can be diagnosed. It also covers an important edge case (server may refuse a range and report a limit) and the read-only nature of the tool. Given the richness of the 15-parameter schema, the description supplies the missing non-schema context.

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

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

All 15 parameters are fully documented in the input schema with examples and descriptions, so the schema description coverage is 100%. The tool description itself does not need to add much about the parameters; it simply confirms the purpose and the return fields. This meets the baseline of 3 because the heavy lifting is already done in the schema.

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

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

The description uses a specific verb ('Read') and a specific resource ('Browserless's own record of the account's recent requests'), then lists the record's value: whether it failed, why it stopped, duration, cost. It does not explicitly name sibling tools, but its diagnostic framing ('diagnosing a run that failed on the Browserless side rather than in your own code') differentiates it from the other browserless_* tools. This is slightly below a 5 because sibling differentiation is implicit rather than 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?

The description gives a clear when-to-use: it is the tool for diagnosing failures on the Browserless side, not your own code. It also warns that the available time window is plan-dependent and that the server may refuse overlong ranges. It does not explicitly say when to use alternative tools instead, but the guidance is still strong enough to steer an agent.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint. Description adds beyond that by specifying method (sitemaps and link extraction) and that it returns a list of URLs with optional titles/descriptions, which is useful context.

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

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

Two concise sentences. The first front-loads the purpose, the second adds features and use cases. No unnecessary words.

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

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

With 8 parameters and no output schema, the description explains the tool's core functionality and use cases but lacks details on output format or behavior under different parameter combinations. It is adequate but not fully complete.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining the search parameter orders results by relevance to a query, which is not fully clear from the schema alone. Other parameters are adequately described in the schema.

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

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

Clearly states the tool discovers and maps all URLs on a website using sitemaps and link extraction. Distinguishes from sibling tools like browserless_crawl (crawling) and browserless_search (searching within pages).

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?

Mentions use cases like site audits and content discovery, and explains the search parameter for relevance ordering. However, it does not explicitly state when not to use this tool or provide alternatives among siblings.

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

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

The description adds significant behavioral context beyond annotations (readOnlyHint, destructiveHint): audits take 30-120 seconds, can filter by category, and support authentication profiles. No contradictions with annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and includes key notes about time and optionality without superfluous words. Every sentence 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?

Despite no output schema, the description mentions return types (scores and metrics for multiple categories). Combined with parameter details and annotations, it provides complete context for an AI agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the timeout duration (30-120s), the necessity of existing profiles, and the optionality of budgets and categories, which goes beyond the schema descriptions.

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

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

The description clearly states the tool runs a Lighthouse performance audit on any URL and returns scores for accessibility, best practices, performance, PWA, and SEO. This distinguishes it from sibling tools like browserless_crawl or browserless_search.

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 context for using the tool (Lighthouse audit) and mentions optional filtering and budgets. It does not explicitly state when not to use it or compare to alternatives, but the purpose is clear enough for an AI agent to infer usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's safety profile is consistent. The description adds valuable behavioral context: profiles are saved logged-in states (cookies+storage) and can be replayed, and the return includes name, cookie/origin counts, and last-used time. No contradictions with annotations.

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

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

The description is three sentences, front-loading the main purpose immediately. Every sentence serves a purpose: stating the action, defining what a profile is and its usage, and noting return fields. No wasted words.

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

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

Given there is no output schema, the description adequately explains what is returned (profile name, cookie/origin counts, last-used time). It also explains the concept of profiles and how they relate to other tools. For a list tool with pagination parameters, this is sufficiently complete.

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

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

Schema description coverage is 100% (all three parameters have descriptions). The tool description adds no information about parameters beyond what the schema provides. Per the rubric, when coverage is high, a score of 3 is the baseline. No additional value from 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 clearly states the tool lists authentication profiles for the current token, specifying the verb 'list', the exact resource, and the scope. It distinguishes itself by explaining what a profile is (saved browser state) and that profiles are reusable by name in other tools, differentiating it from sibling tools that perform actions like crawling or searching.

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

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

Explicitly states when to use: 'Call this before a task that needs the browser to start signed in, to discover which profiles already exist and pick one by name.' It provides clear context but does not explicitly mention when not to use or alternative tools; however, no sibling tool serves a similar purpose, so the guidance is sufficient.

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 (readOnlyHint: true, destructiveHint: false) already indicate safe read operations. The description adds value by disclosing that search results can be optionally scraped (with formats like markdown, HTML, links, screenshots), implying potential performance impact from multiple requests. There is no contradiction with annotations.

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

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

The description is three sentences, front-loaded with the core action ('Search the web using Browserless and optionally scrape each result'), followed by a brief elaboration. Every sentence contributes meaning without redundancy or unnecessary detail.

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 complexity (11 parameters, 100% schema coverage, no output schema), the description covers the tool's primary capabilities—searching and scraping—and hints at output formats. However, it does not specify the structure of the returned search results (e.g., whether they include titles, snippets, URLs) or the exact output when scraping is used, which would enhance completeness.

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

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

Schema coverage is 100%, with all parameters described in detail (e.g., tbs enum, limit bounds, scrapeOptions nested structure). The description does not add meaning beyond the schema—e.g., it doesn't explain when to use 'scrapeOptions' versus just searching. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Search the web using Browserless and optionally scrape each result.' It specifies the search engine (SearXNG), supported sources (web, news, images), and optional scraping for various formats. This differentiates it from sibling tools like browserless_crawl (multi-page crawling) or browserless_smartscraper (AI-powered scraping).

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 basic usage context—'Useful for research, gathering information, and finding relevant web pages'—but lacks explicit guidance on when not to use this tool or mention of alternatives. It does not address prerequisites or scenarios where other tools (e.g., browserless_crawl for deep crawling) would be more appropriate.

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

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

The description notes it is 'Read-only — it never stops a session', matching the readOnlyHint while also spelling out the safety guarantee. It richly details the replay action's output contract, including that the rrweb page is self-contained, needs no network, and must be shown inline or as an artifact rather than summarized.

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 definition is front-loaded with a clear purpose, then gives exactly the important usage context, and ends with the critical replay display instruction. Every sentence earns its place, and there is no fluff or redundant schema copying.

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 7 parameters, no output schema, and no nested object structure, the description covers the main output and behavior for the key action 'replay', surfaces user-facing intent, and emphasizes the must-do UI behavior. Creators additionally receive 100% parameter schema coverage, keeping a complete enough picture 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?

The input schema already documents all 7 parameters with descriptions, including the action enum and paging fields. These descriptions additionally calls out replay behavior, but it does not add semantic meaning to the individual parameters beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with the specific verb 'Inspect' and explicitly scopes the resource to 'sessions on the Browserless account behind the current API token'. It enumerates four concrete data kinds, which distinguishes it clearly from crawling, exporting, and performance sibling tools even without naming 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?

The description gives explicit use contexts with 'Use it to answer "what is running", "did my session survive", or "what got recorded"', which tells an agent when to select this tool. It does not name alternative sibling tools or describe when not to use this tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's role is lighter. It adds context about returns ('no recipe' note, pointers) and that it loads skill bodies. No contradictions with annotations.

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

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

Well-structured with two main uses and bullet points for in-house skills. Front-loaded with key information. Slightly lengthy due to detailed skill list, but each sentence adds value.

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

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

No output schema, so description should explain return values. It mentions 'returned as pointers' and 'load a skill body', but lacks explicit details on response format. Adequate but not fully complete.

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

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

Schema coverage is 100%, baseline 3. The description adds meaning: explains the difference between id and site parameters, provides examples, and clarifies the _prompt parameter's intended use. This goes beyond the schema descriptions.

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

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

The description clearly states the tool's purpose: 'Load a Browserless agent skill on demand, or discover site-specific recipes.' It distinguishes between two use cases (site and id) and differentiates from sibling tools by focusing on skill loading rather than other browserless actions.

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?

Explicit guidance is provided: 'Use the in-house skills below when you suspect the page exhibits a non-trivial mechanic but no SKILL block was auto-injected.' Also advises to use site lookup 'as soon as you know the host' and lists specific scenarios for each in-house skill, making when-to-use 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 indicate read-only (readOnlyHint: true) and non-destructive (destructiveHint: false). The description adds value by mentioning automatic handling of JavaScript and anti-bot measures. Although it doesn't detail auth profile or timeout behavior, the overall transparency is good.

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, no wasted words. The first sentence clearly states the core functionality and return types; the second provides important alternatives. It is front-loaded and 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?

Given the well-documented schema and annotations, the description is mostly complete. It covers purpose, alternatives, and key behaviors. However, lacking details about return structure (since no output schema) and edge cases slightly reduces completeness.

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

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

The input schema has 100% coverage with descriptions for all five parameters. The description adds marginal value by mentioning markdown/HTML formats, but the schema already defines formats with defaults. Baseline 3 is appropriate.

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

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

The description clearly states it scrapes a SINGLE webpage and returns content as markdown or HTML. It explicitly distinguishes from sibling tools 'browserless_crawl' (multiple pages) and 'browserless_map' (list URLs), making the purpose unambiguous.

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

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

The description provides explicit when-to-use (single page scraping) and when-not-to-use (use crawl for multiple pages, map for listing URLs). It also notes it handles JavaScript-heavy pages and anti-bot measures, guiding proper usage.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds useful context beyond that by explaining the account-scoped nature, the breadth of metrics, and the billing-oriented purpose, which helps the agent understand what the call exposes and how it is meant to be used.

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

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

The description is two focused sentences: one defining scope and returned data, and one providing usage intent and sibling routing. Every sentence earns its place, with no filler, redundancy, or unnecessarily repeated annotation 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?

For a read-only tool with zero required parameters and no output schema, this description is sufficiently complete. It names the resource, the data categories returned, the intended usage questions, and the sibling to use for related but distinct needs, so an agent can confidently select and invoke it.

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

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

The input schema has 100% description coverage and clearly documents all three parameters, their defaults, and restrictions. The description does not need to repeat parameter details, so the baseline score of 3 is appropriate; it adds no unique parameter nuance beyond what the schema already provides.

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

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

The description clearly identifies the tool as reading request and unit consumption for the Browserless account behind the current API token, and lists the specific metrics returned. It also explicitly differentiates itself from browserless_logs by noting that per-request failure details are handled there, making purpose and boundary unambiguous.

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

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

The description explicitly says when to use the tool, with example user questions like "how much have I used" and "why is my bill high". It also gives a direct exclusion by telling the agent to use browserless_logs instead when per-request failure detail is needed, which is strong alternative routing.

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