Skip to main content
Glama
privacyplaybook

sops-mcp

by privacyplaybook
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

sops_add_secrets

Add new secrets to an existing SOPS-encrypted file by decrypting, merging, and re-encrypting while preserving existing values and rejecting duplicate keys.

Instructions

Add new secrets to an existing SOPS-encrypted file. Decrypts the file, merges in new secrets, and re-encrypts — preserving all existing values and metadata. Rejects keys that already exist in the file. Supports generated, external, and derived sources. Requires a private key for the target domain.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoName of the key domain to encrypt to / decrypt with. Optional. Defaults to the domain recorded in the file's _meta_unencrypted block, and failing that to 'default'. Call sops_list_domains to see what this server has configured.
secretsYesNew secrets to add
encrypted_contentYesContents of an existing secrets.enc.yaml file

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.0
    • addedInput schema / properties / domain
      Added value: +{
+  "description": "Name of the key domain to encrypt to / decrypt with. Optional. Defaults to the domain recorded in the file's _meta_unencrypted block, and failing that to 'default'. Call sops_list_domains to see what this server has configured.",
+  "type": "string"
+}
  2. First observedv0.10.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the decrypt/merge/re-encrypt cycle, that existing values and metadata are preserved, that duplicate keys are rejected, and that a private key is required for auth. It omits atomicity/partial-failure behavior and does not say what the call returns, which matters for a mutation with no output schema.

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?

Four short sentences, front-loaded with the action and effect, then constraints and auth. No filler, and each sentence adds a distinct fact (effect, preservation guarantee, rejection rule, key requirement).

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 3-parameter mutation tool with no annotations and no output schema, the description covers purpose, side effects, preservation semantics, and auth requirements. The main remaining gap is the return value — an agent chaining this into a later call has to guess whether new encrypted content comes back.

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; the description adds meaning beyond it by summarizing the three source modes (generated/external/derived) at the top level and by stating the private-key requirement for the domain parameter, which the schema's domain text does not mention. It does not explain the nested secret fields, but those are fully documented in the schema.

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?

States a specific verb and resource ('Add new secrets to an existing SOPS-encrypted file') and immediately enumerates the mechanism (decrypt, merge, re-encrypt). The word 'existing' and the 'rejects keys that already exist' clause distinguish it from the sibling sops_create_secrets without needing either schema.

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?

Gives clear preconditions (file must exist, keys must be new, a private key for the target domain is required) and points at sops_list_domains for domain discovery. It never names the sibling an agent should use instead for keys that already exist (e.g. sops_update_external), so routing guidance is implied rather than explicit.

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

Deploy Server

Other Tools