Omneum
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingA | Verify that the Omneum MCP server is reachable. |
| evaluate_voprfA | 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. |
| evaluate_contextA | Evaluate relative source reliability and claim support from a caller-prepared graph of opaque linkage tokens and pairwise evidence dependencies. Use the Omneum SDK to prepare canonically ordered inputs and map returned tokens back to local context. Returns source reliability, claim support, conflicting claims, and estimated independent support for context selection. The server does not inspect source text, fetch sources, or independently determine factual truth or freshness. Graphs are evaluated without persistence; failures return isError=true with message and omneum_code. |
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 3 tools
ping is a clearly distinct health check, and evaluate_voprf vs evaluate_context target very different domains (cryptographic blinding vs. graph-based reliability scoring). The shared 'evaluate_' prefix creates only mild surface similarity, and the descriptions resolve it well.
evaluate_voprf and evaluate_context follow a clean verb_noun snake_case pattern. 'ping' is a bare verb with no noun, a minor deviation from the otherwise consistent scheme.
Three tools is at the thin end but reasonable for a narrow, focused cryptographic evaluation service. Each tool (health, VOPRF evaluation, context evaluation) earns its place without redundancy.
The core evaluation operations are present, but there is no key/deployment metadata retrieval, batch evaluation, or status/introspection beyond ping. Agents can work around this via the SDK but the surface has notable gaps for a full lifecycle.