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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: stateless operation, fresh browser per URL, concurrency limits (max 5), and performance characteristics ('faster than sequential crawling'). It doesn't mention error handling or output format, keeping it from a perfect score.

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 structured and concise - front-loaded with the core purpose, followed by usage guidelines and behavioral constraints. Every sentence adds value with no wasted words, and it's 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?

For a stateless crawling tool with no annotations and no output schema, the description provides excellent context about when to use it, behavioral constraints, and alternatives. It doesn't describe the return format or error handling, which would be helpful given the lack of output schema.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline but doesn't provide extra value.

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 ('crawl multiple URLs concurrently') and distinguishes it from siblings by mentioning it's for efficiency and bulk operations. It explicitly differentiates from sequential crawling and session-based approaches.

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 usage guidance with 'Use when:' listing three specific scenarios (processing URL lists, comparing multiple pages, bulk data extraction). It also gives clear alternatives (sequential crawling vs. this tool, and create_session + crawl for persistent 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 provided, the description carries the full burden of behavioral disclosure. It effectively communicates several key behaviors: stateless operation ('Creates new browser each time'), return format ('Returns base64-encoded PNG data'), performance consideration ('Large screenshots (>800KB) won't be returned inline when saved'), and a critical limitation about JavaScript changes. The only gap is lack of information about error conditions or timeout 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 appropriately sized and front-loaded with the core functionality. The first sentence establishes the main purpose, followed by important behavioral details. The warning about chained calls is crucial but could be slightly more concise. Overall, most sentences earn their place by conveying essential information that isn't in the structured fields.

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 of a screenshot tool with browser isolation and JavaScript limitations, and with no annotations or output schema, the description does a good job covering key aspects: stateless operation, return format, sibling tool relationships, and important constraints. The main gap is the lack of information about what happens on failure (timeouts, invalid URLs, etc.), which prevents a perfect score.

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 three parameters thoroughly. The description adds minimal parameter-specific information beyond what's in the schema - it mentions the save_to_directory behavior with large screenshots, but doesn't provide additional context about url validation or screenshot_wait_for usage. This meets the baseline expectation when schema coverage is complete.

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 ('capture webpage screenshot'), the resource ('webpage'), and distinguishes it from siblings by explicitly mentioning what it doesn't do (chained calls with execute_js) and pointing to the alternative (create_session + crawl). The verb+resource combination is precise and 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 guidance on when NOT to use this tool ('Chained calls... will NOT work') and specifies the alternative approach ('use create_session + crawl... in ONE call'). It also clarifies the stateless nature upfront, which helps set expectations about browser isolation.

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 and excels at this. It explains critical behavioral traits: session persistence mechanics, server serialization errors with js_code, the need for screenshot:true with js_code, multi-step workflow requirements, and warnings about js_only usage. It provides rich context about what gets maintained (cookies, localStorage, page state) and operational constraints.

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

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

While the description is well-structured with clear sections, it's quite lengthy with multiple bullet points and workflow examples. Some information could be more condensed, though most content earns its place by providing essential guidance. The front-loaded session persistence claim is effective, but overall length reduces conciseness.

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 high complexity (48 parameters, no annotations, no output schema), the description does an excellent job covering critical usage patterns, behavioral constraints, and workflow guidance. It compensates well for the lack of structured metadata, though some edge cases or error handling details could be more explicit for such a complex 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?

Despite 100% schema description coverage, the description adds significant value by explaining the semantic relationship between session_id and persistence, providing critical warnings about js_code usage patterns, and offering practical guidance on parameter combinations. It doesn't just repeat schema information but provides context about how parameters interact in real workflows.

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 as the only tool with browser persistence, distinguishing it from all sibling tools. It specifies that it crawls URLs with optional JavaScript execution and session management, making the verb+resource+scope explicit and differentiating it from stateless alternatives like get_html.

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 extensive explicit guidance on when to use sessions vs stateless approaches, when to use crawl vs other tools, and includes detailed workflow patterns. It explicitly names alternatives (stateless tools, get_html) and provides clear decision criteria for different scenarios like form filling, screenshot after JS, and data extraction.

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 describes key traits: stateless operation ('[STATELESS]'), need for JS execution for dynamic sites, fresh browser per page, and limitations (defaults for max_depth and max_pages). It doesn't cover rate limits or error handling, but provides substantial context beyond basic functionality.

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 efficiently structured with zero waste: it opens with the stateless hint, states the core purpose, provides usage guidelines, mentions key parameters with defaults, and notes behavioral considerations. Every sentence earns its place, 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?

Given the tool's complexity (recursive crawling with multiple parameters) and no annotations or output schema, the description does well to cover purpose, usage, key behaviors, and parameter defaults. It could improve by briefly mentioning the return format or error scenarios, but it's largely complete for guiding agent selection and 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 schema already documents all 5 parameters thoroughly. The description adds minimal value by mentioning defaults for max_depth and max_pages, but doesn't provide additional semantics beyond what's in the schema. This meets the baseline of 3 when schema coverage is high.

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 ('deep crawl', 'following internal links') and resources ('a website'), distinguishing it from siblings like 'crawl' (likely simpler) and 'smart_crawl' (likely more intelligent). It explicitly mentions use cases like mapping entire sites and building comprehensive indexes.

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

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

The description provides explicit guidance on when to use ('Use when: mapping entire sites, finding all pages, building comprehensive indexes') and when not to use ('For persistent operations use create_session + crawl'), with clear alternatives named ('create_session + crawl'). It also distinguishes from other tools by mentioning JS execution needs and fresh browser contexts.

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 describes key behavioral traits: the stateless nature ('[STATELESS]', 'Creates new browser each time', 'page state is lost'), return value handling ('Scripts with "return" statements return actual values', 'null returns as {"success": true}'), and execution characteristics ('Each string runs separately. Returns appear in results array'). The only minor gap is lack of explicit error handling or timeout information.

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 efficiently structured with front-loaded key information ('[STATELESS] Execute JavaScript and get return values + page content'), followed by usage guidelines, behavioral notes, and sibling differentiation. Every sentence adds value without redundancy, and the information density is high while remaining readable.

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 complexity (JavaScript execution in browser context), no annotations, and no output schema, the description does an excellent job covering execution behavior, return value handling, and sibling differentiation. The only gap is the lack of explicit information about what the output structure looks like (though this is somewhat implied by the return value explanations). For a tool with this complexity level, 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?

With 100% schema description coverage, the baseline is 3. The description adds meaningful context beyond the schema by explaining how return values work ('Scripts with "return" statements return actual values'), providing concrete examples of script syntax, and clarifying that 'null returns as {"success": true}'. This significantly enhances understanding of how to use the scripts parameter effectively.

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 ('Execute JavaScript and get return values + page content') and distinguishes it from siblings by mentioning it 'Creates new browser each time' and contrasting with 'For persistent JS execution, use crawl with session_id.' This provides a clear differentiation from tools like crawl, manage_session, and smart_crawl.

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

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

The description provides explicit guidance on when to use this tool ('Use for: extracting data, triggering dynamic content, checking page state') and when not to use it ('For persistent JS execution, use crawl with session_id'). It names a specific alternative (crawl with session_id) and explains the trade-off between stateless execution and persistence.

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 describes key traits: stateless operation ('[STATELESS]'), creation of a new browser each time, and categorization behavior. However, it lacks details on error handling, performance limits, or authentication needs, leaving some gaps for a tool that interacts with external URLs.

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

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

The description is highly concise and well-structured, with each sentence adding value: it states the tool's purpose, usage contexts, categorization details, behavioral note, and alternative. There is no redundant or unnecessary information, making it efficient and front-loaded for quick comprehension.

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 moderate complexity (2 parameters, no output schema, no annotations), the description is mostly complete, covering purpose, usage, behavior, and alternatives. However, it lacks output details (e.g., format of categorized links) and doesn't address potential issues like rate limits or URL validity, which could be helpful for an 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 both parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining 'categorize' further or detailing URL validation. Thus, it meets the baseline but doesn't enhance understanding.

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 verb ('extract and categorize') and resource ('all page links'), distinguishing it from siblings like 'crawl' or 'get_html' by focusing on link extraction rather than broader crawling or content retrieval. It specifies the output format (grouped by internal/external/social/documents), making the purpose explicit and differentiated.

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

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

The description provides explicit usage scenarios ('building sitemaps, analyzing site structure, finding broken links, or discovering resources') and clear alternatives ('For persistent operations use create_session + crawl'), helping the agent decide when to use this tool versus others like 'crawl' or 'manage_session'. It also notes stateless behavior, guiding against use for ongoing tasks.

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 and discloses key behavioral traits: stateless operation (via [STATELESS] tag), fresh crawling each time, natural language return format, and limitations with dynamic/session content. It doesn't mention rate limits, authentication needs, or error handling, but covers core operational behavior well.

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?

Perfectly front-loaded with the core purpose first, followed by key behavioral notes and usage guidance. Every sentence earns its place with zero wasted words, making it highly scannable 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?

For a 2-parameter tool with no annotations and no output schema, the description provides good coverage of purpose, behavior, and usage context. It could be more complete by describing the return format in more detail (beyond 'natural language answers') or error scenarios, but it adequately supports agent decision-making given 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 schema already documents both parameters thoroughly. The description adds marginal value by implying the relationship between URL and query (asking questions 'about webpage content') but doesn't provide additional syntax or format details beyond what the schema 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 states the tool's purpose with specific verbs ('Ask questions about webpage content using AI') and resources ('webpage content'), distinguishing it from siblings by focusing on AI-powered Q&A rather than raw crawling, screenshot capture, or link extraction.

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 provides when-to-use guidance ('Crawls fresh each time') and when-not-to-use alternatives ('For dynamic content or sessions, use crawl with session_id first'), naming a specific sibling tool (crawl) for comparison.

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 describes key traits: it's stateless ('[STATELESS]', 'Creates new browser each time'), has limitations ('Cannot capture form fills or JS changes'), and specifies the return format ('Returns base64-encoded PDF data'). This covers essential operational context beyond basic functionality.

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 highly concise and well-structured: it uses a tag ('[STATELESS]') for immediate context, states the core function in the first sentence, adds behavioral details in subsequent sentences, and ends with alternative guidance. Every sentence adds value without redundancy, making it efficient and 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 tool with one parameter, no annotations, and no output schema, the description is complete: it explains what the tool does, its stateless nature, limitations, return format, and when to use alternatives. This provides sufficient context for an agent to understand and invoke the tool correctly, compensating for the lack of structured metadata.

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

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

The schema description coverage is 100%, with the single parameter 'url' clearly documented in the schema. The description does not add any additional meaning or context about the parameter beyond what the schema provides (e.g., URL format requirements). Given the high schema coverage, the 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 specific action ('Convert webpage to PDF') and resource ('webpage'), distinguishing it from sibling tools like capture_screenshot (which captures images) or get_html (which retrieves HTML). It explicitly mentions the output format ('base64-encoded PDF data'), making the purpose unambiguous and distinct.

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

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

The description provides explicit guidance on when to use this tool vs. alternatives: it states 'Cannot capture form fills or JS changes' and directs users to 'For persistent PDFs use create_session + crawl(session_id, pdf:true)'. This clearly defines limitations and names an alternative approach, helping the agent choose appropriately.

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 describes key behaviors: it's stateless ('[STATELESS]'), returns cleaned HTML with specific details ('element names, IDs, and classes'), and has a side effect ('Creates new browser each time'). However, it doesn't mention potential limitations like rate limits, error handling, or authentication needs, which would be useful for a tool that creates browser instances.

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 sized and front-loaded, starting with the core purpose. Most sentences earn their place by providing usage guidelines and behavioral context. However, the repetition of 'for automation' in 'automation planning' and 'for subsequent crawl operations' slightly reduces efficiency, preventing a perfect score.

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

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

Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is largely complete. It covers purpose, usage, behavior, and output characteristics. The main gap is the lack of output schema, so the description doesn't detail the exact structure of the returned HTML (e.g., format, size limits), but it does describe the content ('cleaned HTML showing element names, IDs, and classes').

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 'url' parameter. The description doesn't add any additional semantic information about parameters beyond what's in the schema (e.g., URL format requirements, handling of invalid URLs). This meets the baseline of 3 when the schema provides complete 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: 'Get sanitized/processed HTML for inspection and automation planning.' It specifies the verb ('Get'), resource ('sanitized/processed HTML'), and distinguishes from siblings by focusing on HTML extraction rather than crawling, screenshot capture, or other operations listed in sibling tools.

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 when: finding form fields/selectors, analyzing page structure before automation, building schemas.' It also provides context on alternatives by noting it's 'commonly used before crawl to find selectors for automation,' distinguishing it from actual crawl operations like 'crawl' or 'smart_crawl'.

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 discloses key behavioral traits: statelessness ('[STATELESS]'), browser creation ('Creates new browser each time'), and persistence alternatives. It does not cover rate limits or auth needs, but adds significant context beyond basic function.

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 sized and front-loaded, with each sentence adding value: stating purpose, listing filters, explaining usage, and noting behavioral aspects. 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 no annotations and no output schema, the description is fairly complete for a tool with 4 parameters and stateless behavior. It covers purpose, usage, and key traits, but lacks details on output format or error handling, 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 description coverage is 100%, so the schema already documents all parameters. The description adds some meaning by explaining filter purposes (e.g., 'raw (full content), fit (optimized, default)'), but does not provide additional syntax or format details beyond the schema.

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

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

The description clearly states the tool's purpose with specific verbs ('extract content as markdown') and distinguishes it from siblings by mentioning filtering options and browser creation, unlike tools like 'get_html' or 'extract_links'.

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 clear context on when to use specific filters (e.g., 'Use bm25/llm with query for specific content') and mentions alternatives for persistence ('For persistence use create_session + crawl'), but does not explicitly state when not to use this tool versus all 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?

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: sessions are persistent, maintain ALL state (cookies, localStorage, page) across multiple calls, and support three distinct actions. It doesn't mention rate limits, authentication needs, or error handling, but covers the core functionality thoroughly.

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 with clear sections (SESSION MANAGEMENT header, bulleted actions, usage examples, and essential use cases). It's appropriately sized but could be slightly more concise by integrating the usage examples more tightly with the action descriptions rather than as a separate section.

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 4 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains what the tool does, when to use it, and key behavioral characteristics. The main gap is lack of information about return values or output format, which would be helpful given no output schema exists.

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 minimal parameter semantics beyond the schema - it mentions 'initial_url' in the CREATE example and that session_id is 'auto-generated if omitted' for create actions, but doesn't significantly enhance understanding of the four parameters 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 states the tool's purpose as 'Unified tool for managing browser sessions' and specifies the three supported actions (CREATE, CLEAR, LIST). It distinguishes this from sibling tools by focusing on session state management rather than crawling or content extraction operations.

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

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

The description provides explicit guidance on when to use this tool ('Essential for: forms, login flows, multi-step processes, maintaining state across operations'). It differentiates from sibling tools by explaining this is for maintaining persistent browser state across multiple operations, unlike one-off crawl 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 provided, the description carries the full burden and does well by disclosing key behavioral traits: the stateless nature ('[STATELESS]'), that it 'Creates new browser each time' (implying isolated execution), and supports 'regex filtering' for customization. It doesn't mention error handling or rate limits, keeping it from a perfect score.

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 key information, uses bullet-like phrasing efficiently, and every sentence earns its place by adding distinct value (purpose, usage guidelines, behavioral notes). No wasted words.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, usage, key behavior, and hints at parameters. It lacks details on output format or error cases, but for a stateless extraction tool, this is sufficient though 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 the schema already documents both parameters fully. The description adds minimal value beyond the schema by mentioning 'Supports regex filtering' which loosely relates to 'filter_pattern', but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Extract URLs from XML sitemaps') and resource ('XML sitemaps'), distinguishing it from siblings like 'extract_links' or 'crawl' by focusing specifically on sitemap parsing rather than general link extraction or crawling.

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 provides when-to-use guidance ('Use when: discovering all site pages, planning crawl strategies, or checking sitemap validity'), when-not-to-use alternatives ('Try sitemap.xml or robots.txt first'), and practical context for application.

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 describes key traits: 'Adapts strategy based on content' (dynamic behavior), 'Creates new browser each time' (stateless operation, implying no session persistence), and '[STATELESS]' tag (explicit statelessness). However, it lacks details on rate limits, error handling, or output format, which are important for a crawl 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?

The description is highly concise and well-structured: it starts with a [STATELESS] tag for quick insight, states the purpose, provides usage guidelines, and notes behavioral traits in three clear sentences. Every sentence adds value without redundancy, making it 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 tool's complexity (crawling with auto-detection) and no annotations or output schema, the description does a good job covering purpose, usage, and key behaviors. However, it lacks details on output (what is returned, e.g., extracted data or links) and error scenarios, which are critical for a tool with no output schema. This gap prevents a perfect score.

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 well. The description does not add any parameter-specific semantics beyond what's in the schema (e.g., it doesn't explain url formats or max_depth implications further). Baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

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: 'Auto-detect and handle different content types (HTML, sitemap, RSS, text)' with specific verbs ('detect', 'handle') and resources ('content types'). It distinguishes from siblings by mentioning 'automatic format handling' versus more specific tools like parse_sitemap or get_html.

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 usage guidelines: 'Use when: URL type is unknown, crawling feeds/sitemaps, or want automatic format handling.' It also specifies alternatives: 'For persistent operations use create_session + crawl,' though create_session is not listed as a sibling, implying an external or implied tool. This gives clear when-to-use and when-not-to-use scenarios.

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