Skip to main content
Glama
OrygnsCode

opa-mcp-server

by OrygnsCode
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

Sign OPA bundle

opa_bundle_sign
DestructiveIdempotent

Signs an OPA bundle directory with a provided key, writing a .signatures.json file for verification.

Instructions

Sign a bundle directory with opa sign. A directory is signed in place: .signatures.json is written into it and files are recorded as <directory name>/<file>, so the signed directory verifies wherever it is placed as long as its name is unchanged, with opa_bundle_verify or with opa build or opa run --bundle <name> from its parent. An archive is refused: OPA reads the signature from inside it, so a signed archive comes from opa_bundle_build with signingKey. The key is a PEM private key (RSA or ECDSA); for HMAC algorithms pass a file holding the secret. Extra claims such as keyid and scope come from claimsFile. Returns the path written, the algorithm, and the number of files covered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bundleYesPath to a bundle directory. Must be inside an allowed root. An archive is refused, since OPA reads the signature from inside it; build a signed archive with `opa_bundle_build` and `signingKey`.
claimsFileNoPath to a JSON file of extra claims to sign, such as {"keyid": "...", "scope": "..."}. Must be inside an allowed root.
signingAlgNoSigning algorithm: RS256 (default), RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, HS256, HS384, HS512.
signingKeyYesPath to the PEM private key (RSA or ECDSA), or for HMAC algorithms a file holding the secret. Must be inside an allowed root.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.0
    • changedInput schema / properties / bundle / description
      Previous value: -"Path to a bundle directory or `.tar.gz` archive. Must be inside an allowed root."New value: +"Path to a bundle directory. Must be inside an allowed root. An archive is refused, since OPA reads the signature from inside it; build a signed archive with `opa_bundle_build` and `signingKey`."
    • removedInput schema / properties / outputDir
      Removed value: -{
-  "description": "For an archive, the directory that receives `.signatures.json`; defaults to the archive's own directory. Must exist and be inside an allowed root. Not accepted for a directory bundle, which is signed in place.",
-  "type": "string"
-}
  2. Changed5 schema fields changedv0.5.0
    • changedInput schema / properties / bundle / description
      Previous value: -"Path to a bundle directory or archive. Must be in an allowed root."New value: +"Path to a bundle directory or `.tar.gz` archive. Must be inside an allowed root."
    • changedInput schema / properties / claimsFile / description
      Previous value: -"Path to extra claims to include in the signature."New value: +"Path to a JSON file of extra claims to sign, such as {\"keyid\": \"...\", \"scope\": \"...\"}. Must be inside an allowed root."
    • addedInput schema / properties / outputDir
      Added value: +{
+  "description": "For an archive, the directory that receives `.signatures.json`; defaults to the archive's own directory. Must exist and be inside an allowed root. Not accepted for a directory bundle, which is signed in place.",
+  "type": "string"
+}
    • changedInput schema / properties / signingAlg / description
      Previous value: -"Signing algorithm (e.g. RS256). Default: RS256."New value: +"Signing algorithm: RS256 (default), RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, HS256, HS384, HS512."
    • changedInput schema / properties / signingKey / description
      Previous value: -"Path to the signing key."New value: +"Path to the PEM private key (RSA or ECDSA), or for HMAC algorithms a file holding the secret. Must be inside an allowed root."
  3. Addedv0.1.13
  4. Removedv0.1.5
  5. Addedv0.1.2
  6. Removedv0.1.1
  7. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing the in-place mutation ('signed in place', `.signatures.json` is written), the naming scheme for recorded files, archive refusal, key-type constraints, and return values. These details align with `destructiveHint=true` and `idempotentHint=true` without contradicting them, and they compensate for the lack of an 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?

Although longer than typical tool descriptions, every sentence carries a distinct piece of information: action, side effects, archive exception, key details, claims, and return value. The most decision-relevant fact (archive refusal and `opa_bundle_build` route) is placed after the core mechanics, which is still well front-loaded and dense without padding.

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?

For a 4-parameter tool with no output schema, the description covers the operation, side effects, return payload, parameter specifics, and the important boundary case (archives). The only minor omission is behavior when `.signatures.json` already exists, but the `idempotentHint` annotation covers that, so nothing essential is missing.

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?

The schema already documents all four parameters (100% coverage), so the baseline is 3. The description adds value on top by explaining that RSA/ECDSA keys are PEM files while HMAC algorithms expect a file holding the secret, and by spelling out what `claimsFile` should contain. This moves it to a 4.

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?

The description opens with a specific verb+resource pair ('Sign a bundle directory with `opa sign`') and immediately differentiates from siblings by explaining it signs directories, not archives, and that signed archives come from `opa_bundle_build`. It also names `opa_bundle_verify` as the counterpart for verification, so an agent can distinguish it among the bundle-related tools.

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

Usage Guidelines5/5

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

Explicitly states that archives are refused and directs agents to `opa_bundle_build` with `signingKey` when a signed archive is needed. It also tells agents where the signed directory can be verified (`opa_bundle_verify`, `opa build`, `opa run --bundle`), making the tool's place in the workflow clear. No ambiguity about when to use this tool versus its bundle siblings.

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

Install Server

Other Tools