zerodom_replay

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

With no annotations, the description carries the full burden of disclosing side effects. It says it sends a request and returns status/size/body preview, but it never warns that replaying arbitrary methods (POST, PUT, DELETE) can mutate server state, nor does it mention authentication requirements, rate limits, or whether the request is sent from the agent's context. The 'Burp Repeater' analogy implies tampering, but the safety profile is not disclosed.

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?

Two sentences plus a usage line, front-loaded with the analogy and core mechanics. Every sentence earns its place – the first defines, the second explains parameters and return, the third gives use cases and a pairing. Zero fluff, ideal density for an agent to scan quickly.

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?

The output schema exists, so return details are covered; the description correctly mentions status/size/preview anyway. However, it omits any error handling, authentication prerequisites, or the range of valid as_identity values. For a tool that can fire arbitrary HTTP requests, an agent needs more guardrails (e.g., 'requires an active session' or 'only one header allowed'). The core is complete, but the edges are under-specified.

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 0%, so the description must compensate. It does mention all five parameters in one sentence and gives the header format ('K: V'), but it leaves as_identity ambiguous (what values? identity names?) and does not explain body format or constraints beyond 'optional'. The default method GET is implied but not stated explicitly. This is thin compensation for a 5-param tool with no schema descriptions.

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 crisp verb+resource statement ('Replay an HTTP request under a chosen identity') and the 'Burp Repeater for the agent' analogy instantly frames the tool. It clearly separates itself from browser-automation siblings like zerodom_click_node or zerodom_network_log by focusing on raw HTTP replay, and names a natural companion (zerodom_compare_identities).

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 lists concrete use cases: 'probe an endpoint, tamper with a request, or check an object reference' and even suggests an iterative workflow ('change the id/body and replay again'). It names a sibling to pair with for A-vs-B diffing. It does not state when not to use it (e.g., if a browser-level interaction is needed), but the guidance is strong and actionable.

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