12.9 An AI assistant as a client: MCP

Included from Basic tier

After this you can: connect an AI assistant through the Model Context Protocol on the stdio or HTTP lane, choose the credential it acts as, and state the governance posture.

Before you start — tick each one:

• Lesson 12.2 — Enrol, own, assign, grant, ceiling (opschain learn 12.2)

In the GUI: nothing extra — the assistant's calls show up as that principal's activity, and a change it raises waits in Reviews & approvals like anyone else's.

The module so far put an agent inside the platform. This lesson is the mirror image: your own AI assistant — Claude Desktop, an IDE, a hosted client — driving OpsChain from outside, through the Model Context Protocol, without weakening anything. opschain mcp serve exposes a curated set of tools to any MCP client: query the estate, plan and raise changes, run workflows, read logs, events and audit, answer approvals. The server is an API client of your OpsChain server — every tool call is an ordinary, audited API call under the credential you configure, so approval policies still gate, denied reads still answer not found, and refusals reach the assistant word for word. The full reference is opschain docs integrations-mcp.

1. A local assistant (stdio): Claude Desktop, IDEs

Local assistants launch the MCP server as a child process. Log in once so a credential is stored for the target:

opschain login --server https://opschain.example.com --token <api-token>

Then register the server with your assistant. For Claude Desktop, add to claude_desktop_config.json:

{
  "mcpServers": {
    "opschain": {
      "command": "opschain",
      "args": ["mcp", "serve", "--server", "https://opschain.example.com"]
    }
  }
}

IDE MCP configurations take the same command and arguments. What you should see: the assistant lists the OpsChain toolset, and its first read answers exactly what your login may read. It calls as you — what you may not read it cannot, and a change it raises waits on exactly the approvals yours would.

2. A hosted client (streamable HTTP)

For an assistant that cannot launch a child process, serve the HTTP transport — typically behind your reverse proxy, which owns TLS:

opschain mcp serve --server https://opschain.example.com \
  --auth-token <service-account-token> --http 127.0.0.1:8137

MCP messages POST to /mcp; each answers one JSON response (no SSE streaming in this cut, and the server says so politely if a client asks). Anyone who can reach the listener calls OpsChain as the configured principal — bind it privately and put your own access control in front.

3. Who the assistant is — the recommendation

The configured credential decides everything, so choose it deliberately:

• A service-account token (recommended for anything unattended). Enrol a dedicated identity for the assistant (lesson 7.3) and grant it exactly the access it needs. Its calls are individually attributable, its access is reviewable and revocable on its own, and switching it off severs the assistant without touching any person's access.
• Your own login (fine for an assistant acting as you). The default stdio lane uses the login stored by opschain login: the assistant holds your authority, and the audit trail shows you.

Neither is an agent in Felix's sense: the assistant holds no agent identity, no trust grant and no tier. It is a client, and the platform's answer to "may this client do that" is the same answer it gives you.

4. The governance posture, stated plainly

• The toolset is curated, never a generated dump of the API: each tool wraps one or two API calls with typed inputs, and mutating tools say honestly that creation may hold for approval and never waits.
• Approvals still gate. An assistant-raised change on a protected target queues behind the same approval policy as anyone else's; the tool returns the gate state, and the quorum holds.
• Refusals surface. An approval hold, validation violation or entitlement lapse reaches the assistant as a named tool error with the server's text verbatim — never swallowed, never rephrased.
• Every call is audited. The tool name rides the request's client identification, so the request log answers "which assistant verb did this" beside the principal.
• Tools the licence does not entitle are omitted from the listing, and the server re-checks on every call regardless.

The assistant gets hands; OpsChain keeps the supervision.

Check yourself

• Which credential should the assistant use, and what happens to a tool call that needs an approval?

What you learned

• opschain mcp serve exposes a curated OpsChain toolset to any MCP client, as a child process over stdio or as a streamable HTTP listener.
• The configured credential decides everything: a dedicated service account for anything unattended, your own login for an assistant acting as you.
• Every tool call is an ordinary audited API call — approvals gate, denials answer not found, refusals reach the assistant verbatim.
• An assistant is a client, not an agent: no agent identity, no trust tier — the same answer the platform gives you.

Next: this closes the module Agents — back to your track (opschain learn).