Secret Store

Import .env

import_env

Set many secrets at once from dotenv text (KEY=value lines). Existing keys are kept unless overwrite is true; protected keys and keys outside the token's limits are skipped and named. Requires secrets:write and the editor role.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>",
      "environment": "<environment>",
      "text": "<text>"
    },
    "name": "import_env"
  }
}

Input Schema

Name	Required	Description
`kind`	No	Store new entries as secret (default) or plain
`text`	Yes	dotenv text
`project`	Yes	Project slug or id
`overwrite`	No	Replace existing values (each replaced value stays in the version history)
`environment`	Yes	Environment slug or id, e.g. development, preview or production

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: existing keys are preserved unless overwrite is true, and protected or out-of-limit keys are skipped and reported by name. It also discloses the auth requirements (secrets:write and editor role), which the annotations do not carry. It stops short of describing the return payload or ordering, but the mutation semantics are well covered.

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?

Three tight sentences: what it does first, then the merge/skip semantics, then the permission gate. No redundant restatement of the name and no filler.

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?

For a mutating import tool with no output schema, the description covers format, merge behavior, partial-failure handling, and auth. The only soft spot is that the shape of the result (what 'named' skipped keys look like, success count) is only implied rather than described.

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?

Schema coverage is 100%, so the baseline is 3, and the description earns an upgrade by explaining the consequence of overwrite (non-overwrite runs keep existing values) and the format of text (KEY=value lines). The skip-and-name behavior for protected keys adds operational meaning the schema's parameter blurbs do not state.

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?

Specific verb and resource: 'Set many secrets at once from dotenv text (KEY=value lines).' The phrase 'many ... at once' implicitly distinguishes it from the single-key set_secret sibling, but that sibling is never named, so the differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

The description makes the use case clear (bulk import from dotenv text) and states prerequisites (secrets:write plus the editor role), which bounds when it can be called. It never explicitly says when to prefer this over set_secret or add-via-other tools, so routing depends on the agent inferring from 'many at once.'

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

All Secret Store tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?