MCP server

The MCP server is a thin bridge: it turns the TrustPlane workload signing flow into tools that any MCP client — Claude Code/Desktop, or another agent runtime — can call in natural language. The agent never holds an API key. Each call proves the workload’s identity, obtains a short-lived key, and signs exactly one request. Turn the server off and the agent has no path to the protected data.

Availability

The MCP bridge is a private preview. It is distributed via a private repository, not yet published to a public package registry or MCP directory. The steps below assume repository access; the setup is otherwise identical to what the public package will use.

What it does

• Enrolls once, caches. Proves the workload’s identity to Control through a trust anchor and activates a short-lived Ed25519 key, then resolves the key’s signing profiles. Re-enrolls only on key expiry.
• Signs any granted route. Exposes tools that list the routes the key is granted and send a signed request to any of them. Requests to routes the key is not granted fail closed.
• Holds no secret. The signing key lives in the bridge process (or an owner-only state file); the model sees only decisions, response bodies, and audit ids.

The tools

Tool	Purpose
list_routes	Enumerate the routes (method + path) the enrolled key is granted, from its resolved signing profiles.
signed_request(method, path, body?)	Send a TrustPlane-signed request to a granted route and return the response. Fails closed on ungranted routes (no_grant_for_route).
unsigned_request(path)	Control case — call a protected route with no signature, to show the API denies unsigned callers (401 missing_bearer_token).

Tool results are JSON. The model chooses the tool and the method/path/body from your natural-language request, so no TrustPlane-specific phrasing is required.

How it works

mint proof (k8s SA token / compact JWT)
  → enroll with Control            → short-lived Ed25519 key
  → resolve signing profiles       → per-route coordinates incl. the signing kid
  → sign the request transcript    → passport under the signing kid, TTL ≤ replay window
  → send                           → allow/deny + response

The upstream host and every per-route signing coordinate (signing kid, route id, audience, issuer, subject, trust domain) come from Control’s resolve response — so one server is upstream-agnostic: it signs whatever routes the key is granted, to whatever host the profile names. Two details the signer gets right for you: it signs under the resolve-issued signing kid (not the key id), and it keeps the passport TTL within the adapter replay window. See Enrollment troubleshooting for the failure modes those two rules avoid.

Configuration

The server is configured by environment (or a config.env file) — you set only which Control, policy, and proof source to use; everything else is resolved:

Variable	Purpose
TRUSTPLANE_CONTROL_URL	Control API base URL (not the console URL).
TRUSTPLANE_ENROLLMENT_POLICY_REF	Opaque enrollment policy reference (binds the key to a client and its grants).
TRUSTPLANE_PROVIDER	Trust-anchor provider the proof satisfies (oidc_jwks, ci_oidc, …).
TRUSTPLANE_K8S_NAMESPACE / _SA / TRUSTPLANE_TOKEN_AUDIENCE	Mint a Kubernetes ServiceAccount token as the proof.
TRUSTPLANE_PROOF_TOKEN_FILE	Or supply a pre-issued compact-JWT proof (CI OIDC, projected token). Used instead of kubectl.
TRUSTPLANE_PASSPORT_TTL	Passport TTL per request. Must be ≤ the adapter’s replay lifetime; 5m is safe.

Setup

# 1. obtain the bridge (private preview) and install its deps
git clone <bridge-repo>
cd <bridge-repo> && npm install

# 2. provide the trustplane CLI as ./tp (download the current release for your OS/arch)

# 3. configure for your Control + workload
cp config.env.example config.env   # set control URL, policy ref, proof source

# 4. sanity-check the signed path
sh signer.sh --list
sh signer.sh GET /your/route

# 5. wire into your MCP client (a .mcp.json is included for Claude Code), then run it
#    and ask naturally: "what can this workload call?", "get <resource>", "create <resource>"

What it does not do

• No stored API key. The workload never holds a bearer for the protected API; it signs each request under a short-lived key.
• No business authorization. The upstream still owns which record/tenant a request may touch after the signature is verified.
• No caller-selected grants. The routes the agent can reach are exactly the workload’s Control route grants — no more, no less.

Relationship to the CLI and SDKs

The MCP server drives the same enroll → resolve → sign flow as the CLI and the SDKs; it is the agent-facing surface over that flow. Use the CLI for scripts and pipelines, an SDK to embed signing in application code, and the MCP server to let an agent call protected routes conversationally.