browser_network_requests

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

The annotations already declare readOnlyHint=true (safe read) and destructiveHint=false, so the safety profile is clear. The description adds value by specifying the behavior: 'since loading the page' (explaining the scope/timebound) and 'numbered list' (indicating the output structure requires the partner tool for details). This goes beyond 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 description is two short sentences. The first sentence states what the tool does. The second provides immediate usage guidance for the sibling tool. Every word serves a purpose. No fluff, no repetition of what's in the schema.

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 could have explained the return format (e.g., structure of the numbered list). But it's clear enough for an agent to understand: it returns a list of requests, each with a number, and the partner tool gets detail by number. The input schema is well-documented. This is adequate for the tool's functionality and 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 all parameters. The description adds a bit of context by implying the 'filter' and 'static' parameters affect the list, and the 'filename' parameter changes the output format (save vs. return text). However, it doesn't elaborate on the regex usage or the exact effect of including static resources, so it mostly relies on the schema which is already 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 uses the specific verb 'Returns' and the resource 'numbered list of network requests' with a clear scope ('since loading the page'). It also differentiates from its sibling 'browser_network_request' by noting the partner tool is for getting full details of a specific request. This makes the purpose unmistakable.

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 to use this tool first to get the list, then 'browser_network_request with the number to get full details'. This establishes a clear workflow. However, it doesn't mention when NOT to use it (e.g., if you already know the request number, or if you need details from a specific filter upfront), so it falls just 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.