MCP & Driving FrontierStack from Your Own AI

Chapter 13 covered the AI Administrator built into the app. This chapter is about the other direction: exposing FrontierStack to an AI tool you already use. FrontierStack runs as its own MCP server, so an external harness — Claude Code, Claude Desktop, Cursor, Codex or any Model Context Protocol client — can drive the whole app. The same guarded executors, the same approval cards, the same read-only-by-default posture — reached from your editor or terminal.

14.1Why drive FrontierStack over MCP

Two reasons stand out:

• No metered AI bill. When the harness is your own subscription tool — Claude Code on a Claude plan, a Cursor seat — the AI runs on the flat plan you already pay for. There is no per-token API charge for operating your servers.
• One agent for code and infrastructure. The coding agent already in your editor can now inspect and operate the servers that code runs on: read a production log, restart a service, check a certificate, run a migration — without leaving the tool you are working in.

14.2How it works

FrontierStack publishes its tool registry over MCP and binds the server to localhost behind a required token. Tool calls from the client route to the same executors the built-in Administrator uses and act on live app state — so your coding agent sees your real services, sites, fleet and health, not a copy. The safety model is identical to Chapter 13:

• Read-only until you opt in. The MCP surface stays read-only until you enable changes and scripts, exactly like the in-app assistant.
• The same approval card in front of every change. A mutating tool call from Cursor or Claude Code raises the same approval in FrontierStack that an in-app request would.
• Secrets never leave the Mac. The vault behaves the same way: scripts reference names, values are injected at run time and never sent to the model.

It also teaches a cold agent about FrontierStack itself. The read-only search_app_help tool searches only the app-authored Help index, so an outside harness can answer where a setting lives or what a control means without arbitrary file access. The frontierstack://manual resource supplies the canonical English/Japanese desktop and iPhone/iPad manual locations. Both are advertised by MCP discovery.

Stateless MCP is the default. FrontierStack supports MCP 2026-07-28: every HTTP request carries its protocol version, client capabilities and route, so it needs no hidden session or Mcp-Session-Id. server/discover reports the server's capabilities and cache hints. The owner-only Keychain bridge keeps the older initialize flow available for Claude Code, Cursor and other clients that have not moved to the new revision yet; the bridge never writes the bearer token into their configuration.

14.3Enabling the MCP server

On first contact FrontierStack offers to start its MCP server for you. You can also enable it yourself:

1. Open the MCP settings in FrontierStack and turn on the MCP server. It binds to localhost and shows the token and the endpoint URL.
2. Pick your client in the pane — Claude Code, OpenAI Codex CLI, Cursor, Gemini CLI or Claude Desktop — and copy the ready-made command or config. The website's MCP page has the same snippets.
3. Or use the one-click Add to… button, which writes the entry straight into that client's own config file (~/.codex/config.toml, ~/.cursor/mcp.json, ~/.gemini/settings.json, Claude Desktop's config). Any other MCP client works too — the protocol is an open standard.
4. Start a conversation in your tool and ask it to list FrontierStack's tools or your fleet to confirm the connection.

The installed frontierstack CLI also uses stateless MCP by default. Run frontierstack discover for machine-readable protocol and capability information; frontierstack info reports both the preferred stateless revision and the supported legacy revisions.

The separate MCP Servers pane can manage other servers in either generation. Its Automatic setting tries server/discover first and falls back to legacy initialize only when necessary. A green Stateless mark appears in the server list only after the HTTP server proves support; a stateless stdio server can be marked explicitly because the external client owns that process and handshake.

14.4Signed requests and device pairing (FS1)

The control and MCP servers add a per-device signed-request layer — FS1 — on top of the bearer token and TLS. Each paired device holds its own Ed25519 private key and signs every request; FrontierStack verifies the signature against the device you approved, so a leaked token alone cannot drive anything.

• Per-device scopes. Each device is granted a scope from read-only up to full control, set on the Mac.
• One-tap revoke. Remove a device and it is cut off instantly, without affecting the others.
• This is the same mechanism the iPhone and iPad app uses to pair — see the Mobile Manual, and the trust model in Chapter 10.

14.5External AI jobs

Beyond live MCP, FrontierStack can hand a job to a subscription AI CLI — package up a task and let your local Claude (or similar) work it under your plan, then bring the result back into the app. This is how heavier, longer-running analysis runs without a metered API bill, and it pairs with the Data Map (a per-location data-flow diagram) so the agent has the context it needs. External AI jobs are managed from the AI stack (Chapter 15).

14.6Skills, notes, memory and Obsidian over MCP

An external harness reaches the same knowledge surfaces as the built-in Administrator, subject to the same gates:

• Skills — your curated playbooks are discoverable and loadable on demand.
• Shared notes — only notes you unlocked with “Share with AI” are readable.
• Long-term memory — the same memory.md of preferences and standing rules.
• Obsidian — if you have linked an Obsidian vault, the agent can search your SOPs and runbooks and follow the documented procedure (Chapter 12).

14.7The Fleet Skill — portable context for any agent

The MCP server lets an agent act on your fleet. The Fleet Skill is the other half: static context that teaches an agent your world before it touches anything. The Fleet Skill pane generates a SKILL.md — your servers and their roles, OS, services and how to reach them; your network locations; your KVMs and power sources; and a free-text block of your own rules and preferences — with every secret stripped out. An agent that reads it picks the right host, uses the right path, and respects your conventions instead of guessing.

It is written to ~/.claude/skills/fleet/SKILL.md, which Claude Code discovers automatically — the description: in its frontmatter tells the model when the skill is relevant. MCP-connected agents can pull the same content through the get_fleet_context tool, and you can optionally also emit ~/AGENTS.md for CLIs that read that convention. Turn on auto-update and the skill is rewritten a few seconds after your fleet, locations or KVMs change, so it never drifts from reality.

Think of it as the difference between a map and a remote control. The MCP is the remote control — live, authenticated, able to do things. The skill is the map — zero-setup, portable, safe to hand to any agent, and the thing that stops a capable tool from doing the wrong thing in the right way.

14.8When to use which

All three reach the same guarded tools and the same live app state. Pick by where you prefer to work; the safety guarantees do not change.