You can use the Omneum MCP server to ping it, perform RFC 9497 VOPRF evaluation, and evaluate source reliability and claim support from a caller-prepared dependency graph.
ping: verify the Omneum MCP server is reachable.
evaluate_voprf: evaluate one blinded Ristretto255 element with the deployment’s VOPRF key, returning a 32-byte evaluated element and 64-byte proof without seeing plaintext.
evaluate_context: evaluate relative source reliability and claim support from opaque linkage tokens and pairwise dependency scores, returning reliability, support, conflicts, and estimated independent support counts.
Runs locally via MCP for dependency-aware context auditing of AI agent retrieval and context selection.
Does not inspect source text, fetch sources, or determine factual truth; caller retains local mappings and raw context.
Agents routinely assemble context from many different sources — a RAG pipeline, web search, APIs, databases, files, memory systems, other agents — but stuffing dozens of raw chunks into a single context window can leave the model working through a mess of information that was never organized for it.
Most agents focus on retrieving more context. Omneum is focused on making sure the context reaching the model is clean and reliable.
⚡ Fast context auditing for AI agents.
33 ms median evaluation latency: Measured across 250 observations, 3 independent sources, 84 claims on Apple M5. No additional LLM inference or model judge steps.
Dependency-aware: Detects when multiple retrieved context chunks repeat information from the same upstream source.
Local by default: A content-blind graph algorithm running entirely within your environment, with SQLite persistence and optional PostgreSQL deployment.
Install the Python package:
pip install omneumRun the included demo:
python -m omneum.demoCreate evaluate.py to evaluate three observations against a single claim. Two sources reference the same upstream document.
import omneum
from omneum.explanations import explain_evaluation
observations = [
{
"url": "https://a.example",
"value": 4200000000,
"claim": {
"entity_namespace": "company",
"entity": "acme",
"attribute": "fy2025_gross_revenue",
},
"upstream": ["https://sec.example"],
},
{
"url": "https://b.example",
"value": 4200000000,
"claim": {
"entity_namespace": "company",
"entity": "acme",
"attribute": "fy2025_gross_revenue",
},
"upstream": ["https://sec.example"],
},
{
"url": "https://c.example",
"value": 4200000000,
"claim": {
"entity_namespace": "company",
"entity": "acme",
"attribute": "fy2025_gross_revenue",
},
"upstream": [],
},
]
result = omneum.evaluate(observations)
print(explain_evaluation(result))Run:
python evaluate.pyOutput:
Omneum Evaluation
Evaluation latency: 1.6 ms
Fy2025 gross revenue
4200000000
Support: 0.67
Supporting sources: 3
Estimated independent support: 2.00
Dependency signal coverage: 1.00
Explanation:
3 sources support this claim, with an estimated 2.00 independent sources. The available dependency signals indicate that some supporting sources are related.evaluate() runs Omneum's graph-based evaluation algorithm in-process; it computes source reliability and claim support scores, adjusting for dependencies between sources.
For raw retrieval text, use the optional extract_observations() API to extract structured claims with an LLM before evaluation. See Python SDK.
Related MCP server: footnote
Modern agent pipelines use several different techniques to decide what context should reach a model:
Semantic similarity (Vector DBs). The piece of text that looks closest to the prompt wins.
Semantic reranking. Retrieved context is reordered based on how relevant it is to the query.
LLM-as-a-Judge. An LLM reads the retrieved context and is instructed to evaluate it against a set of instructions.
These techniques can be highly effective at selecting context, but relevance is only one dimension of context quality.
Chunks can still hold conflicting or stale information. Multiple retrieved chunks might not be deduplicated or appear independent despite sharing an upstream source. This contributes to context bloat: low-quality information consumes context-window capacity that could otherwise be used for higher quality information.
Omneum addresses many of these limitations: it uses a graph-based mathematical analysis to model the relationships between claims and their supporting sources. Importantly, this analysis does not naively assume every source has derived its information independently. The same information often propagates across multiple sources. Without dependency tracking, an agent cannot distinguish five independent observations from the same information repeated five times.
Agent pipelines already handle structured metadata alongside retrieved context. Omneum uses available provenance and lineage metadata to estimate source dependencies, then incorporates those estimates into its calculation of source reliability and claim support scores.
These scores are computed without interpreting the semantic meaning of the context. For instance, when considering a claim such as:
“Acme reported $4.2 billion in revenue in 2025.”
Its support score depends on the reliability of the sources supporting it. In turn, those sources receive reliability from the claims they support.
This definition seems circular, and it is. Nonetheless, it yields a well-defined notion of reliability that helps distinguish strongly supported context from weakly supported context.
Omneum's production inference algorithm computes these reliability and support scores. Explore the experiments and research →
Omneum runs locally through its Python SDK or as a Model Context Protocol (MCP) server. It adds a lightweight post-retrieval evaluation layer to your existing retrieval or ranking stack; no inference request, no extra model call.
Retrieval / tools → Reranking (optional) → Omneum evaluation → agent control flow → LLM
Omneum returns context-quality signals; your agent makes evidence-aware decisions throughout its workflow.
Note: This tutorial assumes Python 3.11–3.14. SDKs for other languages are not currently supported.
Supported Platforms:
Platform | Supported |
macOS (Apple Silicon / arm64) | ✅ |
macOS (Intel / x86_64) | ✅ |
Linux (Ubuntu 22.04+ / x86_64) | ✅ |
Run the installer to configure the local evaluator:
omneum installRun omneum install from your normal login account. Don't run the command with sudo.
The installer runs unprivileged while it downloads and verifies the evaluator release. The daemon version is pinned to the installed Python package version. For example, Omneum 1.0.3 only accepts daemon assets from v1.0.3; it doesn't resolve latest or fall back to another release.
The archive is verified against the release SHA256SUMS before installation. A missing checksum, mismatched digest, unexpected archive entry, link, or path traversal stops the install before anything from the archive runs.
Administrator access is requested only when installing machine-level service files. On Ubuntu, this includes the managed runtime under:
/opt/omneumand public client configuration at:
/etc/omneum/config.tomlThe evaluator runs as a system service because its VOPRF private key is isolated from the login account and MCP process. On macOS it runs under launchd; on Ubuntu it runs under systemd with a separate service identity.
omneum-server connects MCP clients to the installed local service. The installer finishes by sending a VOPRF request through that path and verifying the response against the configured public key. A running service alone does not count as a successful installation.
See docs/guides/installation.md for service accounts, sockets, installed paths, custom endpoints, and failure handling.
Add Omneum to your MCP client configuration:
{
"mcpServers": {
"omneum": {
"command": "omneum-server"
}
}
}Restart your MCP client to expose Omneum's tools to your agent.
If your MCP client cannot find omneum-server, set command to the absolute path returned by command -v omneum-server.
Ask your agent to call Omneum's ping tool. A successful response returns "status": "ok", confirming that your agent can reach the Omneum MCP server.
Evaluate retrieved context using Omneum's Python SDK and local MCP server.
Use ContextMapper to map retrieved records into Omneum observations. The example uses three sources, two of which reference the same upstream document.
import asyncio
from datetime import datetime, timezone
from omneum.mcp import StdioServerParameters
from omneum import (
ContextMapper,
OmneumClientConfig,
Source,
open_stdio_client,
)
now = datetime.now(timezone.utc)
records = [
{
"id": "obs-1",
"raw_text": "Acme reported FY2025 gross revenue of $4.2 billion.",
"url": "https://example.com/report-a",
"value": 4_200_000_000,
"upstream": ["https://example.com/filing"],
"observed_at": now,
},
{
"id": "obs-2",
"raw_text": "FY2025 gross revenue for Acme was $4.2 billion, per the filing.",
"url": "https://example.org/report-b",
"value": 4_200_000_000,
"upstream": ["https://example.com/filing"],
"observed_at": now,
},
{
"id": "obs-3",
"raw_text": "Acme's FY2025 gross revenue totaled $4.2 billion.",
"url": "https://example.net/report-c",
"value": 4_200_000_000,
"upstream": [],
"observed_at": now,
},
]
mapper = ContextMapper(
source=lambda r: Source(kind="web_document", identifier=r["url"]),
entity_namespace=lambda r: "company",
entity=lambda r: "acme",
attribute=lambda r: "fy2025_gross_revenue",
value="value",
observation_id="id",
observed_at="observed_at",
upstream_sources=lambda r: [
{"kind": "web_document", "identifier": url}
for url in r["upstream"]
],
)The SDK handles canonicalization. See Canonicalization.
Connect to omneum-server and call evaluate_mapped():
async def main():
config = OmneumClientConfig.from_local_deployment()
server = StdioServerParameters(command="omneum-server")
async with open_stdio_client(config, server=server) as client:
evaluation = await client.evaluate_mapped(
records,
mapper,
)
print(evaluation.explanation)
asyncio.run(main())Save both Python blocks in evaluate_mcp.py, then run:
python evaluate_mcp.pyTo evaluate and select locally retained chunks in one operation, replace the
evaluate_mapped() call with:
from omneum import DependencyEstimatorConfig
from omneum.context_selection import claim_id
observations = mapper.map_many(records)
chunks = [
{"chunk_id": record["id"], "raw_text": record["raw_text"],
"claim_ids": [claim_id(observation.claim)]}
for record, observation in zip(records, observations)
]
estimator = DependencyEstimatorConfig(
upstream_weight=1.0, citation_weight=0.0, assertion_lineage_weight=0.0,
ownership_weight=0.0, temporal_weight=0.0, graph_weight=0.0,
temporal_window_seconds=7200.0,
)
result = await client.evaluate_context_with_chunks(
observations, chunks, estimator=estimator, token_budget=200,
strategy="coverage_support",
)
evaluation = result["evaluation"]
selected_chunks = result["chunks"]
context = result["context"]evaluation retains source reliability, claim support, and evaluation telemetry.
chunks contains only selected {chunk_id, score, raw_text} records in descending
utility order; context renders them in that same order. Raw text remains in
client memory and is never included in the MCP request. The consuming agent
assembles its own model request.
The default budget counts Unicode words and punctuation, including chunk headers.
Pass count_tokens=your_token_counter for model-specific accounting. Strategies
are retrieval, max_support, mean_support, and coverage_support; coverage
selection records marginal gains separately from final chunk utilities.
evaluation.explanation formats the evaluation result for inspection.
Omneum Evaluation
Evaluation latency: 10.6 ms
Fy2025 gross revenue
4200000000
Support: 0.67
Supporting sources: 3
Estimated independent support: 2.00
Dependency signal coverage: 1.00
Explanation:
3 sources support this claim, with an estimated 2.00 independent sources. The available dependency signals indicate that some supporting sources are related.Three sources report the same value, but two reference a shared upstream document. Omneum identifies this dependency and estimates 2.00 independent supporting sources instead of treating all three as independent evidence.
An agent can use this result to trigger additional retrieval or route execution back to a verification step before generating a response.
See Evaluation schema for result fields.
Use the Python SDK and ContextMapper to add Omneum to your agent.
Framework examples:
For a complete framework-independent workflow, see the enterprise policy example.
Omneum runs locally by default. You can opt in to contribute observations to the shared Omneum Context Graph without uploading raw context.
Network contributions help build a shared evidence base across agent deployments, extending the Context Graph beyond any single installation.
Contributions use privacy-preserving cryptographic linkage via an RFC 9497 VOPRF. Network contribution is disabled by default. Local evaluation works without it.
Hosted Network enrollment is currently limited to approved beta participants.
See Enable Network contribution (MCP) to get started, or How Network contribution works for technical details.
Context is more than a collection of text chunks. Omneum represents information encountered by an agent as observations — immutable records that preserve structured data and its provenance. The first supported type, an assertion observation, records a claim, its source, and the metadata needed to evaluate it.
Observation(
observation_id="obs-1",
source=source,
claim=claim,
observed_at=datetime.now(timezone.utc),
)Observations retain available provenance and metadata, including source ownership, timestamps, citations, upstream source relationships, and assertion lineage. Multiple assertion observations can support the same claim or report conflicting values without being merged or overwritten. Observations are not generated judgments about what is true: they preserve the evidence as reported.
Sources identify where an assertion originated. Each source has a kind and a canonical identifier for recognizing the same source across multiple observations. Sources can represent web documents, databases, internal services, or other information providers.
Source(
kind="web_document",
identifier="https://example.com/acme-filing",
)Claims represent specific assertions extracted from retrieved context, such as text chunks and tool outputs. Each claim consists of an entity_namespace, entity, attribute, and value. An integrating agent or retrieval pipeline extracts these fields, and ContextMapper maps them into Omneum's data model.
Claim(
entity_namespace="company",
entity="acme",
attribute="fy2025_gross_revenue",
value=4_200_000_000,
)Multiple sources can report the same claim without providing independent support. Omneum estimates source dependence from upstream lineage, citations, assertion lineage, shared ownership, timestamps, and graph structure.
Estimated source dependencies adjust the contribution of related sources when calculating independent support for each claim.
ContextMapper maps structured data from agent and retrieval pipelines into Omneum's observation model. It defines how source identifiers, claim fields, timestamps, and provenance metadata are read from existing records.
ContextEvaluation returns source reliability and claim support scores adjusted for source dependence, alongside conflict and provenance information.
evaluation = await client.evaluate_mapped(
records,
mapper,
)
print(evaluation.explanation)Evaluated on 24 held-out cases across six domains: coding agents, enterprise RAG, research and analysis agents, multi-agent systems, data analytics agents, and support and operations agents.
Measures how Omneum improves evidence selection when combined with semantic rerankers across diverse agent workflows.
Configuration | Precision ↑ | Recall ↑ | Answer Accuracy ↑ | Selection p50 ↓ | E2E p50 ↓ | Generator Tokens ↓ | Generator Cost ↓ |
BGE Reranker v2-m3 | 69.44% | 47.46% | 91.67% | 201 ms | 2.467s | 11,941 | $0.074618 |
BGE + Omneum | 85.51% | 59.31% | 87.50% | 660 ms | 3.020s | 11,595 | $0.070662 |
Cohere Rerank v4.0 Pro | 77.78% | 53.99% | 87.50% | 151 ms | 2.634s | 11,577 | $0.071242 |
Cohere + Omneum | 82.64% | 55.72% | 79.17% | 624 ms | 3.176s | 11,535 | $0.070654 |
Costs reflect estimated downstream generator API usage only; reranker API charges and local compute are excluded. Omneum improves selection precision and recall in both comparisons.
Each LLM judge is evaluated alongside Omneum under the same model-specific benchmark configuration.
Configuration | Precision ↑ | Recall ↑ | Answer Accuracy ↑ | Selection p50 ↓ | E2E p50 ↓ | Generator Tokens ↓ | Generator Cost ↓ |
BGE + Claude Sonnet 5.5 Judge | 92.36% | 65.24% | 95.83% | 1.831s | 4.165s | 11,356 | $0.068208 |
BGE + Omneum | 86.11% | 59.34% | 91.67% | 0.697s | 3.141s | 11,811 | $0.072822 |
BGE + GPT-6 Astra Judge | 92.78% | 65.45% | 92.50% | 3.421s | 5.849s | 111,247 | $0.658998 |
BGE + Omneum | 86.11% | 59.34% | 91.67% | 0.641s | 2.983s | 115,119 | $0.698310 |
BGE + Gemini 3.8 Flash Judge | 94.44% | 66.28% | 95.83% | 2.487s | 4.924s | 114,250 | $0.686916 |
BGE + Omneum | 86.11% | 59.34% | 91.67% | 0.639s | 3.130s | 115,535 | $0.702470 |
Costs reflect estimated downstream generator API usage only; LLM judge inference costs and local compute are excluded. Omneum achieves competitive selection quality and downstream answer accuracy against frontier LLM judges, with 2.6–5.3× lower selection latency and no additional LLM inference step.
Detailed evaluations: Methodology · Coding Agents · Enterprise RAG · Research Agents · Multi-Agent Systems · Data Analytics · Support Operations
Omneum uses SQLite as its default local storage backend. PostgreSQL is supported for deployments that use an external database.
Component | Implementation |
MCP server | Local |
Evaluator | Managed local daemon |
Local database | SQLite |
Graph model | Relational source, claim, observation, and dependency tables |
External database | PostgreSQL |
Graph extension | Apache AGE |
Service manager |
|
Cryptography | RFC 9497 VOPRF, Ristretto255-SHA512 |
Local installations create context.db automatically:
macOS
~/Library/Application Support/Omneum/context.db
Linux
~/.local/share/omneum/context.dbFor a new default graph with unsafe data-directory ancestors, Omneum uses
~/.omneum/data/context.db. Existing graphs and explicit paths are never
silently relocated; shared directory permissions are preserved.
PostgreSQL can be configured for deployments that use an external database. Apache AGE provides the graph projection for PostgreSQL deployments.
See docs/storage.md for the storage schema and deployment options.
Omneum evaluates context locally. omneum-server, the evaluator daemon, and context.db run within the local environment.
Component | Boundary |
Context | Passed to the local evaluation path |
Context graph | Stored in local |
VOPRF private key | Held by the evaluator daemon |
MCP process | Cannot read the evaluator's private key |
Source payloads | Not required in the graph |
Omneum Network | Optional contribution through the ingestion API |
Omneum persists the local context graph across MCP sessions.
application data
│
▼
omneum-server
│
├── evaluator daemon
│
└── context.dbLocal persistence and Omneum Network contribution are configured independently.
Option | Behavior |
Local persistence | Writes observations to |
Network contribution | Sends pseudonymous observations to the Omneum Network through the ingestion API |
See Omneum Network for Network contribution and Local Persistence for Context Graph storage.
External evaluations are published with the test inputs and Omneum outputs in evals/.
SearchTS. SearchTS 0.13.0 returned the same Go 1.22 claim from thenewstack.io through curl_cffi and go.dev through stealth-browser. Omneum received the original final_url and fetched_at values for both captures. The evaluation returned 2.00 estimated independent support, pairwise dependency 0.0000, and dependency-signal coverage 0.25. Results →
Jawz. Independent evaluation of Omneum 1.0.3 on 14 financial observations across 5 sources and 10 claims. Declared FRED lineage produced dependency scores of 1.00; omitting lineage reduced mean dependency from 0.70 to 0.42, while estimator v4 detected partial dependency (0.10) between shared-series pairs. Unrelated controls remained at 0.00. Runs were deterministic in a network-isolated Linux Docker environment. Results →
Bastra Recall. Recall ran Omneum 1.0.3 dependency-estimator-v4 against a 30-memory synthetic harness. Four memories sharing one upstream source collapsed to 1.0 effective independent support; three independent sources remained at 3.0. A temporal-only sweep moved continuously from 2.5 effective sources at identical timestamps to 3.0 at 48 hours. The evaluation also exposed an open lineage-chain case where v1 → v2 → v3 → v4 produces 1.6 rather than 1.0 because dependency is currently computed only across direct lineage edges. Results →
Contributions are welcome. See CONTRIBUTING.md.
If you find a security issue, please follow the private reporting process in SECURITY.md instead of opening a public issue.
Omneum is open source under the MIT License.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| assertions | Yes | 1-4096 unique assertion triples, sorted lexicographically by (source_id, attribute_id, claim_id). Each source may assert at most one claim per attribute; each claim belongs to exactly one attribute. At most 64 distinct sources, 2048 attributes, and 4096 claims. The sum of k*(k-1) across attributes, where k is the attribute's distinct claim count, must not exceed 16384 conflicting-claim entries. | |
| voprf_mode | Yes | VOPRF mode. Must be voprf. | |
| source_pairs | Yes | Complete unordered source-pair matrix: exactly n*(n-1)/2 entries for the n distinct sources in assertions, at most 2016 entries. Sort lexicographically by (source_a_id, source_b_id); use an empty array for one source. No duplicate, diagonal, reversed, or unknown-source pairs. | |
| deployment_id | Yes | Deployment identifier from the initialized client configuration or ping. Must be a canonical lowercase urn:uuid:… value matching this server. | |
| protocol_version | Yes | Omneum protocol version. Must be v1. | |
| voprf_ciphersuite | Yes | VOPRF ciphersuite. Must be ristretto255-SHA512. | |
| voprf_key_version | Yes | VOPRF key version matching this deployment's configured key version. | |
| linkage_encoding_version | Yes | Omneum linkage encoding version. Must be 1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discharges it well: it discloses that graphs are evaluated without persistence, that the server performs no source fetching or truth determination, and that failures return isError=true with a message and omneum_code. This is meaningful behavioral context an agent could not infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with purpose followed by setup guidance, return values, and limitations. Every sentence carries information, though it is tightly packed and could be marginally streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex cryptographic graph-evaluation tool, the description covers purpose, caller responsibilities, return contents, failure behavior, and explicit non-capabilities. With an output schema present, return values need not be detailed further, and nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains every parameter in depth (token format, ordering, dependency semantics, limits). The description adds only high-level framing about canonical ordering and opaque tokens, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (evaluate) and resource (relative source reliability and claim support) over a precisely characterized input (a caller-prepared graph of opaque linkage tokens and pairwise evidence dependencies). This is clearly distinguishable from siblings like ping and evaluate_voprf, which operate on different inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: use the Omneum SDK to prepare canonically ordered inputs and map returned tokens back to local context, and states explicit exclusions (server does not inspect source text, fetch sources, or determine truth/freshness). It does not explicitly name the alternative sibling or the condition selecting it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| voprf_mode | Yes | VOPRF mode. Must be voprf. | |
| deployment_id | Yes | Deployment identifier from the initialized client configuration or ping. Must be a canonical lowercase urn:uuid:… value matching this server. | |
| blinded_element | Yes | 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. | |
| protocol_version | Yes | Omneum protocol version. Must be v1. | |
| voprf_ciphersuite | Yes | VOPRF ciphersuite. Must be ristretto255-SHA512. | |
| voprf_key_version | Yes | VOPRF key version matching this deployment's configured key version. | |
| linkage_encoding_version | Yes | Omneum linkage encoding version. Must be 1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Verify that the Omneum MCP server is reachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, but for a zero-parameter health check there is little behavior to disclose. 'Verify ... is reachable' implies a read-only, side-effect-free probe, yet it does not confirm that (e.g. no auth required, no state change), so it is only minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every word earns its place and the purpose is stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema already defining the return shape, the description need not explain results. It is essentially complete for such a simple tool, with only the when-to-use context left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there are no parameter semantics to explain; the baseline of 4 applies. Nothing in the schema is left ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (verify) and resource (the Omneum MCP server's reachability), which is unambiguous and clearly distinct from the sibling evaluation tools evaluate_voprf and evaluate_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is a connectivity/health check to run before other calls, but the description never says when to use it, when not to, or that it is the natural first call. Adequate but leaves the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.5evaluate_context17 fields changedInput schema / $defs / Assertion / properties / attribute_id / descriptionAdded value: +"Opaque linkage token identifying the entity-attribute being asserted: canonical unpadded base64url encoding of 64 bytes, exactly 86 characters."Input schema / $defs / Assertion / properties / claim_id / descriptionAdded value: +"Opaque linkage token identifying a claim value for its attribute: canonical unpadded base64url encoding of 64 bytes, exactly 86 characters."Input schema / $defs / Assertion / properties / source_id / descriptionAdded value: +"Opaque source linkage token: canonical unpadded base64url encoding of 64 bytes, exactly 86 characters. Use the Omneum SDK to generate and retain its local mapping."Input schema / $defs / SourcePair / properties / dependency / descriptionAdded value: +"Caller-supplied pairwise evidence-dependency score, finite and within [0,1]: zero represents no modeled dependency; one represents maximal dependency. This does not certify exact equivalence."Input schema / $defs / SourcePair / properties / exact_equivalence / descriptionPrevious value: -"Explicit certification of identical evidence; not ordinary derivation."New value: +"Explicit certification of identical evidence; not ordinary derivation. True links form transitive equivalence groups. Group members must have identical claim profiles and uniform dependencies to other groups."Input schema / $defs / SourcePair / properties / source_a_id / descriptionAdded value: +"Source linkage token present in assertions, lexicographically smaller than source_b_id. Canonical unpadded base64url encoding of 64 bytes (86 characters)."Input schema / $defs / SourcePair / properties / source_b_id / descriptionAdded value: +"Distinct source linkage token present in assertions, lexicographically larger than source_a_id. Canonical unpadded base64url encoding of 64 bytes (86 characters)."Input schema / $defs / SourcePair / properties / weighted_signal_coverage / descriptionAdded value: +"Caller-supplied weighted coverage of observable dependency signals, finite and within [0,1]. Used for coverage diagnostics, not as an additional inference weight."Input schema / properties / assertions / descriptionAdded value: +"1-4096 unique assertion triples, sorted lexicographically by (source_id, attribute_id, claim_id). Each source may assert at most one claim per attribute; each claim belongs to exactly one attribute. At most 64 distinct sources, 2048 attributes, and 4096 claims. The sum of k*(k-1) across attributes, where k is the attribute's distinct claim count, must not exceed 16384 conflicting-claim entries."Input schema / properties / deployment_id / descriptionAdded value: +"Deployment identifier from the initialized client configuration or ping. Must be a canonical lowercase urn:uuid:… value matching this server."Input schema / properties / linkage_encoding_version / descriptionAdded value: +"Omneum linkage encoding version. Must be 1."Input schema / properties / protocol_version / descriptionAdded value: +"Omneum protocol version. Must be v1."Input schema / properties / source_pairs / descriptionAdded value: +"Complete unordered source-pair matrix: exactly n*(n-1)/2 entries for the n distinct sources in assertions, at most 2016 entries. Sort lexicographically by (source_a_id, source_b_id); use an empty array for one source. No duplicate, diagonal, reversed, or unknown-source pairs."Input schema / properties / voprf_ciphersuite / descriptionAdded value: +"VOPRF ciphersuite. Must be ristretto255-SHA512."Input schema / properties / voprf_key_version / descriptionAdded value: +"VOPRF key version matching this deployment's configured key version."Input schema / properties / voprf_mode / descriptionAdded value: +"VOPRF mode. Must be voprf."Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "ClaimSupport": {
+ "additionalProperties": false,
+ "properties": {
+ "agreement_weight": {
+ "maximum": 1,
+ "minimum": 0,
+ "title": "Agreement Weight",
+ "type": "number"
+ },
+ "attribute_id": {
+ "title": "Attribute Id",
+ "type": "string"
+ },
+ "claim_id": {
+ "title": "Claim Id",
+ "type": "string"
+ },
+ "conflicting_claims": {
+ "items": {
+ "$ref": "#/$defs/ConflictingClaim"
+ },
+ "title": "Conflicting Claims",
+ "type": "array"
+ },
+ "dependency_signal_coverage": {
+ "anyOf": [
+ {
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "title": "Dependency Signal Coverage"
+ },
+ "estimated_independent_support_count": {
+ "minimum": 1,
+ "title": "Estimated Independent Support Count",
+ "type": "number"
+ },
+ "is_attribute_max_support": {
+ "title": "Is Attribute Max Support",
+ "type": "boolean"
+ },
+ "support": {
+ "minimum": 0,
+ "title": "Support",
+ "type": "number"
+ },
+ "supporting_source_count": {
+ "minimum": 1,
+ "title": "Supporting Source Count",
+ "type": "integer"
+ },
+ "supporting_sources": {
+ "items": {
+ "$ref": "#/$defs/SupportingSource"
+ },
+ "title": "Supporting Sources",
+ "type": "array"
+ }
+ },
+ "required": [
+ "attribute_id",
+ "claim_id",
+ "support",
+ "agreement_weight",
+ "is_attribute_max_support",
+ "supporting_source_count",
+ "estimated_independent_support_count",
+ "dependency_signal_coverage",
+ "supporting_sources",
+ "conflicting_claims"
+ ],
+ "title": "ClaimSupport",
+ "type": "object"
+ },
+ "ConflictingClaim": {
+ "additionalProperties": false,
+ "properties": {
+ "claim_id": {
+ "title": "Claim Id",
+ "type": "string"
+ },
+ "support": {
+ "minimum": 0,
+ "title": "Support",
+ "type": "number"
+ }
+ },
+ "required": [
+ "claim_id",
+ "support"
+ ],
+ "title": "ConflictingClaim",
+ "type": "object"
+ },
+ "EvaluateAssertionResponse": {
+ "additionalProperties": false,
+ "properties": {
+ "claim_support": {
+ "items": {
+ "$ref": "#/$defs/ClaimSupport"
+ },
+ "title": "Claim Support",
+ "type": "array"
+ },
+ "deployment_id": {
+ "title": "Deployment Id",
+ "type": "string"
+ },
+ "linkage_encoding_version": {
+ "title": "Linkage Encoding Version",
+ "type": "integer"
+ },
+ "metadata": {
+ "$ref": "#/$defs/Metadata"
+ },
+ "protocol_version": {
+ "title": "Protocol Version",
+ "type": "string"
+ },
+ "source_reliability": {
+ "items": {
+ "$ref": "#/$defs/SourceReliability"
+ },
+ "title": "Source Reliability",
+ "type": "array"
+ },
+ "summary": {
+ "$ref": "#/$defs/Summary"
+ },
+ "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",
+ "summary",
+ "source_reliability",
+ "claim_support",
+ "metadata"
+ ],
+ "title": "EvaluateAssertionResponse",
+ "type": "object"
+ },
+ "Metadata": {
+ "additionalProperties": false,
+ "properties": {
+ "algorithm_version": {
+ "title": "Algorithm Version",
+ "type": "string"
+ },
+ "converged": {
+ "title": "Converged",
+ "type": "boolean"
+ },
+ "convergence_delta": {
+ "minimum": 0,
+ "title": "Convergence Delta",
+ "type": "number"
+ },
+ "convergence_tolerance": {
+ "minimum": 0,
+ "title": "Convergence Tolerance",
+ "type": "number"
+ },
+ "iterations": {
+ "maximum": 1000,
+ "minimum": 1,
+ "title": "Iterations",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "algorithm_version",
+ "iterations",
+ "converged",
+ "convergence_tolerance",
+ "convergence_delta"
+ ],
+ "title": "Metadata",
+ "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"
+ },
+ "SourceReliability": {
+ "additionalProperties": false,
+ "properties": {
+ "reliability": {
+ "minimum": 0,
+ "title": "Reliability",
+ "type": "number"
+ },
+ "source_id": {
+ "title": "Source Id",
+ "type": "string"
+ }
+ },
+ "required": [
+ "source_id",
+ "reliability"
+ ],
+ "title": "SourceReliability",
+ "type": "object"
+ },
+ "Summary": {
+ "additionalProperties": false,
+ "properties": {
+ "assertion_count": {
+ "maximum": 4096,
+ "minimum": 1,
+ "title": "Assertion Count",
+ "type": "integer"
+ },
+ "claim_count": {
+ "maximum": 4096,
+ "minimum": 1,
+ "title": "Claim Count",
+ "type": "integer"
+ },
+ "source_count": {
+ "maximum": 64,
+ "minimum": 1,
+ "title": "Source Count",
+ "type": "integer"
+ }
+ },
+ "required": [
+ "source_count",
+ "claim_count",
+ "assertion_count"
+ ],
+ "title": "Summary",
+ "type": "object"
+ },
+ "SupportingSource": {
+ "additionalProperties": false,
+ "properties": {
+ "contribution": {
+ "minimum": 0,
+ "title": "Contribution",
+ "type": "number"
+ },
+ "independence": {
+ "maximum": 1,
+ "minimum": 0,
+ "title": "Independence",
+ "type": "number"
+ },
+ "source_id": {
+ "title": "Source Id",
+ "type": "string"
+ }
+ },
+ "required": [
+ "source_id",
+ "independence",
+ "contribution"
+ ],
+ "title": "SupportingSource",
+ "type": "object"
+ }
+ },
+ "anyOf": [
+ {
+ "$ref": "#/$defs/EvaluateAssertionResponse"
+ },
+ {
+ "$ref": "#/$defs/OmneumErrorResponse"
+ }
+ ],
+ "type": "object"
+}evaluate_voprf8 fields changedInput schema / properties / blinded_element / descriptionAdded 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."Input schema / properties / deployment_id / descriptionAdded value: +"Deployment identifier from the initialized client configuration or ping. Must be a canonical lowercase urn:uuid:… value matching this server."Input schema / properties / linkage_encoding_version / descriptionAdded value: +"Omneum linkage encoding version. Must be 1."Input schema / properties / protocol_version / descriptionAdded value: +"Omneum protocol version. Must be v1."Input schema / properties / voprf_ciphersuite / descriptionAdded value: +"VOPRF ciphersuite. Must be ristretto255-SHA512."Input schema / properties / voprf_key_version / descriptionAdded value: +"VOPRF key version matching this deployment's configured key version."Input schema / properties / voprf_mode / descriptionAdded value: +"VOPRF mode. Must be voprf."Output 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"
+}v0.1.0evaluate_contextevaluate_voprfpingScored 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.
Context integrity for AI agents: evaluate freshness, confidence, provenance, and decision readiness.
Retrieve citation-ready technical context and coordinate evidence-backed work between AI agents.
Real-time fact-check, citation verification, and source-freshness for AI agents.
Review agent task evidence with sample deduplication, version filters and uncertainty intervals.