browser_get_resource_content

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

With no annotations provided, the description carries full burden. It discloses critical behaviors: '[Disabled]' status upfront, 'Returns content from the browser cache — does not re-fetch the resource' (caching behavior), and return format differences ('Text content is returned as a string; binary resources... are returned as base64'). Deduct one point for not mentioning error handling when resources aren't cached.

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 structured with zero waste. Five sentences each serving distinct purposes: [1] Status/purpose, [2] Cache behavior, [3] Prerequisite workflow, [4] Use case, [5] Return format. Front-loaded critical '[Disabled]' warning. No redundant 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?

Comprehensive for a 3-parameter tool without output schema. Compensates for missing output schema by detailing return formats (string vs. base64). Includes disabled status, caching constraints, prerequisite relationships, and content type handling. Given the complexity, 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 has 100% description coverage (baseline 3). The description adds valuable semantic context for the 'url' parameter by specifying it comes from 'browser_list_resources output.' It also implicitly guides the 'maxLength' usage by explaining the tool is useful for reading minified JavaScript, suggesting potential size considerations.

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?

Description clearly states the tool 'Read[s] the content of a specific resource (JS, CSS, HTML, etc.) loaded by a page' with specific verb and resource type. It distinguishes from siblings like browser_get_page_html (full page) and browser_list_resources (listing vs. fetching) by specifying it retrieves specific loaded resources and requires a URL from browser_list_resources.

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

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

Explicitly states the prerequisite workflow: 'Use browser_list_resources first to find the resource URL you want to read.' It also provides clear usage context: 'Useful for reading minified JavaScript to understand API patterns, endpoints, data models, and authentication,' which helps the agent select this over alternatives like browser_get_page_html.

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