web_capture_live_session

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

With no annotations, the description carries the full behavioral burden. It discloses useful facts (HAR 1.2 output, WebSocket replay server generation, live recording), but stays silent on side effects such as writing artifacts to disk, launching a browser, capture latency/cost, and whether the session is time-bounded by default. Slightly better than adequate but leaves meaningful gaps.

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?

A single front-loaded sentence leads with the core action before listing capabilities, so the agent gets the gist immediately. The dense enumeration is slightly list-like but every clause corresponds to a real feature, so little is wasted.

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers what the tool produces but omits operational context (disk writes, browser requirements, duration defaults, failure modes). It is minimally sufficient for an agent that reads the schema, but not self-sufficient.

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 all eight parameters are already documented, giving a baseline of 3. The description loosely maps its capability list onto flags (WebSocket recording, cookie/localStorage state), but it doesn't clarify the injection-vs-snapshot distinction or default behaviors beyond what the schema already states.

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 opens with a specific verb+resource ('Captures live dynamic web sessions') and enumerates four concrete capabilities (HAR 1.2 capture, WebSocket frame recording, cookie/localStorage snapshotting, offline replay server generation). It is clearly distinguishable in intent, though it never names or contrasts against nearby siblings like web_clone_offline_mirror or web_inspect_pwa_cache.

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?

There is no explicit guidance on when to reach for this tool versus alternatives, nor any stated prerequisites (e.g. headless browser availability, permissions). The usage is implied by the capability list but an agent must infer the selection criteria itself.

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