MCP server
Let an AI assistant run your Roar account — connect it in about a minute.
Roar hosts an MCP server, so an assistant — Claude, an editor's AI, your own agent — can do console work for you: create a key, check what you've spent, deploy an app, look at why a build failed.
It can only ever do what you can do, in the projects you can reach. Connecting takes about a minute and there is nothing to install.
https://cloud.roar-ai.com/mcp
You do not need a key. Most assistants sign you in through your browser the first time and remember it. There is nothing to copy, paste or keep safe. A key is only for an agent running unattended — see Unattended agents below.
Claude
Paste the address. Nothing to install; works in the browser and in the desktop app.
Open Settings › Connectors › Add custom connector, and paste the address above. Claude asks you to sign in the first time.
Claude Code, if you work in the terminal:
claude mcp add --transport http roar https://cloud.roar-ai.com/mcp
That command needs the Claude Code CLI, which is a separate install from the desktop app. Having the app does not give you the claude command.
ChatGPT
Open Settings › Connectors › Advanced › Developer mode, then Create. Name it Roar, paste the address, and set authentication to OAuth. ChatGPT then opens our sign-in page for you to approve.
Cursor
Settings › Tools & MCP › New MCP Server, then paste the address.
For a config you want to commit or share with your team, put this in ~/.cursor/mcp.json, or .cursor/mcp.json for a single project:
{
"mcpServers": {
"roar": { "url": "https://cloud.roar-ai.com/mcp" }
}
}
VS Code and Copilot
Command Palette › MCP: Open User Configuration, or create .vscode/mcp.json:
{
"servers": {
"roar": { "type": "http", "url": "https://cloud.roar-ai.com/mcp" }
}
}
VS Code calls the block servers. Everything else calls it mcpServers. Pasting the common shape here fails without telling you why — it is the one config on this page that differs.
OpenCode
Under the mcp key in opencode.json:
{
"mcp": {
"roar": {
"type": "remote",
"url": "https://cloud.roar-ai.com/mcp",
"enabled": true
}
}
}
Anything else
If your tool has a field for an MCP server address, the address on its own is all it needs. If it wants a config file, this is the shape Cline, Windsurf, Continue, JetBrains and most others read:
{
"mcpServers": {
"roar": { "url": "https://cloud.roar-ai.com/mcp" }
}
}
However your tool receives the address, it then asks us what we are, discovers the sign-in, registers itself and opens the approval page. There is nothing else to configure.
What the assistant can do
Tools mirror the management API. An assistant can manage your API keys, read your usage and budgets, and run your apps end to end — deploy one from a repository, choose the region it runs in, give it a database and a domain, set its environment variables, watch a deploy, read its logs, roll it back, and delete it when it is finished with. It can also manage projects and who is in them, schedule jobs, and register webhooks.
Some things are deliberately not offered to an assistant, and the line is about what a person should decide rather than what a key is allowed. Inviting a colleague, topping up credit, editing the rows inside your app's database, restoring a backup and turning prompt logging on or off are all done by a person in the console.
Every tool call goes through the same authorization and ownership checks as the REST API — they are not a parallel implementation, they call it. So an assistant can never do more than the person or key behind it, and it cannot see another workspace's anything.
The tool list is filtered by what you granted: an assistant connected with permission to read usage and nothing else never sees a deploy tool at all, rather than seeing it and failing.
Unattended agents
Sign-in through the browser suits a person at a keyboard. For something that runs on a schedule with nobody there, use an API key instead — send it as Authorization: Bearer roar_live_… alongside the address.
Give it a key that is narrow and expiring. A reporting agent needs usage:read and nothing else; sixty days is usually generous. See Authentication & keys.
If a connector will not finish signing in
The address is on cloud.roar-ai.com, and it has to be — even though api.roar-ai.com reaches the same platform for everything else.
Sign-in is OAuth, and OAuth can only complete on the host you actually typed. Sending it anywhere else means your assistant would sign you in, show you a consent screen, get your approval, and still not be able to call a tool — with the consent screen making it look like the problem is somewhere else entirely.
So we refuse it up front instead. A connector pointed at the wrong host gets 421 and a message naming the right address. If you see that, the fix is the address in the dialog, not your account.