Connect AI Assistants (MCP)
Watasu ships a hosted MCP (Model Context Protocol) server. Connect it to Claude or any MCP-capable client and your assistant can answer questions like “is the deploy green?”, “what failed in the last build?”, or “which add-ons does the billing app have” — directly from live platform state.
https://mcp.watasu.io/mcpThe MCP surface is read-only. An assistant connected through MCP can see app and build state; it cannot deploy, scale, change config, or read your secrets.
Connect a client
Section titled “Connect a client”OAuth (recommended)
Section titled “OAuth (recommended)”Most MCP clients only need the endpoint URL. Add https://mcp.watasu.io/mcp as a remote MCP server and the client walks you through the rest:
- The client registers itself automatically (dynamic client registration).
- Your browser opens a Watasu consent page.
- You choose what the connection can see: all your teams (including ones you join later) or specific teams only.
- The client receives a token and starts reading.
Tokens are short-lived and refresh automatically. You can revoke a connection at any time from the dashboard.
API key
Section titled “API key”For scripted or headless MCP clients, a Watasu API key works directly as a bearer token:
Authorization: Bearer <your-api-key>Create API keys in the dashboard. The key inherits your access — apps you can’t see, the assistant can’t see either — and can itself be scoped to specific teams.
What the assistant can see
Section titled “What the assistant can see”The server exposes read-only resources:
| Resource | What it answers |
|---|---|
watasu://overview | Account-wide summary — teams, apps, live status, latest builds, current issues |
watasu://whoami | What identity and team scope this connection has |
watasu://teams, watasu://teams/{team}/apps | Team and app inventory |
watasu://apps, watasu://apps/status | All accessible apps with health at a glance |
watasu://apps/{app} | One app’s details — URL, current release, latest build |
watasu://apps/{app}/builds, .../builds/{number} | Build history and individual build details |
watasu://apps/{app}/builds/{number}/logs | Build log events for debugging a failed deploy |
watasu://apps/{app}/builds/{number}/raw-output | Raw build output |
watasu://apps/{app}/releases/latest | Latest release status |
watasu://apps/{app}/process-types | The app’s formation — process types and sizes |
watasu://apps/{app}/addons, watasu://addons/{name} | Attached add-ons, plans, and status |
Everything respects your access: team-scoped connections only see their teams, and apps you can’t access return nothing.
What the assistant can’t see or do
Section titled “What the assistant can’t see or do”By design, the MCP surface excludes:
- config var values and secrets — never exposed, redacted or absent entirely
- database credentials and add-on connection details
- billing data
- runtime app logs (build logs only — use
watasu logsor Grafana for runtime logs) - any write operation — no deploys, no scaling, no config changes, no destroys
If you want an assistant that acts on Watasu, give it the CLI in an environment you control. MCP is the safe default for visibility.
Typical uses
Section titled “Typical uses”- “Why did the last deploy of
billing-apifail?” — the assistant reads the build log and tells you - a morning standup summary across every app in a team
- letting a coding agent check that its push actually went live before moving on
- an on-call assistant that triages “is it us or the deploy?” questions
Rate limits
Section titled “Rate limits”OAuth registration and token endpoints are rate-limited per client and IP. If a client hammers them it gets 429 Too Many Requests with a Retry-After header. Normal assistant usage won’t get near the limits.