Skip to content

Driving Restorm over MCP

Restorm exposes an MCP server (Model Context Protocol). An AI agent — Claude Code, Cursor, or any MCP client — can therefore read your project, create and run requests, and drive the interface.

That is what lets you say “import this Swagger, build a scenario that tests the ordering journey and run it” and get a verifiable result, in an application you keep in front of you.

The server is on by default. Two governing factors:

  • the Settings ▸ MCP ▸ Enable the MCP server setting;
  • an absolute rule: on a machine with no display, the MCP server never starts, whatever the setting says. A CI server therefore does not end up exposing an endpoint.

The status bar’s MCP indicator blinks on every inbound call. Its popover lets you suspend or resume the server for the session, and open the MCP logs.

The status bar's MCP indicator and its popover: the server's listening port, the connected session's name, and the "Stop the MCP server" and "View the logs" actions

At start-up, Restorm picks a free port, generates a process-specific access token, and writes a discovery file into the system’s temporary directory. The JSON-RPC server listens on 127.0.0.1:<port>/mcpon the loopback interface only: any external caller gets a 403.

A small proxy bridges your MCP client’s standard input and Restorm’s HTTP server:

{
"mcpServers": {
"restorm": {
"command": "node",
"args": ["scripts/mcp-launcher.mjs"]
}
}
}

It discovers the running instance, injects the token, and never starts Restorm silently: an instance whose MCP server you have switched off stays off, with a clear error message.

Read the port and the token from the discovery file, then send your JSON-RPC requests with an Authorization: Bearer <token> header.

Several Restorm processes can run in parallel. Every call accepts a reserved __session key to designate the instance targeted. The list-instances, create_instance and terminate_instance tools complete the picture.

Reading · navigation · project · writing · environments and secrets · import · execution · scenarios · instances · interface automation (screenshot, DOM query, input, shortcuts, themes, layout).

Four resources are exposed as well: restorm://project, restorm://tree, restorm://active-tab and restorm://request/{id}.

Full inventory: MCP tools.

The MCP server itself is never restricted. Each tool checks its own capability at call time.

  • Community edition — all request driving: run, cancel, read responses and history, read streams, send messages, import from a URL, open and close tabs, manage projects, write to the tree, manage environments and variables, quick settings, favorites, and the six firewall tools.
  • Pro edition — the scenarios domain (reading included), screenshots, all of interface automation, themes, the mini browser, the workbench layout, multiple instances, and the git tools.

A restricted tool stays listed — its title carries the (Restorm Pro) suffix — and returns an explicit, machine-readable error rather than disappearing.

  • Loopback and token: the server only listens on 127.0.0.1, and the token is compared in constant time.
  • Secrets: an agent receives a secret’s resolved value, just like the rest of the application — it drives Restorm on your behalf, with your own secrets. What the Secret type guarantees still holds: the value goes neither into the project, nor into an export, nor out to an unauthorised third-party service.
  • Real network effects: run_request genuinely calls the target. It is your MCP client’s approval flow that acts as the safeguard — keep it on.
  • The firewall applies: a call fired by an agent to an unknown origin raises the same authorisation prompt as one of yours.
  • Logging: every call appears in the MCP logs, with its request and its response.