Skip to main content
Glama

Recover sources

hexvero_recover

Extract recoverable sources from a bundle or source map into a new directory, writing bundle modules (plus a manifest of requires/exports) or embedded sourcesContent without executing anything.

Instructions

Write recoverable sources into a new directory: the modules of a webpack/Rspack/browserify/esbuild bundle (one file each plus hexvero-bundle.json with requires/exports), or the original files embedded in a source map (sourcesContent). No engine needed; nothing is executed.

Input Schema

NameRequiredDescriptionDefault
targetIdYesTarget id returned by hexvero_open
outputDirYesAbsent or empty directory to write into

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare this is a non-readonly, non-destructive, non-idempotent write into a new directory. The description adds meaningful context beyond that: the output artifact layout (one file per module plus hexvero-bundle.json with requires/exports) and that nothing is executed. It does not state what happens if outputDir is non-empty or whether writes are partial on failure.

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?

Two sentences, front-loaded with the action and its modes, then a compact safety clause. No wasted text and no repetition of schema or annotation content.

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

Completeness5/5

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

With no output schema, the description carries the return-value burden and does so by describing the produced files and the hexvero-bundle.json manifest. For a two-parameter write tool with full schema coverage and annotations, nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (targetId, outputDir) are already documented, including the 'absent or empty directory' constraint. The description adds no per-parameter detail beyond what the schema provides, so baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Write recoverable sources into a new directory') and enumerates the two source kinds it handles: bundle modules (webpack/Rspack/browserify/esbuild) and source-map sourcesContent. It is clear what the tool produces, but it never names or distinguishes itself from nearby siblings like hexvero_export or hexvero_sourcemap, which plausibly overlap.

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?

'Write recoverable sources into a new directory' plus the two enumerated cases gives a clear when-to-use context, and 'No engine needed; nothing is executed' reassures about prerequisites. There is no explicit exclusion or pointer to an alternative tool for the overlapping export/sourcemap cases.

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