fetch_url

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

No annotations are provided, so the description carries the full burden. It discloses the session reuse (user's cookies), that it avoids touching the active tab, that it may fail in specific environments, and names the fallback path. It doesn't describe return format (but no output schema exists), yet the key behavioral traits are covered.

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

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

The description is a dense, single-block paragraph that front-loads the core purpose and mechanism first, then usage guidance, then failure modes. It's information-rich with no filler, though slightly long; the sentence combining purpose and fallback is efficient. Minor structure improvement possible by splitting into sub-points.

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 moderately complex tool with 3 params, no output schema, and no annotations, the description covers purpose, usage context, parameter options, failure modes, and fallback - a thorough treatment. It doesn't describe the return structure, which would be valuable, but the core usage decision is well covered.

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% and each parameter has a schema description (defaults, enum values, batch-size advice). The description adds meaningful context about content_type values ('text', 'html', 'domSnapshot') and reiterates the batching constraint, going slightly beyond schema to explain practical 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 verb+resource ('Fetch rendered content for one or more URLs') and specifies the mechanism (via browser.tabs.content, using the user's Chrome session without touching the active tab). It distinguishes itself from siblings like goto+scroll+snapshot and eval_js by positioning it as a faster bulk/JSON fetching approach.

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 it ('ideal for JSON endpoints or reading pages in bulk') and when NOT to ('fall back to goto + eval_js' if tabs_content is unsupported or content-blocker blocks). It also contrasts with goto+scroll+DOM scraping as the slower alternative, giving clear decision guidance.

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