Extract unencrypted secrets from .env files, encrypt them locally as VaultKey AAD records, and emit {{vault:sec_}} templates for AI agents to use without exposing plaintext.
Extract unencrypted secrets from a file (e.g. .env), encrypt them locally with VaultKey + AAD into sec_ records, and generate {{vault:sec_}} template (.env.tpl).
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | ||
| inPlace | No | ||
| vaultId | No | ||
| filePath | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does disclose the core pipeline (local encryption with VaultKey + AAD, creation of sec_<ulid> records, generation of a .env.tpl template). However, it omits critical behavioral traits: whether the source file is modified or deleted, what dryRun and inPlace actually change, and any permission or irreversibility considerations for a mutation tool.
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 dense sentence that front-loads the extraction step and lists the produced artifacts without padding. Every clause carries information; it is not verbose.
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 mutating tool with no annotations, no output schema, and 0% parameter coverage, the description explains the processing flow but leaves the operational contract incomplete — especially the effects of dryRun/inPlace and what the tool does to the original file.
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% and none of the four parameters are documented in the schema. The description only implicitly explains filePath (the file to absorb, e.g. .env) and says nothing about dryRun, inPlace, or vaultId, leaving the two behavior-altering flags uninterpretable.
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 names specific verbs (extract, encrypt, generate) and resources (.env secrets, sec_<ulid> records, .env.tpl template), so the operation's purpose is unambiguous. It does not, however, differentiate itself from plausible siblings like vault_scan_workspace or vault_inject_env, which an agent might reasonably confuse it with.
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 statement of when to use this tool versus the many sibling vault_* tools, no prerequisites, and no exclusions. Usage can only be inferred from the described transformation pipeline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.