MCP-driven deploys: 5 tasks your Claude agent should be running for you
Published: May 17, 2026
Category: AI · MCP · Operations
Reading time: 8 minutes
Author: NEXUS AI Team
Most Model Context Protocol servers are read-only. They let your AI agent search a codebase, list GitHub issues, or look up Linear tickets. That is useful. It is also where most agents stop.
NEXUS AI's MCP server is different. It exposes more than 50 write actions covering the full deployment lifecycle: build, deploy, scale, back up, restore, attach storage, query the database, fix schemas, roll back, and delete. Connect it to Claude Code, Cursor, Codex, or any MCP client, and your agent can run your infrastructure on your behalf.
This post walks through five concrete tasks worth handing to your agent today.
If your AI tools have only ever generated code for you, see also Your AI app is generated. Now how do you deploy it? for the full picture of what changes when the agent owns operations.
Setup: connect the NEXUS AI MCP server in 60 seconds
For Claude Desktop, add this to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"nexus-ai": {
"url": "https://nexusai.run/mcp",
"headers": {
"Authorization": "Bearer <your-nexus-token>"
}
}
}
}
For Cursor, add the same server in Cursor Settings → MCP → Add server.
Generate a token at https://nexusai.run/app/tokens. Scopes follow deployments:read|create|delete, db:query|admin, secrets:read|manage, and similar boundaries. Start with read-only scopes if you want to watch the agent before giving it write access.
Restart your AI client. The 50+ NEXUS AI tools appear in its tool list.
Task 1: Deploy from a prompt
The classic case. You have a repository with working code. Tell the agent:
Deploy this repo to NEXUS AI. Use Postgres and Redis. Set the start command to
uvicorn app:app --host 0.0.0.0 --port 8000.
The agent calls:
nexusai_deploy_source
repo: https://github.com/you/my-app.git
framework: python
services: [postgresql, redis]
start_command: "uvicorn app:app --host 0.0.0.0 --port 8000"
Five minutes later the agent reports back with the live URL, the masked database connection string, and the deployment ID. You did not write a Dockerfile. You did not touch a dashboard.
Why hand this over: the agent already has the repository context (it just wrote the code). It knows which framework, which port, which start command. The agent should know all of these without being told.
Task 2: Back up the database before a risky migration
Your agent is about to run a schema migration. The right ops habit is "snapshot first, migrate second, validate third, restore on failure." That used to be three terminals, two Slack messages, and a prayer. Now it is one prompt:
Before running the migration on
my-ai-app, take a Postgres backup. If the migration fails, restore from the backup and roll back the deploy.
The agent runs:
1. nexusai_db_services_list → finds the postgres service id
2. nexusai_db_backup → triggers pg_dump, waits for SUCCESS
3. (runs your migration command)
4. nexusai_deploy_logs → reads runtime logs for errors
5a. (success) nexusai_db_backup_list → confirms backup is on the retention list
5b. (failure) nexusai_db_restore → restores from the backup
nexusai_deploy_rollback → rolls back to the previous release
Why hand this over: the failure path is the part humans forget to do under pressure. The agent always remembers.
Backups land at /var/lib/nexus-backups/<service>/ and are downloadable through nexusai_db_backup_download, which returns a signed URL with a 30 to 3600 second TTL.
Task 3: Diagnose a failing deploy from logs
A deployment is stuck in BUILDING or healthy but throwing 500s. Ask:
What is wrong with
my-ai-appright now? Tail the last 200 log lines, identify the failure, and propose a fix.
The agent runs:
nexusai_deploy_status → status, health, restart count, last error
nexusai_deploy_logs → last 200 lines of build + runtime logs
It reads the actual stack trace, identifies the missing environment variable, the unhealthy upstream, or the failed migration, and replies with a targeted fix. If the fix is a code change, it edits the file in your IDE. If the fix is a secret, it calls nexusai_secrets_create. If the fix is a redeploy, it calls nexusai_deploy_redeploy.
Why hand this over: incident triage is the part of operations that scales worst with team size. An agent in the loop never forgets to check the logs first.
Task 4: Query the database without leaving chat
You want to know how many users signed up this week. You do not want to open psql. Ask:
How many users signed up in the last 7 days on
my-ai-app?
The agent runs:
1. nexusai_db_source_list → resolves your database service
2. nexusai_db_inspect_schema → confirms there is a `users` table with `created_at`
3. nexusai_db_query_preview → returns the SQL it intends to run, you approve
4. nexusai_db_query_execute → runs the read-only query, returns the count
The preview step is the safety net. You see the SQL before it runs. For read-only queries the agent runs in a sandboxed session with a 5-second statement timeout and a row-count cap. For destructive queries the agent uses the AI-powered DDL fix workflow (nexusai_db_propose_fix then nexusai_db_apply_fix), which requires explicit approval.
Why hand this over: most "look at the database" tasks are short, repetitive, and high-friction. Making them a chat message removes the friction.
Task 5: Roll back on incident
A deploy went out at 3pm. Error rates spiked at 3:05. Tell the agent:
Roll back
my-ai-appto the previous release. Snapshot Postgres first in case we need to forward-fix.
The agent runs:
1. nexusai_db_backup → snapshot before the rollback
2. nexusai_deploy_rollback → revert to the previous container image
3. nexusai_deploy_status → confirm RUNNING and healthy
4. nexusai_deploy_logs → tail to verify error rate dropped
Rollback flips back to the previous image with the same database state. If the bug was schema-level you can restore from the backup separately.
Why hand this over: rollbacks under stress are exactly when humans skip the snapshot step.
What you should not hand over yet
A few actions are deliberately gated. The agent can prepare them but cannot fire them without explicit confirmation:
| Action | Why gated |
|---|---|
Delete a deployment (nexusai_deploy_delete) |
Permanent. Tears down containers, networks, volumes. |
Drop or truncate via nexusai_db_query_execute
|
Requires db:admin scope and an explicit confirmation. |
Delete a bucket (nexusai_bucket_delete) |
Removes scoped service account and bucket contents. |
Remove a volume (nexusai_volume_delete) |
Deletes the underlying data. |
| Rotate bucket credentials | Invalidates current keys. Apps must redeploy. |
The platform requires the agent to call a _preview variant first (where available) or to set an explicit confirm: true flag. The agent will pause and ask you before crossing one of these lines.
A minimal Claude system prompt for operations
If you want Claude to behave as a careful operator rather than an enthusiastic deployer, paste this into your project's system instructions:
You are operating a NEXUS AI account via MCP tools. Rules:
1. Read before you write. Always call status/list/inspect tools before
making changes.
2. Snapshot before destructive operations. Always call nexusai_db_backup
before migrations or restores.
3. Show the SQL before running it. Always call nexusai_db_query_preview
before nexusai_db_query_execute.
4. Confirm before deletes. Never call delete tools without an explicit
"yes, delete <resource>" from the user in the same message.
5. Prefer rollback over fix-forward during an incident. Stabilize first,
debug second.
6. Stream logs after every deploy or restart and summarize the first
error you see.
Six lines turn a code-generating agent into an operations partner.
What this changes about your workflow
Once the agent can deploy and operate, three things shift:
Operations cost drops. Tasks that took 5 to 30 minutes (snapshot, deploy, tail logs, rollback) become one prompt. The agent does the boilerplate, you make the decision.
Incident response gets faster. The agent already has context (recent code changes, recent deploys, recent logs). It can triage in seconds instead of minutes.
Experimentation gets cheaper. Standing up a new app, attaching a database, testing an idea, tearing it down: each step is one prompt instead of one ticket.
The agent is no longer a code-completion tool. It is the operator on call.
FAQ
Which MCP clients work with NEXUS AI?
Claude Desktop, Claude Code, Cursor, Codex CLI, Windsurf, Zed AI, and any client that speaks MCP over HTTP or stdio. NEXUS AI publishes a hosted HTTPS endpoint, so any client that can attach a Bearer token works.
Does the agent need the same permissions I have?
No. NEXUS AI tokens are scoped. Start the agent with deployments:read, db:read, logs:read. Promote scopes only when you want it to deploy or modify. Tokens are revocable from the dashboard.
Can two agents operate the same account?
Yes. Each token is independent. Audit log entries record which token took each action, so you can attribute changes to "claude-prod", "cursor-staging", or any other label.
Is there a rate limit on MCP calls?
The platform applies standard API rate limits per token. Heavy reconciliation loops should batch (*_list tools support pagination) instead of polling.
Does the agent see secret values?
No. nexusai_secrets_list returns names and metadata. nexusai_secrets_create accepts values you provide. The platform never returns decrypted secret values over the API or MCP.
What if the agent makes a mistake?
Every action is in the audit log (AuditLog table, exportable from the dashboard). Most actions are reversible: stops have starts, deploys have rollbacks, backups have restores. Deletes are the only one-way door, and the agent will not call delete tools without explicit user confirmation in the same message.
Start free and connect the MCP server in your client of choice. Or ask your agent to do it for you.
Top comments (0)