hydra-mcp

hydra_hush

Destructive

Immediately blank all outputs, clear update() and document across all connected tabs, archiving first so no content is lost. Use as a panic wipe; for single changes, replace that block's definition.

Instructions

The panic button: blank every output, clear update(), reset speed to 1, and empty the document — every block, human-written ones included, in every connected tab.

The document is archived first (the path comes back as archived), so nothing is lost, but the screen goes black. To change one part, replace that block instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 14, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, and the description reinforces the destructiveness by detailing what gets destroyed (all blocks, human-written ones, in every tab) and the archival safety net. It adds context on the archive behavior and the black screen, which is valuable beyond the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a strong opening metaphor, followed by essential details about archiving and the alternative approach. Every sentence adds value, and the structure frontloads the critical destructive nature.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the zero parameters, the destructive scope is well-explained, and the archival behavior is disclosed. The output schema exists, so return values are covered. The only minor gap is not detailing what exactly the 'archived' path is used for, but it's not critical. Overall, complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters)Skip, so the description doesn't need to document any. It implicitly communicates that no parameters are required, which is sufficient. The coverage is 100% and there are no params to explain, so a baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is highly specific: it names the tool as a 'panic button' that blanks every output, clears update(), resets speed, and empties the entire document including human-written blocks across all tabs. It clearly distinguishes this from hydra_drop or hydra_block by emphasizing the global scope and inclusion of human content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (as an emergency reset) and explicitly states that to change only one part, one should replace that block instead. It does not explicitly name alternative tools, but the guidance is clear enough to prevent misuse.

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