Rock8Cloud is a software factory: build, review, ship and observe on one platform. All of it is operable over MCP (Model Context Protocol), so Claude works against your actual platform instead of a description of it. Add the connector once in Claude Desktop and any Claude chat can deploy a service, read its logs, or hand a task to a cloud agent.
The connector belongs to your Claude account rather than to one machine, so it is there in every Claude window you open.
What you need#
- Claude Desktop or Claude on the web. Custom connectors are added there, not on mobile.
- A Claude plan that includes custom connectors. Settings shows Connectors under Customize when your plan has them.
- A Rock8Cloud account with at least one project. Sign-in happens in the browser during setup.
Add the Rock8Cloud MCP server in Claude Desktop#
Connectors can only be added and authorized on desktop or web. That is the whole setup, and you do it a single time.
- Open Settings → Connectors in Claude Desktop.
- Add custom connector. Name it
Rock8Cloudand paste the server URL:
https://app.rock8.cloud/mcp- Authorize. Claude opens Rock8Cloud in your browser. Sign in, approve the access, and the connector shows as connected. No API key, no token in a config file.
Choose what Claude may do on its own#
Every tool has three settings: automatic, ask, or off. A setup that stays comfortable when you are away from a keyboard:
| Tools | Setting | Why |
|---|---|---|
| Reading projects, services, deployments, uptime, code reviews | Automatic | Answers arrive without a tap. Nothing changes. |
| Build and runtime logs, env var reads | Ask | Log lines can carry data you would rather see before it lands in a chat. |
| Deploy, provision, write env vars, task an agent | Ask | These spend money or change what is running. You approve each one. |
Approvals appear in the conversation, so a phone is enough to grant one.
What you can do once connected#
The tools cover the whole lifecycle, so a chat can carry a change from idea to running service:
- Deploy and ship. Create a project or service, deploy it, follow the build and deployment status, and roll back.
deploy_service,get_deployment_status,get_latest_build. - Read the logs. Build logs and runtime logs per service, so a failure is readable in the conversation rather than in a dashboard you have to reach.
get_build_logs,get_runtime_logs. - Spawn a cloud agent sandbox. Hand a task to an agent that gets its own sandbox and its own copy of the repository. It works on its own and returns a pull request with a preview environment. Follow-up turns go to the same session.
task_agent,continue_agent_session,get_agent_session. - Provision databases and storage. PostgreSQL, Dragonfly (Redis) or S3 storage in one call, then link the credentials into a service as env vars.
provision_postgres,provision_redis,provision_object_storage,link_env_vars. - Pull code review findings. Severity, file locations and a fix prompt for the open branch.
get_code_reviews. - Watch what is live. Uptime, response times and outage history per service.
get_uptime_status.
The full catalog lives on the MCP primitives page, and the per-tool reference is in the MCP integration docs.
What this is good for#
Asking instead of navigating. “What is running in my staging project?” returns live data rather than a guess, and it beats finding the right screen for a question you can phrase in six words.
Planning against facts. Claude has the real state in front of it: current codebase, what is deployed, what broke last night, what the review flagged on the open branch. Brainstorming against your platform beats brainstorming against memory.
Delegating in the chat where you planned it. When the plan is good, task_agent starts a cloud agent on that service with its own sandbox and its own copy of the repo. It comes back as a pull request with a preview environment, not as a merge to production.
Debugging against the evidence. Runtime logs, build logs, deployment status and uptime all read into the conversation, so the fix is discussed next to what actually happened.
Working away from your desk. The connector is on your account, so Claude on your phone has the same tools as Claude on your laptop. Approvals appear in the conversation, which is enough to unblock a deploy from a train. More on that in talk to your codebase from your phone.
The gate does not move. Agents open pull requests, reviews still run, and nothing reaches production because a chat asked nicely.
Troubleshooting#
The connector will not authorize. Check the URL ends in /mcp with no trailing slash. Finish the browser sign-in rather than closing the tab, then return to Claude. Removing and re-adding the connector starts a fresh OAuth exchange.
Claude says it has no tools for this. The tool is set to off, or the conversation started before the connector was added. Reopen the tool permissions and start a new chat.
Claude answers about the wrong project. Ask it to list organizations and projects first. An account with several organizations needs the project named in the question.
Nothing shows up on mobile. Connectors sync with the account, not the device. Confirm the connector is connected on desktop and that both are signed in to the same Claude account.
Claude Code, Codex and other MCP clients#
The connector belongs to the Claude apps. Command line and editor agents point at the same server URL through their own config, so Claude Code, Codex, Cursor and Zed all reach the same tools with the same permissions model.
Next: talk to your codebase from your phone · let your agent delegate work to cloud agents · debug a failing deploy from your agent.