fetch

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

With no annotations, the description carries the burden and does well: it discloses the side effect that Chrome is launched automatically if needed, and explains the conditional result (site-specific extractor returns structured data, otherwise generic readable text). It omits failure modes, timeouts, and whether logged-in sessions are used, but the auto-launch disclosure is valuable 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?

Four short sentences, each earning its place, with the primary behavior front-loaded before usage hints and the Discogs caveat. Only minor friction from the parenthetical interrupting the opening sentence.

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?

An output schema exists, so return-shape documentation is not required, and the description nonetheless explains the two result modes. It covers mechanism, usage, and a site-specific quirk; the main remaining gap is what max_chars controls and how failures surface.

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 0%, so the description must compensate. It adds real meaning to the URL (extractor-matching behavior and the ochi_max=<price> URL convention) but says nothing about max_chars beyond its self-explanatory name, leaving one of two parameters undocumented.

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

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

States a specific verb and resource ('Read a web page') plus the mechanism ('through the user's own Chrome'), and explains the two extraction paths. This clearly separates it from siblings like browser_start (starts the browser) and snapshot/tabs (state inspection), so an agent can pick it without reading the schema.

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

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

Explicitly routes usage: 'Use for sites that block normal fetching (Discogs marketplace, Reddit, news)', and notes the Discogs-specific ochi_max=<price> refinement. It gives a clear positive condition but no explicit when-not-to-use or named alternative for ordinary pages, 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.