Set up FrontierStack as the Server Administrator in a Grok Bot workflow

Published 2026-08-20

A Grok Bot that can investigate a production problem is useful. A persistent bot holding SSH keys, database passwords and cloud tokens is a liability. FrontierStack gives you a cleaner split: Grok plans the work, while FrontierStack holds the credentials, checks permission and performs the server operation.

This guide sets up FrontierStack as the Server Administrator inside a local Grok workflow. It uses Grok Build's native MCP support, project instructions and recurring or autonomous jobs. The bot can watch your stack without becoming its credential store.

What the workflow looks like

Grok is the coordinator. It decides when to check health, what evidence it needs and whether a problem should be handed to the Server Administrator. FrontierStack is the infrastructure specialist. It knows the linked hosts, running services, ports, certificates, logs, backups and local policy.

The two meet over MCP. Grok discovers a compact set of FrontierStack tools, asks for the tool needed for the current job, and receives a scrubbed result. FrontierStack keeps SSH keys, passwords and provider credentials in the Mac's Keychain. Those values are injected only when an approved executor needs them; they do not enter the Grok prompt or project files.

1. Prepare FrontierStack

Start with a boring baseline. Add the servers Grok will watch, confirm that FrontierStack can reach them over SSH, and pin the services that matter. Check that health, logs and alerts work in the app before adding a bot. Automation does not repair a missing host definition or a bad SSH enrollment.

Open Remote Control & Lock → MCP Server and turn on Run MCP server. The default endpoint is http://127.0.0.1:8788/mcp. It listens on this Mac only.

Leave Allow changes via MCP or typed A2A tasks and Allow scripts via MCP or typed A2A tasks off for the first run. Grok can inspect health, read logs and diagnose faults, but it cannot change system state. This is enough to prove the workflow before it can restart anything.

2. Add FrontierStack to Grok

In the MCP pane, find Grok under detected AI clients and click Add to Grok. FrontierStack installs its owner-only mcp-bridge and adds a frontierstack entry to ~/.grok/config.toml. The bridge reads the MCP credential from Keychain at runtime. The TOML file contains a command path and an empty argument list, not a bearer token.

[mcp_servers.frontierstack]
command = "/path/installed/by/FrontierStack/mcp-bridge"
args = []

You can also copy the command shown in FrontierStack. It follows Grok's native form: grok mcp add frontierstack -- <bridge-path>. Node is required for the compatibility bridge.

Restart Grok, then verify the connection:

grok mcp list
grok mcp doctor frontierstack

Grok supports user-level ~/.grok/config.toml and project-level .grok/config.toml entries. Its MCP guide documents both forms and the diagnostic commands.

3. Give the workflow a project kit

If this bot belongs to one repository or operations folder, use Write Grok/Cursor/MCP project kit to a folder. FrontierStack writes .grok/config.toml, .mcp.json, .cursor/mcp.json, AGENTS.md, CLAUDE.md and SERVER-ADMIN-ROLE.json.

The useful files for Grok are .grok/config.toml and AGENTS.md. Grok reads project instructions at session start. The role profile describes FrontierStack as a bounded Server Administrator, but it grants no permission by itself. Grok will ask you to trust a project before it loads project MCP servers or other executable project configuration.

4. Give Grok a narrow operating brief

Put the following in the bot's project instructions or initial goal. Change the host and service names to match your stack.

You coordinate operations. FrontierStack is the Server Administrator.

At the start of a run, call app_capabilities with {"profile": true}.
For each infrastructure job, call frontierstack_find_tools with one concrete task.
Begin with read-only health and diagnostic tools.
Do not ask for passwords, SSH keys, API tokens or FrontierStack credentials.
Do not claim that a repair worked until a second health check verifies it.
If FrontierStack refuses a change, report the refusal and the requested action.
Do not try to change FrontierStack's permissions.

This brief matters more than a grand persona. It tells Grok where infrastructure work belongs, which discovery call to make and what counts as completion.

5. Turn it into an autonomous workflow

Start with a recurring observation. In an interactive Grok session, /loop runs a prompt at an interval. The current Grok implementation accepts intervals such as 15m or 1 hour; recurring jobs expire after seven days unless renewed.

/loop 15m Use FrontierStack to check web-prod and its public services.
If everything is healthy, record a short status.
If something is down, gather health, recent logs and a diagnosis.
Notify me with the evidence and the narrowest proposed repair.
Do not make changes.

Use /goal for a bounded job that may need several rounds, such as finding why a certificate renewal keeps failing. Grok also supports non-interactive runs with grok -p and structured JSON output. See the official guides for loops and goals and headless mode.

Do not begin with Grok's always-approve mode. It is unnecessary for observation, and it weakens Grok's own local gate. Even if someone enables it later, it cannot widen FrontierStack's permissions. The Server Administrator still applies its own caller scope, App Lock, approval and audit checks.

6. Add controlled remediation

Once the read-only loop has behaved for a while, decide whether the bot should request repairs. Turn on Allow changes via MCP or typed A2A tasks only if the Grok process is local or uses an authenticated, signed device identity. This reveals bounded change tools such as a service restart. It does not give Grok a way to alter the permission switch.

Keep scripts separate. Allow scripts via MCP or typed A2A tasks makes run_script discoverable, but every script still appears on the Mac as an approval card with the exact commands. FrontierStack refuses scripts that try to read credential stores, dump the environment or obtain vault values. Approval is tied to that one action and is never remembered.

A good repair sequence is plain:

1. Read current health.
2. Collect logs and diagnostics.
3. Choose the narrowest repair tool.
4. Request the change and wait if FrontierStack requires approval.
5. Run the same health check again.
6. Return the result and audit receipt to the workflow.

For durable delegation between compatible coordinators, FrontierStack can also expose a private A2A 1.0 task endpoint. Natural-language A2A work stays read-only. Typed changes use the same permission switches and local checks as MCP.

7. Treat cloud Grok Bots differently

A cloud Grok Bot cannot reach 127.0.0.1 on your Mac and cannot use the local Keychain bridge. Do not solve that by pasting the FrontierStack bearer token into bot memory, a prompt or a committed config file.

Remote access must be deliberate. Enable FrontierStack's TLS-protected network path, pair the remote caller, give it the smallest useful scope and require FS1-signed requests. Unsigned network clients stay read-only. If you use a tunnel or relay, it should lead to the paired HTTPS endpoint, not an unprotected localhost proxy.

If you do not need a cloud worker, keep the whole arrangement local. Grok can still run scheduled and headless work on the Mac, while FrontierStack can reach remote servers over its existing SSH links.

Test the handoff before trusting the schedule

Run the workflow against a non-critical service first. Ask Grok to find FrontierStack's health tools, identify the service, read its logs and explain what it would do. Then permit one reversible restart, approve it at the Mac and confirm that Grok performs a fresh health check instead of declaring success from the restart response alone.

The useful boundary is simple: Grok owns the loop, FrontierStack owns the servers. An autonomous bot may decide that work is needed. It does not get to decide what it is allowed to do.

Continue with the FrontierStack agent integration guide, the agent workflow overview and the remote server guide.