Voroa MCP server: manage your hosting from an AI client
Voroa's MCP server lets an AI client read logs, deploy and manage your services. What MCP is, which tools exist, and where the boundary of what it can do sits.
The Model Context Protocol is a standard way for an AI assistant to call tools that someone else provides.
A platform that publishes an MCP server gives the assistant a fixed list of actions. The assistant does not have to be taught the platform by hand, and it cannot do anything outside that list.
Voroa publishes one for customers. This page is what it exposes and where its edges are. To connect a client, see Connect an AI client.
Why a tool server rather than an API key
An API key gives away everything the API can do, and trusts the caller to be careful. A tool server gives away a list.
That matters most when you are not watching. An agent that misunderstands an instruction can still only reach the tools it was given, and the tools that could lose your data are not on the list.
Voroa uses the same routes here that the dashboard uses. There is no second, parallel API.
This gives you one useful guarantee: a feature added to the dashboard tomorrow is not reachable by an AI client until someone adds it to the list on purpose. New features do not appear here by accident.
The four scopes
A token carries exactly one scope, and each contains the one before it.
services:read - everything you can see in the dashboard. Services and their status, deploy
history, build logs, runtime logs, domains, databases and their settings, usage, previews, scheduled
tasks and their runs, projects, environments and environment groups, and Object Storage buckets (their
plan, usage and file list), database backups, metrics and slow queries, extensions, autoscaling, edge
caching, disk, the repositories you can deploy from, your workspace’s alert settings, its members (names
and roles - never email addresses), your SSH public keys, and your support tickets. Environment
variables and secret files come back as names only.
services:act - redeploy, restart, stop, start, roll back, cancel a running deploy, turn
maintenance mode or DDoS protection on and off, clear the edge cache, and scan a service’s disk. None of
them destroys anything. A rollback goes back to a deployment you already had.
services:write - configuration. Set environment variables and secret files, add a domain, create
and edit scheduled tasks, projects, environments and environment groups, change database settings and
users, take a database backup or turn nightly backups on, verify a domain, copy variables into preview
deploys, set alert emails, open, answer and close support tickets (a few a day, each marked as sent by
an AI client), and connect a bucket to a service (its key is written into the service’s
environment variables, and never shown to the agent).
services:admin - the ability to propose the actions that create, destroy, cost money or cannot
be undone. It performs none of them.
What is deliberately absent
Three things are off the surface entirely, and no scope reaches them:
- Database connection credentials.
GET /databases/:uuid/connectionis not on the list. An agent can see a database and change its settings; it cannot read the password. The same goes for a bucket’s secret key and for file download links: an agent can list a bucket’s files, not open them. - The live build-log stream. Finished logs are readable. The streaming connection is not carried by this transport.
- Token management. No tool creates or deletes a token, not even its own. If one could, it would be able to give itself a longer life.
Some things need no rule at all, because they are simply not here: scaling a service, changing a plan and cancelling a subscription are not tools. A tool that does not exist cannot be misused.
A request outside the list returns 404, not 403. This is deliberate. A 403 would tell the caller that the action exists but is blocked, and that in itself is information we do not want to give away.
The actions that require a person
Creating a service, a database or a bucket. Deleting anything. Restoring a database from a backup or to a past minute. Turning point-in-time recovery or nightly backups off. Enabling a database extension or changing a key-value store’s eviction policy. Turning HSTS on, changing edge caching, setting autoscaling. Removing a member, moving a member to a lower role, or removing an SSH key. Creating a deploy hook or a new bucket key - the URL or key is shown once, to the person approving, never to the AI client.
An AI client can never give access: inviting someone, raising a member’s role and adding an SSH key are dashboard-only, at every scope.
On services:admin an AI client calls propose. Voroa records the intent and returns a summary; the
customer approves it in their own dashboard, and the dashboard performs the action through the same
authenticated route a click would have used. Proposals expire after an hour.
Everything on that list either costs money or cannot be undone. Nothing else is on it. Asking someone to confirm a harmless action only teaches them to click through confirmations without reading them.
Why the confirmation is not in the conversation
Asking the agent to type the database name to agree would not stop anything. The agent read that name one step earlier and can type it itself. The same agent would be on both sides, and no person would be involved.
Putting the approval in the dashboard is what makes it a real second check instead of a formality.
Scope of a token
One token, one workspace. A token cannot see any workspace other than the one it was created for, and
there is no tool for switching. Tokens expire after 90 days, or after 30 days on services:admin.