MCP Server PRO

Devkeepr works with your agents out of the box: start them from a project's menu, resume sessions, hand a failed process to one to fix. All of that is on the Agents page and needs no Pro plan.

The MCP server works the other way around. Your agent starts dev servers, test runs and builds all day, in shells you never see. Connected over MCP, it starts them through Devkeepr instead, and it can read everything Devkeepr knows about the project: output, logs, scripts, services, CI runs. You get to see the work while it happens, and the agent stops guessing at a project Devkeepr has already figured out.

Turning It On

The first time Devkeepr spots an agent without the connection, it asks once. The toast takes you to Settings → MCP server, where every agent found on your machine gets an install button. Installs take effect from the agent's next session.

Claude Code, Codex, Cursor Agent, Gemini, Copilot CLI, Amp, and OpenCode are supported. Aider doesn't speak MCP, so it sits this one out.

What Your Agent Can Do

Run things that outlive the session. A dev server the agent starts keeps running after the conversation ends, and you stop, rerun, or read it back like anything you started yourself. Runs are identified by name, so rerunning tests reuses the same row instead of piling up one per attempt. When the agent runs one of the project's own scripts it can skip the name, and the row reads as the command itself.

Run tests in one call. The agent waits for the result and gets the exit code and output back straight away. Quick runs like that can tidy up after themselves: a pass disappears, a failure stays until it's dealt with.

See what's already running. Terminals, scripts, and other agents' processes for the project, each with a short note about why it exists. No second dev server fighting the first one for a port.

Use the project's real commands. The scripts, Make targets and framework commands Devkeepr detected, so the agent runs your test suite the way the project runs it.

Read output and logs. Tail, page through, or search a process's output, with the searching done by Devkeepr instead of dragging the whole buffer into the conversation. Project logs come from the detected stack, including app logs that live outside the project folder.

Check services and CI. Which services Herd and Homebrew have running, and on which ports. After a push: GitHub Actions runs, GitLab pipelines, and Forge deployments, the same data behind CI Monitoring and the Deployment Watcher.

Where Its Runs Show Up

Give the workspace your agent works in an Activity panel, and every run it starts opens there as a new tab, beside the agent itself, with the newest one on screen. That's the way to work with an agent and see what it's doing as it does it.

Without one, its runs don't appear in the sidebar while they run or after they pass, so a busy agent doesn't bury your own processes. A failed run always shows up under its project.

Every run an agent started carries a small sparkles glyph. Hover it to see which agent started it and why. Go to Claude session in the row's menu, named for whichever agent it was, jumps to the conversation that started it.

Guardrails

Some things stay yours to decide. Agents are told to ask you before they hibernate or wake a project, register a new one, or trigger a CI run, since that spends your CI minutes. Starting a process in a hibernated project is refused outright, with instructions to ask you about waking it first. When an agent registers or hibernates a project, a toast names the agent that did it.

Tools

For the curious, this is what the server gives an agent: