MCP Server

Preview. Not yet released. The Untrace MCP server is planned and not yet published. The configuration below will not connect today. This page documents the intended tool surface so teams can plan agent integrations. The supported way to use Untrace right now is the dashboard. To be notified when the beta opens, request early access.

The Model Context Protocol is how AI assistants call external tools. An MCP server for Untrace lets an agent store and retrieve sensitive data through threshold-sharded vaults, instead of holding that data in a chat transcript, a scratch file, or a vendor's logs.


Why agents need this specifically

Agent workflows have a data-handling problem that predates any single vendor.

An assistant processing an onboarding document, a contract, or a medical record typically ends up with that content in several places at once: the conversation history, the tool call arguments, the provider's logs, and whatever temporary files the run created. Each of those is a complete copy, in one place, retained on someone else's schedule.

Giving an agent a sharded vault changes what it is able to leak. The agent holds a reference. The content is encrypted client-side and split across independent nodes, and retrieval requires a signed, policy-checked request per node. An agent that is prompt-injected into exfiltrating "the file" can exfiltrate an identifier, which is not the file.

This is the same argument as Why Encryption Is Not Enough, applied to a context window.


Intended configuration

For Claude Desktop, in claude_desktop_config.json:

{
  "mcpServers": {
    "untrace": {
      "command": "npx",
      "args": ["-y", "@untrace/mcp-server"],
      "env": {
        "UNTRACE_VAULT_ID": "vault_...",
        "UNTRACE_DID": "did:key:z6Mk..."
      }
    }
  }
}

For Claude Code and other clients that read .mcp.json, the same block works at the project root.

Server and package names are provisional until first publish.


Intended tools

ToolPurpose
untrace_list_vaultsList vaults the caller's DID can access.
untrace_storeEncrypt, shard, and distribute content. Returns an object reference.
untrace_retrieveFetch and reconstruct an object the caller is authorized to read.
untrace_shareGrant another DID access to a vault or object.
untrace_revokeRemove a DID's access.
untrace_describeReturn metadata about an object without returning its contents.

untrace_describe matters more than it looks. It lets an agent reason about what a vault holds, and decide whether retrieval is warranted, without pulling plaintext into the context window at all.


Intended authorization model

The server does not hold a long-lived credential that grants blanket read access. That would rebuild the single point of failure the architecture exists to remove.

  • Every retrieval is a nonce-scoped signed request, verified independently by each node against the on-chain access policy.
  • The agent's DID is granted scoped, expiring permissions, the same mechanism used for human sharing.
  • Write access does not imply read access. An agent can be permitted to deposit documents into a vault it cannot read back.
  • Access is revocable at the policy layer, so revoking an agent does not require rotating anything for other users.

Next