MCP server
Reviewed
🧩
AI agents plugin.
The fortrabbit MCP server connects an AI agent to your apps and environments over the Model Context Protocol. Authorization happens in the browser, so no token is pasted into a config file.
About the MCP server
The Model Context Protocol is a standard way for AI agents to discover and call the capabilities of an external service. Instead of being told which HTTP endpoints exist, the agent asks the server what it can do and gets a described list of tools back.
That makes the platform something an agent can operate. A coding agent with the repository already open can look up which environment runs which PHP version, clone a staging environment from the plans of a live one, read the build output of a failed deployment and set the variable that fixes it. No dashboard tab, no app ID copied between windows. Answers come back as data, so the agent can act on them in the same turn.
https://mcp.fortrabbit.com/mcp← remote endpoint
Requests pass the same authorization as the public API, so an agent never sees more than the person who authorized it.
Use cases
- An AI agent should see apps, environments, and deployments
- The agent runs on a machine with a browser, for the OAuth approval
- No credential should be pasted into a config file
Connect an agent
Each client has its own setup command. Instructions for Codex, Claude, Cursor and VS Code:
The Claude Code command carries --scope user. That registers the server for every directory instead of the current project only, which fits objects that belong to an account rather than to a repository. Other providers usually document the command without it.
The Codex command carries an explicit client ID. Codex 0.147 and newer publish their own metadata document and ignore it, older releases need it.
A client without OAuth support takes a personal API token as a bearer credential instead:
Authorization: Bearer frbit-at-YOUR-TOKEN
The rate limits are the same as on the REST API, counted per credential.
Authorize the connection
The setup command writes configuration, it does not sign in. A silent terminal is the expected result. Authorization runs on the first connection, and every client starts it differently:
| Client | Authorize with |
|---|---|
| Claude Code | /mcp, then Authenticate |
| Codex | codex mcp login fortrabbit |
| Cursor | Prompt on first connection |
| VS Code | MCP: List Servers |
claude mcp login fortrabbit does the same from the terminal, without opening a session first.
The browser page names the requesting client and the address the approval goes back to. Check both before approving. Approval issues an access token that expires after one hour and a refresh token that lasts 30 days, both bound to that one agent.
A page that never opens leaves the connection unauthorized, not broken. Repeat the step above.
Revoke access
Disconnecting from the agent side ends the connection immediately. In Claude Code that's /mcp, then Clear authentication. It drops the access token and the refresh token together, so the agent cannot quietly renew.
Disconnecting on the account side does the same for every connection that agent holds. That's the route to take when the machine running the agent is out of reach.
Uninstall
Removing a connection has two halves. Start in the client. Two of them remove the server from the command line, two need the config file edited by hand:
| Client | Remove with |
|---|---|
| Claude Code | claude mcp remove fortrabbit |
| Codex | codex mcp remove fortrabbit |
| Cursor | Delete the entry from ~/.cursor/mcp.json |
| VS Code | MCP: List Servers, or edit the profile mcp.json |
| frbit CLI | frbit mcp remove |
claude mcp remove needs no scope, it takes the server out of whichever scope holds it. VS Code has no counterpart to code --add-mcp, so removal happens in the editor or in the file. Dropping the entry does not drop the stored credentials, which live outside the config file. claude mcp logout fortrabbit and codex mcp logout fortrabbit clear those. Run the logout first when the machine is being handed on.
Then revoke the grant on the account side with the fortrabbit dashboard:
Reconnecting later does not need the setup command again, as long as the client entry is still in place. The client reports the server as needing authentication, and authorizing once restores access.
Available tools
The tool set can cover the objects you'd look at in the dashboard:
| Tools | Cover |
|---|---|
list_apps, get_app | Apps, with their region and software preset |
list_environments, get_environment | Environments of an app |
list_deployments, get_deployment, get_deployment_logs | Deployment history and build output |
list_domains, get_domain | Custom domains and generated environment URLs |
get_environment_variables | Custom and platform variables of an environment |
list_teams, get_team | Teams |
list_payment_methods, get_payment_method | Payment methods |
get_you | The account the credential belongs to |
A second group answers the questions that come up while writing a create call:
| Tool | Returns |
|---|---|
list_regions | Region identifiers, names, locations and recommendations |
list_software_presets | Preset slugs with the major versions each one supports |
list_php_versions | PHP versions, their end-of-life year and the platform default |
list_component_plans | Component slugs and sizes with specs and, per region, monthly price |
list_git_repositories | Repositories you can deploy from, with default branch |
list_git_branches | The branches of one of those repositories |
detect_repository_stack | The framework found in a repository and the preset that matches it |
Three tools change something. create_app creates an app together with its first environment, and can start the first deployment when the configuration allows it. create_environment adds an environment to an app, either from plans for php, storage, traffic and backups, or from an existing environment whose plans and settings it clones. update_environment_variables adds, changes and removes variables on an environment.
Restarts, deletions and standalone deployments are not exposed. Adding a tool is a separate decision each time; a REST endpoint existing does not make it available to agents.
Environment variables
update_environment_variables merges, it does not replace. Names under set are created or updated, names under delete are removed, and every other variable stays as it is. A partial payload can't wipe the rest of the file, and one name may not appear in both lists. create_environment takes the same variables as an argument, so a new environment can start with them in place.
Writes only reach your own variables. The FORTRABBIT and __FRBIT prefixes are rejected, so an agent can't shadow a platform variable.
Reads are a different matter. get_environment_variables returns what the REST API returns, and that includes the values fortrabbit injects, database credentials among them. Whatever an agent reads ends up in the model context of the connected client. Worth keeping in mind before pointing an agent at a production environment.
Apps and environments as resources
Apps and environments are also published as MCP resources, so you can point at one in a prompt instead of describing it: @fortrabbit:app/ap-a1b2c3 or @fortrabbit:env/en-a1b2c3, depending on how your client renders the picker. The payload is identity only, meaning public ID, name, and for an environment the app it belongs to. The tools above fetch the rest.
MCP or agent skills
The two work together and solve different halves of the problem. The MCP server gives an agent authorized access to platform objects. Agent skills give it the workflow knowledge: how a deployment is done, how a database is synced, which command to run over SSH.