Why did the deploy fail? Which services run at their limit? Who changed the domain yesterday? Connect Claude, Cursor or VS Code to your workspace and just ask – the assistant answers from the same data as the cockpit, sees only what you allow it to, and every call is in the audit log.
An MCP server offers tools to AI assistants through the Model Context Protocol, the open standard Claude, Cursor, VS Code and other programs use to reach data and actions. Clusterward is such an MCP server for your Kubernetes operations on Scaleway: around 40 tools to look things up – almost everything the cockpit shows – and, if you allow it, 22 tools to act and 17 to change and create. The same roles as in the cockpit decide what an assistant sees and does.
Under Settings → Security you allow AI assistants for the workspace – logs, actions and changing settings each with a switch of their own.
In Claude as a connector with your login, in Claude Code, Cursor or VS Code with the workspace’s address and an API token.
The assistant picks the right tools, reads deploys, logs or checks and answers with a link to the page in the cockpit.
If it is to do something – restart, bring back an earlier version – it asks first. Every call is in the audit log.
Reading is the default, acting a deliberate decision – both with the same rules as in the cockpit.
“Why did the deploy fail?”, “What runs hot?”, “Which sites are down?” – the answer comes from deploy history, logs, usage and uptime checks.
An assistant reads almost everything the cockpit shows – clusters, pods, databases, domains, buckets, pipelines – but only what its role and applications allow. A tool without the right does not even appear.
With “Also let it act”, an assistant starts what the cockpit’s buttons start: deploy, restart, earlier version, a database backup or snapshot now, a restore test, the configuration check, a wildcard certificate, uptime checks – asking every time.
Add it in Claude in the browser, the desktop app or on the phone as a connector, sign in to the cockpit, allow it – no shared key.
One line in the terminal or a JSON entry in the MCP settings, plus an API token explicitly enabled for assistants.
Diagnose a failed deploy, uptime report, capacity review, incident review, backup check, who changed what – the client completes names as you type.
The assistant reads every Help article and the glossary. That way it uses the cockpit’s words and sends you to the right page.
Tool, a summary of the arguments, result and duration – under the token or as “person via Claude”.
Calls over 24 hours, 7 or 30 days, failures and their causes, answer times per tool, who asked and what nobody uses.
With the third switch, “Also let it change configuration”, an assistant changes resources, scaling, image tag, backup and snapshot plans, builds or tenant inputs. Nothing rolls out on its own.
“Create a staging environment for acme”: applications, environments, builds, services, a database for a service, catalog apps or a tenant onboarding – passwords stay in the cockpit.
If the connection may not do something, the assistant names the reason – switch off, read-only connection or a role without the right – and what would have to change.
The assistant combines the tools on its own. A few questions teams ask day to day, and where the answer comes from.
| Question | Where the answer comes from |
|---|---|
| Why did the deploy of payload fail? | Deploy history with the full error text, plus the logs |
| Which services ran into their memory limit today? | Usage and restarts of every service |
| Why does shop.acme.com not answer? | DNS against the load balancer, record, certificate, uptime checks |
| Who changed the payload service yesterday? | Audit log: who, what, when – without the entry’s details |
| Which services have commits not yet live? | Comparison of branch and running version |
| Are our backups running? | Database backups, bucket backups and restore tests |
| Create a staging environment for acme. | With the right to change: a new environment, not rolled out |
Every answer is cut to the fields cleared for its tool – even what the cockpit shows on purpose never reaches the assistant.
No environment variables and secrets, no database connection data, no S3 keys, no chart values.
Nothing that deletes, undeploys, tears down or offboards a customer – the one exception: removing an uptime check.
No users, roles and tokens, no SQL console. An assistant cannot grant itself rights.
Every tool calls the same routes as the cockpit: same rights, same checks, same IP allowlist.
Everything is off per workspace until you switch it on. After that, what an assistant may do follows the role of its token or your own.
| What | Default | How it changes |
|---|---|---|
| AI assistants | off | Settings → Security |
| Service logs | off | a switch of its own |
| Acting | off | switch plus “operate” right |
| Changing settings | off | switch plus consent when connecting |
| Token for assistants | not enabled | tick on the API token |
| Claude connector | read only | “also act” when allowing |
| Connector session | access 1 hour | renews itself, 30 days unused = sign in again |
An assistant works with the rights you set in Security & access – roles, applications, API tokens and the IP allowlist apply unchanged. Its answers come from Logs & monitoring and the deployments of your workspace; every call is evidence for Audit & NIS2.
Claude’s connector calls from Anthropic’s servers. If your workspace sits behind an IP allowlist, their outbound range 160.79.104.0/21 belongs on the list – or you use Claude Code or Claude Desktop with a token, whose calls come from your own machine.
Roles per area, API tokens, mandatory 2FA and the audit log.
Go to SecurityLogs, usage and uptime checks the assistant answers from.
Go to Logs & monitoringDeploy, restart and earlier versions – by assistant too.
Go to DeploymentsYour question isn’t here? Write to us – we usually reply the same working day.
Ask a questionWe connect Claude to a sample workspace, ask about a failed deploy and show the entry in the audit log.
