Skip to main content
Glama
OrygnsCode

opa-mcp-server

by OrygnsCode
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

Write data to OPA

opa_put_data
DestructiveIdempotent

Write or replace a JSON value at a specified data path in OPA. Use dotted or slash notation, or pass segments for keys containing both dots and slashes.

Instructions

Write or replace a value at the given data path. Body is sent as JSON. A path is read as dotted (users.alice) unless it contains a slash, in which case slash is the only separator (users/alice), so a key such as example.com is addressable as hosts/example.com. Pass segments instead when a key contains both.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoData path to write to.
valueNoJSON value to store at this path.
segmentsNoPath as literal key segments, e.g. ["labels", "app.kubernetes.io/name"]. Use instead of `path` when a key contains a dot or a slash.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.5.0
    • addedInput schema / properties / segments
      Added value: +{
+  "description": "Path as literal key segments, e.g. [\"labels\", \"app.kubernetes.io/name\"]. Use instead of `path` when a key contains a dot or a slash.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "minItems": 1,
+  "type": "array"
+}
    • removedInput schema / required
      Removed value: -[
-  "path"
-]
  2. Addedv0.1.13
  3. Removedv0.1.5
  4. Addedv0.1.2
  5. Removedv0.1.1
  6. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructive and idempotent hints; the description adds non-obvious runtime behavior: the body is JSON, path separator parsing switches between dots and slashes, and dot-containing keys can be addressed via slash-separated paths. This is meaningful context beyond the annotations.

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?

Every sentence earns its place: purpose, body format, separator rule, and segments fallback. The most important verb-first statement is front-loaded and the paragraph is dense without padding.

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?

The tricky path-encoding behavior is fully explained, and annotations cover the destructive/idempotent safety profile. There is no output schema and no response description, but for a write operation the essential calling requirements are covered.

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 baseline is 3, but the description elevates it by explaining how `path` is parsed, why `hosts/example.com` works, and when `segments` is the right parameter. It adds practical meaning not fully present in the schema's field descriptions.

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 states a specific action ('Write or replace a value') on a specific resource (OPA data path), which clearly distinguishes it from siblings like opa_patch_data and opa_delete_data. The 'replace' wording communicates full overwrite rather than merge or delete.

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?

It gives useful in-tool guidance for choosing path versus segments, but it never addresses when to use opa_put_data instead of opa_patch_data or opa_delete_data. Tool-vs-alternative selection is therefore left mostly implicit.

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