Cursor MCP for Web Hosting: Let the Agent Deploy and Debug

With Cursor MCP, your editor becomes the one window where you write code, see why a deploy broke and get it fixed. Connect Voroa once and you can ask Cursor’s agent about a failing deploy while the file is still open. This post is written for people who live in the editor: the mcp.json block, what to ask when a build goes red, how Run Modes gate Voroa’s tools, and how to pair it with SSH from the terminal panel.

Cursor as the place you already look

In an IDE, context is everything. The agent can see the file, the diff and the terminal. What it does not see is the build output on your host. Voroa’s MCP server, run by Voroa, turns that output into one more thing Cursor can read, next to your code.

One block in `mcp.json`

Create a token in the Voroa dashboard under Settings, API tokens (copy the voroa_cat_ value the moment it appears; Voroa will not show it again) and store it as an environment variable named VOROA_TOKEN. Then add this to ~/.cursor/mcp.json for all projects, or to .cursor/mcp.json for just one:

json

{
  "mcpServers": {
    "voroa": {
      "url": "https://api.getvoroa.com/mcp",
      "headers": { "Authorization": "Bearer ${env:VOROA_TOKEN}" }
    }
  }
}

The ${env:...} reference matters most in the project file, since that file sits in your repository. The Cursor MCP documentation covers the format and transports. Restart Cursor and ask the agent to name your most recent Voroa deploy. A real service name means it worked; a reply about a missing tool means Cursor has not loaded the file yet. Our client connection troubleshooting covers the rest.

Asking about a failing deploy from the editor

Four-part diagram: the agent pushes code, reads the deploy status, reads the build log, and fixes then redeploys

You push from Cursor, switch to another file, and a few minutes later the service is still on the old version. Instead of opening the dashboard, type into the agent chat:

Why did my last Voroa deploy of the api service fail? Fix it here and push again.

The agent reads the deploy history, confirms the failure through the service status, and opens the build log. Say the log points at an import that does not exist. The agent jumps to that file, which is already open in your editor, corrects the path and shows you the change. Once you accept, it commits and pushes, and auto-deploy starts a new build that it watches to the end. When a build passes but the service will not start, it reads the runtime logs instead. More prompts like this are in Voroa’s playbook for coding agents.

How Run Modes gate Voroa’s tools

Cursor asks for approval before using MCP tools, and those tools follow the same Run Modes as terminal commands:

Allowlist: only calls you have allowed run on their own;
Auto-review: allowlisted calls run, others go to the sandbox or a classifier;
Run Everything: every tool call runs automatically.

For a project that deploys to production on push, Allowlist is the sensible start. Allow the Voroa read tools first, and add push once you trust the pattern. Cursor’s Run Modes page explains each one. By default the sandbox network permits GitHub, so a push from the agent should get through.

What a Cursor-connected token can and cannot reach

Pick the scope when you create the token. services:read is enough to diagnose; services:act lets the agent redeploy or roll back; services:write lets it set env variables. Even services:admin cannot create or delete services, databases or domains. It can only propose them for you to approve in the dashboard. The agent sees which variables are set but not their values, it cannot retrieve database credentials, and a token covers one workspace for 90 days (30 on admin). The complete list is on the Voroa MCP server reference.

SSH from Cursor’s terminal panel

When the logs cannot tell you whether a file exists in the running container, go to the SSH Access page for that service. Register your public key there and copy the login line, which uses port 2222 on ssh.getvoroa.com with the service ID as the user name.

Paste it into a terminal inside Cursor and run it yourself. Cursor’s docs do not say whether the agent sandbox allows arbitrary SSH hosts, so a session you open by hand is the reliable route. Check what the agent asked about, then paste the output into the chat. Whatever you change by hand is wiped by the following deploy, except files kept on a persistent disk, so the real fix still goes through the editor and git. See SSH access to your service.