Skip to main content
Glama
cole-h06

Omneum

by cole-h06
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

evaluate_voprf

Evaluate one RFC 9497 blinded element with this deployment's VOPRF key to return a 32-byte evaluated element and 64-byte proof for Omneum client finalization; no plaintext is received.

Instructions

Evaluate one RFC 9497 blinded element using this deployment’s VOPRF key. Use the Omneum SDK for blinding, proof verification, and local finalization. Supply matching deployment metadata and a canonical base64url-encoded 32-byte blinded element. Returns a 32-byte evaluated element and 64-byte proof, both encoded as unpadded base64url. Evaluation uses the initialized local daemon and does not receive the original plaintext. Capacity or deadline failures return isError=true with message and omneum_code.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
voprf_modeYesVOPRF mode. Must be voprf.
deployment_idYesDeployment identifier from the initialized client configuration or ping. Must be a canonical lowercase urn:uuid:… value matching this server.
blinded_elementYesOne serialized 32-byte RFC 9497 blinded Ristretto255 element, encoded as canonical unpadded base64url: 43 characters using A-Z, a-z, 0-9, _, and -. Generate it with the Omneum client's blinding operation; do not submit plaintext.
protocol_versionYesOmneum protocol version. Must be v1.
voprf_ciphersuiteYesVOPRF ciphersuite. Must be ristretto255-SHA512.
voprf_key_versionYesVOPRF key version matching this deployment's configured key version.
linkage_encoding_versionYesOmneum linkage encoding version. Must be 1.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.1.5
    • addedInput schema / properties / blinded_element / description
      Added value: +"One serialized 32-byte RFC 9497 blinded Ristretto255 element, encoded as canonical unpadded base64url: 43 characters using A-Z, a-z, 0-9, _, and -. Generate it with the Omneum client's blinding operation; do not submit plaintext."
    • addedInput schema / properties / deployment_id / description
      Added value: +"Deployment identifier from the initialized client configuration or ping. Must be a canonical lowercase urn:uuid:… value matching this server."
    • addedInput schema / properties / linkage_encoding_version / description
      Added value: +"Omneum linkage encoding version. Must be 1."
    • addedInput schema / properties / protocol_version / description
      Added value: +"Omneum protocol version. Must be v1."
    • addedInput schema / properties / voprf_ciphersuite / description
      Added value: +"VOPRF ciphersuite. Must be ristretto255-SHA512."
    • addedInput schema / properties / voprf_key_version / description
      Added value: +"VOPRF key version matching this deployment's configured key version."
    • addedInput schema / properties / voprf_mode / description
      Added value: +"VOPRF mode. Must be voprf."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$defs": {
+    "EvaluateVOPRFResponse": {
+      "additionalProperties": false,
+      "description": "Single-element RFC 9497 VOPRF evaluation response.",
+      "properties": {
+        "deployment_id": {
+          "title": "Deployment Id",
+          "type": "string"
+        },
+        "evaluated_element": {
+          "title": "Evaluated Element",
+          "type": "string"
+        },
+        "linkage_encoding_version": {
+          "title": "Linkage Encoding Version",
+          "type": "integer"
+        },
+        "proof": {
+          "title": "Proof",
+          "type": "string"
+        },
+        "protocol_version": {
+          "title": "Protocol Version",
+          "type": "string"
+        },
+        "voprf_ciphersuite": {
+          "title": "Voprf Ciphersuite",
+          "type": "string"
+        },
+        "voprf_key_version": {
+          "maximum": 4294967295,
+          "minimum": 1,
+          "title": "Voprf Key Version",
+          "type": "integer"
+        },
+        "voprf_mode": {
+          "title": "Voprf Mode",
+          "type": "string"
+        }
+      },
+      "required": [
+        "protocol_version",
+        "deployment_id",
+        "voprf_key_version",
+        "voprf_mode",
+        "voprf_ciphersuite",
+        "linkage_encoding_version",
+        "evaluated_element",
+        "proof"
+      ],
+      "title": "EvaluateVOPRFResponse",
+      "type": "object"
+    },
+    "OmneumErrorResponse": {
+      "additionalProperties": false,
+      "description": "Stable structured tool failure.",
+      "properties": {
+        "message": {
+          "title": "Message",
+          "type": "string"
+        },
+        "omneum_code": {
+          "enum": [
+            "request_too_large",
+            "invalid_request",
+            "authentication_required",
+            "permission_denied",
+            "unsupported_protocol_version",
+            "deployment_mismatch",
+            "voprf_key_version_mismatch",
+            "unsupported_voprf_mode",
+            "unsupported_voprf_ciphersuite",
+            "unsupported_linkage_encoding_version",
+            "invalid_blinded_element",
+            "invalid_graph",
+            "rate_limited",
+            "server_busy",
+            "request_timeout",
+            "evaluation_failed",
+            "assertion_evaluation_failed",
+            "internal_error"
+          ],
+          "title": "Omneum Code",
+          "type": "string"
+        }
+      },
+      "required": [
+        "message",
+        "omneum_code"
+      ],
+      "title": "OmneumErrorResponse",
+      "type": "object"
+    }
+  },
+  "anyOf": [
+    {
+      "$ref": "#/$defs/EvaluateVOPRFResponse"
+    },
+    {
+      "$ref": "#/$defs/OmneumErrorResponse"
+    }
+  ],
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A3.9/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 that evaluation runs against the initialized local daemon, that the server never receives plaintext, and that capacity/deadline failures surface as isError=true with a message and omneum_code. It stops short of stating permission/auth requirements or whether evaluation is side-effect-free.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five dense sentences, each carrying real information, with the core action front-loaded. It is technically heavy but not padded; no sentence is redundant.

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 cryptographic mutation tool with seven required parameters and no annotations, it covers the input contract, encoding of both output values, plaintext non-disclosure, and error signaling. With an output schema present, return-value detail is not required, though auth/idempotency context would have closed the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter, and the baseline is 3. The description reinforces the blinded_element format (32-byte, canonical unpadded base64url) and the need for matching deployment metadata, but adds little syntax beyond 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: evaluate one RFC 9497 blinded element using this deployment's VOPRF key. This is clearly distinct from the siblings ping (liveness) and evaluate_context (context evaluation), and the cryptographic scope is unambiguous.

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 tells the caller to use the Omneum SDK for blinding and to supply matching deployment metadata, which implies the prerequisite workflow. However, it never states when to choose this tool over evaluate_context or what the preconditions are (e.g., daemon must be initialized with a key version).

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