network_requests

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it lists requests that have been observed since attach, giving a time-bound scope, but it doesn't clarify whether this is a read-only operation (which seems likely), or what happens if no requests are observed. It also doesn't mention any side effects or limitations, such as whether it requires an active DevTools session or if it returns partial data.

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 single concise sentence, front-loading the main action (list HTTP requests) and including key attributes. Every word contributes to meaning, with no filler or repetition. It's appropriately brief for its simple purpose.

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 simplicity (one parameter, no output schema), the description is adequate for basic usage. However, since there's no output schema and no annotations, it doesn't specify the return format in detail, such as whether it returns an array of objects or a summary structure. The context of needing DevTools attached is implicit but could be more explicit, and the 'summarized' aspect is vague. It covers the essentials but leaves small gaps.

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 only one parameter, tabId, and schema description coverage at 0%, the schema provides only a type and bounds. The description doesn't elaborate on the tabId parameter, but since it is likely obvious that it identifies the tab, the lack of detail is acceptable. The description adds no extra meaning beyond the schema, so it's a baseline of 3.

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 lists HTTP requests, and specifies key attributes (request id, URL, method, status, failure state). It distinguishes from siblings like network_failures (which lists failures) and network_response_body (which gets response bodies) by focusing on a summary of all requests. However, it could be more explicit about the 'summarized' nature, but the verb+resource is clear.

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 implies usage when you need an overview of network requests, and the sibling list shows alternatives like network_read for raw events and network_failures for errors. However, it doesn't explicitly state when to use this tool over others, or when not to use it. The context signal that DevTools must be attached is implicit but not stated, which is a minor gap.

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