MCP — both directions
ostk speaks MCP in both directions. Inbound: a configured MCP client drives the kernel through ostk connect. Outbound: ostk-driven agents can call configured, compatible MCP services through a userspace proxy. Client and server compatibility is integration-specific.
QUICK_REFERENCE
ostk connect Run the canonical stdio MCP bridge. It connects to the project daemon, starting it when possible, and refuses if no anchored daemon can be reached. There is no write-capable in-process fallback. ostk mcp diag Reconcile the kernel's MCP tool surface against CORE_SEED_LANGUAGE. Exits 1 on drift. ostk driver list List configured outbound MCP servers from HUMANFILE's mcp: section. ostk driver call <name> <tool> Invoke a tool on a configured outbound MCP server (ephemeral subprocess). ostk driver serve <name> Run an outbound MCP subprocess persistently on a Unix domain socket. ostk connect is the canonical inbound bridge command. The older bare ostk mcp spelling is a transitional alias; ostk mcp diag remains the diagnostic command. Outbound services use ostk driver list, call, and serve.
Drive ostk from an external MCP client
A supported MCP client launches ostk connect and speaks MCP JSON-RPC over stdio. Calls made through ostk tools receive generation tracking, hash-chained audit, and pin-cap enforcement. The client's native filesystem and shell tools remain outside that surface, so configure an allowlist when complete coverage matters.
Source: src/main.rs (Commands::Connect — runs run_mcp_bridge), src/serve/server.rs (run_mcp_bridge, bridge_stdio_to_daemon). The bridge resolved the "two isolated kernels" problem (→1309 Phase 2B) — the Claude Code MCP process and ostk daemon used to have separate ServerStates that couldn't see each other's work.
Configuration
Many MCP clients use an mcpServers-style configuration, but paths and field names vary. Use the current documentation for your verified client and point it at:
{
"mcpServers": {
"ostk": {
"command": "ostk",
"args": ["connect"]
}
}
} .mcp.json ~/.claude/settings.json ~/.cursor/mcp.json Verify the surface
Restart the client. Ask the agent to list its tools. You should see ostk-namespaced tools appear:
mcp__ostk__bash — kernel-mediated shell with audit + compressionmcp__ostk__read — file read with gen_table trackingmcp__ostk__fs_ops — file mutation with OCC conflict detectionmcp__ostk__search — unified code/files/needles/decisions searchmcp__ostk__lock, spawn, interact, session, tack, help — coordination primitives
The authoritative list is ostk mcp diag. Tool count varies by kernel version. Names are namespaced as mcp__<server>__<tool> by the MCP client — so mcp__ostk__bash is the bash verb routed through your ostk server entry.
First write — see the audit chain
Have the agent edit a small file. In your terminal:
$ tail -f .ostk/journal.jsonl
{"event":"tool.fs_ops","path":"src/lib.rs","gen_before":4,"gen_after":5,"writer":"claude-code-1","ts":"2026-04-26T19:42:11Z","prev_hash":"...","sig":"..."}
{"event":"tool.bash","cmd":"cargo check","exit_code":0,"duration_ms":2841,...}
Kernel-mediated dispatch rows are hash-chained through prev_hash and are Ed25519-signed when a signing key is available; unsigned rows remain visibly unsigned. CAS conflict handling applies to fs_ops edits that provide expected text. Pin caps apply to calls routed through the kernel, not to a client's native tools.
Inbound troubleshooting
DRIVING OSTK FROM CUSTOM TOOLS & SCRIPTS
Custom clients and CI can use the documented MCP bridge. Direct socket clients are an advanced, versioned System ABI integration and must implement the required initialization, identity, and request contracts; the snippets below are protocol sketches, not a universal client SDK.
1. Subprocess Pipe Transport (Stdio)
Spawn ostk connect as the stdio bridge. Write MCP JSON-RPC messages to its stdin and read structured responses from its stdout; the bridge requires the daemon-owned kernel.
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "read",
"arguments": {
"path": "src/main.rs"
}
},
"id": 1
}
2. UNIX Domain Socket Transport
Advanced clients can connect to the project UNIX domain socket at .ostk/ostk.sock and invoke version-compatible System ABI verbs directly. This bypasses MCP translation, but it does not bypass daemon identity, initialization, policy, or schema requirements.
const net = require('net');
const client = net.createConnection('.ostk/ostk.sock', () => {
client.write(JSON.stringify({
jsonrpc: '2.0',
method: 'read',
params: { path: 'README.md' },
id: 1
}) + '\n');
});
client.on('data', (data) => {
console.log('Kernel Response:', JSON.parse(data.toString()));
client.end();
});
Call external MCP services from ostk-driven agents
An ostk-driven agent can talk to a configured MCP service whose stdio and JSON-RPC behavior is compatible with the proxy. The driver subcommand connects, sends one request, prints the response, and exits. Compatibility and authentication must be verified per service.
Deliberately at arm's length: the kernel never speaks the outbound service's MCP protocol bytes. The configured subprocess can access the network and is not constrained by ostk pin caps; its invocation appears through the normal shell compression and audit path. Source: src/commands/mcp_proxy.rs (run_list, run_call, run_serve, run_persistent_call, run_ephemeral_call, run_jsonrpc_session).
Configuration
Outbound MCP servers are declared in .ostk/HUMANFILE under an mcp: section (not ostk.toml). Simple key-value: name → command line.
# .ostk/HUMANFILE mcp: linear: npx -y @anthropic/linear-mcp-server github: gh mcp-server postgres: npx -y @modelcontextprotocol/server-postgres
Source: src/commands/mcp_proxy.rs lines 7–11, 53, 134–147 (HUMANFILE parsing).
Execution modes
One subprocess per ostk driver call. Connect, JSON-RPC once, exit.
mcp_proxy.rs run_ephemeral_call.ostk driver serve <name> runs a long-lived subprocess on a Unix domain socket; subsequent calls reuse it.
mcp_proxy.rs run_serve, run_persistent_call.