oneguard-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ONEGUARD_API_KEY | No | Initializes the session on the first tool call. Without it, the agent must call oneguard_init with a key you supply. | |
| ONEGUARD_CLI_PATH | No | Absolute path to the binary, when it is not on PATH. | oneguard |
| ONEGUARD_MCP_HOME | No | Isolated credential store for the agent's session. | ~/.oneguard-mcp |
| ONEGUARD_MCP_READONLY | No | 1 hides every mutating tool. | false |
| ONEGUARD_MCP_TIMEOUT_MS | No | Per-command timeout. | 60000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| oneguard_initA | Initializes this server's isolated OneGuard session with an API key and verifies it against the backend. Normally you do NOT need to call this: if ONEGUARD_API_KEY is configured on the server, the session initializes itself on the first tool call. Call this only when another tool reports that the server is not initialized, and only with a key the user gave you in this conversation — never invent one. The key is kept for this session only and does not affect the user's own |
| oneguard_statusA | Verifies that the OneGuard CLI is installed, the session is initialized, and the backend is reachable. Returns the organization id and whether the configured API key may write. Use this first when something is not working, or before a batch of changes. |
| oneguard_env_syncA | THE MAIN TOOL. Fetches the secret linked to a directory and writes it into that directory's .env file, then remembers the link for next time. Call it with only project_dir when the directory is already linked (it re-pulls the latest values). If it is not linked yet, this returns the list of vaults (or secrets) to choose from — show those to the user, let THEM pick, then call again with vault and secret. Returns only the variable NAMES that were written; values go to disk and are never shown. |
| oneguard_env_statusB | Reports whether a directory is linked to a OneGuard secret, which one, and which variable names its .env currently holds. Read-only. |
| oneguard_env_pushA | Uploads the variables in a directory's .env file into the secret that directory is linked to, REPLACING what the secret held. The reverse of oneguard_env_sync. Confirm with the user first, and tell them which variable names are about to be uploaded. To add a single generated value without touching the rest, use oneguard_secrets_generate instead. |
| oneguard_env_unlinkA | Removes the .oneguard link file from a directory. The .env file on disk is left untouched. Equivalent to |
| oneguard_vault_listA | Lists every vault in the organization, with the 8-character id prefix that other tools accept as a vault argument. A vault is the container that secrets live in. |
| oneguard_vault_addA | Creates a new vault in the organization and returns its id. A vault is the container that secrets live in. |
| oneguard_vault_renameA | Renames an existing vault. Secrets, links and ids are unaffected — only the display name changes. |
| oneguard_secrets_listA | Lists the secrets of a vault: id prefix, name, and whether it is archived. Values are never returned by any tool in this server. |
| oneguard_secrets_addA | Creates a new secret in a vault from a local .env file (preferred) or from a single key/value pair. Prefer from_env_file: passing a value directly means the secret value travels through this conversation. To create a secret holding a NEW generated value, create it here and then use oneguard_secrets_generate, which never reveals the value. Never invent secret values — only use what the user explicitly provided or what is already in their .env file. |
| oneguard_secrets_editA | Replaces a secret's stored payload. IMPORTANT: this overwrites the whole payload — a single key/value pair replaces every key the secret held. To change one variable while keeping the rest: for a generated value use oneguard_secrets_generate (which merges), otherwise sync the secret to a .env file, edit that file, and push it back with from_env_file. Confirm with the user before calling this. |
| oneguard_secrets_archiveA | Archives a secret. It stops appearing as active but is not deleted. Confirm with the user before calling. |
| oneguard_secrets_deleteA | Permanently deletes a secret and everything stored in it. This cannot be undone. Only call this after the user has explicitly asked for this specific secret to be deleted, and read the secret name back to them first. |
| oneguard_generateA | Generates one or more random values locally and returns them. Nothing is stored anywhere. Note that the returned value passes through this conversation — if the value is going into a OneGuard secret, use oneguard_secrets_generate instead, which stores it without ever revealing it. |
| oneguard_secrets_generateA | Generates a random value and stores it in a secret under the given key, WITHOUT returning the value. This merges: every other variable in the secret is preserved (unlike oneguard_secrets_edit, which replaces the whole payload). Use this whenever the user wants a new password, token or key created for a service — it is the safe path, because the value never enters this conversation. Fails if the key already exists unless force is true. |
| oneguard_teams_listA | Lists the members of the organization with their roles and the 8-character id prefix other team tools accept. |
| oneguard_teams_inviteA | Sends an invitation to join the organization. This emails a real person and grants them access once accepted, so only call it when the user explicitly asked, with the exact address they gave. |
| oneguard_teams_set_roleA | Changes an existing member's role in the organization. Promoting to owner or admin grants broad access to every secret, so confirm the person and the role with the user first. The member can be named by email or by their 8-character id prefix. Note that an admin caller cannot modify owners, other admins, or promote anyone to admin or owner — the server enforces this. |
| oneguard_teams_removeA | Removes a member from the organization and revokes their access to every secret in it. This cannot be undone — they would have to be invited again. Only call this after the user explicitly asked for this specific person to be removed, and read their email back to the user first. |
| oneguard_logs_listA | Returns the organization audit log — who did what to which resource, and when. Useful for answering "who changed this secret" questions. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Each tool targets a distinct resource+action, and descriptions explicitly cross-reference near-neighbors (e.g. oneguard_generate vs oneguard_secrets_generate, secrets_edit vs secrets_generate, env_sync vs env_push vs env_unlink). Boundaries between session tools (init vs status) and vault/secret operations are also spelled out, so misselection is unlikely.
The dominant pattern is oneguard_<domain>_<verb> in consistent snake_case (oneguard_vault_list, oneguard_secrets_generate, oneguard_env_sync). Only oneguard_init, oneguard_status, and oneguard_generate omit the domain segment, a minor but noticeable deviation.
At 21 tools the set sits at the heavy end of the comfortable range, but the domain (vaults, secrets, teams, env linking, audit logs, session) genuinely spans that many operations. Each tool maps to a real workflow step rather than padding.
Core lifecycle coverage is strong: vault create/list/rename, full secret CRUD plus archive and generate, env sync/push/status/unlink, and team management. Gaps remain — no vault delete and, more importantly, no way to unarchive a secret once archived, creating a dead end for that state.