requests_list_captured

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

With no annotations, the description carries the burden well: it discloses eventual-consistency semantics ('a request appears here once it has completed, so a page navigation started a moment ago will not be in the list yet'), confirms the read is non-mutating, and warns that object IDs are profile-local and must never be reused across profiles. It stops short of mentioning pagination, result caps, or ordering, which are real behavioral traits for a list endpoint.

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 core purpose is front-loaded in the first sentence, followed by the timing caveat and then the workflow chain. Every sentence carries information, though the paragraph could be broken into tighter lines for scanning.

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 two-parameter list tool with an output schema, the description supplies everything the schema cannot: prerequisite ordering, ID provenance, profile scoping, and the async-visibility caveat. Return shape is correctly left to the output schema.

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 only 50% and profile_id has no schema description at all, but the description fully compensates: it states profile_id is required, where to obtain it (profiles_list), and that all IDs are scoped to that profile. monitor_id's provenance is likewise tied to requests_start_monitoring.

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 — 'List all captured request summaries from a monitoring session' — and immediately scopes it against siblings (requests_start_monitoring for capture, requests_get_content for bodies). An agent can distinguish it from every other requests_* tool without opening a 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?

Gives an explicit ordered workflow: obtain profile_id from profiles_list, start with requests_start_monitoring, reuse its monitor_id here, then feed a returned request_id to requests_get_content. It also names what the tool does not do ('without starting or stopping capture'), covering the when-not case.

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