Delete recording

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so safety is covered structurally. The description adds real value beyond that: the POST-only transport constraint and the side effect that rerecord=True schedules a future re-recording. It omits whether the underlying file is permanently removed and what permissions are needed, which keeps it short of a 5.

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 short sentences plus the endpoint line; the alternative-parameter behavior is front-loaded and nothing is padded. The opening line is a raw syntax dump rather than a summary, which slightly hurts front-loading.

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 destructive two-parameter mutation with no output schema and no schema descriptions, the entry covers both parameters and the transport requirement. It leaves out whether deletion is permanent/irreversible and what the response or failure mode looks like, which matters for a destructive call.

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 carries the full burden and largely succeeds: cmd_url is identified as the CmdURL taken from recorded_files.json, and rerecord is explained as a boolean that tells the DVR to record the episode again on a future airing, including the wire form &rerecord=1. No format detail is given for the cmd_url string itself.

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 definition makes clear this deletes a recording from the DVR, expressed as the underlying HTTP command (cmd=delete) against a CmdURL. The verb+resource are specific and the sibling hdhomerun_delete_rule covers rules rather than recordings, so an agent can distinguish them. It loses a point for framing the purpose as raw endpoint syntax rather than a plain statement of what the tool does.

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?

It states a hard prerequisite — cmd_url must come from recorded_files.json, i.e. hdhomerun_get_recorded_files — and warns that GET is rejected with 400 so the request must be a POST. It does not explicitly contrast with hdhomerun_delete_rule or explain when deletion is preferable to changing/keeping a rule, but the operational context is clear.

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