Letting your agent deploy to Prostack Cito safely

What the MCP server is

MCP (the Model Context Protocol) is how coding agents call outside tools. The Cito MCP server, at mcp.prostack.uk, gives your agent a set of Cito tools: list your servers, check their health, read a site’s logs, create sites and databases, clone a site, and deploy the project you’re working on.

It’s in beta. It has been tested extensively, but agents still do unexpected things, so read each tool call before you approve it, and be specific in what you ask for.

Connect it

You sign in through the Cito dashboard, with the same passkey or two-factor code as always, and approve the MCP server for your account the first time.

Claude Code. Add the server, then run /mcp in a session to sign in:

claude mcp add --transport http Cito https://mcp.prostack.uk/mcp

Claude on the web or desktop. In Claude’s settings, add a custom connector with the URL https://mcp.prostack.uk/mcp, then click Connect.

Cursor. In Settings → Tools & MCP, add a server:

{ "mcpServers": { "Cito": { "url": "https://mcp.prostack.uk/mcp" } } }

Other tools are listed at mcp.prostack.uk. To check it’s working, ask “what Cito servers do I have?”.

What it can and can’t do

Ask in plain English, and the agent picks the tool:

• “Is my Cito server healthy?”
• “Show me the last 50 lines of the error log for example.com”
• “Create a MySQL database called app_db and add a read-only user to it”
• “Clone example.com to staging.example.com”
• “Deploy this project to Cito”

It can’t run arbitrary commands: on the server it only runs specific commands for the framework it’s deploying, and rejects anything else. It can’t read or write files outside /home, manage Docker containers, change redirects, cron jobs or caching, see malware scans, or read outbound email logs.

It can delete files, sites and databases. Every destructive action asks you to confirm first, which is one more reason to read what you’re approving.

What a deploy does

“Deploy this project to Cito” works from agents that run on your machine, such as Claude Code and Cursor. The agent:

1. looks at the project’s files to work out what it is (Next.js, Laravel and so on);
2. offers to create a site with the right setup, or uses one you name;
3. uploads the project with rsync, using an SSH key it creates for this deploy and deletes afterwards (it never touches your own SSH keys);
4. runs the framework’s install steps, such as npm install and the build, or composer install, and restarts Node apps.

The upload leaves out .git, node_modules, vendor and any file called .env, so your local settings never overwrite the server’s. Set environment variables on the server over SSH or in the File Manager. Environment variables on Prostack Cito explains why .env.local needs care.

Give it a staging-only login

The agent can do whatever the Cito login it signed in with can do. If that’s your owner login, it can reach every site on every server.

Cito’s team roles include Per-site, which limits a login to the sites you choose: their files, settings and databases, and nothing else on the server. So:

1. Clone the live site to a staging copy.
2. In the Cito dashboard, open Team (from your username, bottom left) and add a member for the agent with the Per-site role, with access to the staging site only.
3. Sign the MCP server in with that login.

Now a confused agent, or a badly worded request, can only affect staging. Owners and Admins keep their full access in the dashboard.

A way of working that holds up

1. The agent deploys to staging and checks it there: health, error logs, the pages you care about.
2. You look at the staging URL yourself.
3. The live site deploys from git, with a person pressing Deploy latest, so what’s live is always a commit in your repository.

Every Cito login needs a passkey or two-factor code, and the Audit Logs record who created, cloned or deleted sites and databases, every Git pull and every SSH key change, with timestamps. If something changes that you didn’t expect, that’s where to look.