MCP server

What it is

The API serves an MCP endpoint at {API_ORIGIN}/api/v1/mcp (Streamable HTTP, stateless, JSON responses). It exposes every operator capability of the REST API as an MCP tool: monitors and their analytics, alerts, incidents, maintenance, locations and mesh, Kubernetes discovery, SLAs, status pages and templates, notification routing and channels, local AI, API keys, audit log, users and SSO mappings.

It is a protocol adapter, not a second implementation. Each tool stands for one REST route, and a tool call is dispatched in process through the same router as a direct API call, carrying the caller's credential. Authentication, tenant isolation, the write gate, the tenant-admin and superadmin gates, validation, secret masking (***) and the audit trail therefore apply exactly as they do for the API. Tool argument schemas are reflected from the request types the handlers decode, so they follow the API automatically.

Connect a client

Settings → MCP in the operator UI shows the endpoint URL and these snippets. Clients that support MCP OAuth open a browser to Probara's consent screen the first time; you sign in (password or SSO), pick a workspace and an access level, and the client receives its own tokens.

claude mcp add --transport http probara https://monitoring.example.com/api/v1/mcp
# then run /mcp in Claude Code and choose Authenticate

{
  "mcpServers": {
    "probara": { "url": "https://monitoring.example.com/api/v1/mcp" }
  }
}

Claude.ai and Claude Desktop: Settings → Connectors → Add custom connector, paste the endpoint URL, then Connect.

claude mcp add --transport http probara https://monitoring.example.com/api/v1/mcp \
  --header "Authorization: Bearer pk_<secret>"

Authentication and access

Sign-in (OAuth 2.1)

The connection acts as you. Roles are resolved from the database on every call, exactly as for a browser session, so a role change or a disabled account takes effect immediately. Admin and superadmin tools work if you have those roles.

Workspace API key

Authorization: Bearer pk_<secret>. The connection acts in the key's one workspace with its read or write scope. As everywhere in the API, keys never pass tenant-admin or superadmin gates, so those tools are not offered.

Browser cookies

Never accepted. The MCP endpoint strips the session cookie before authenticating, so a web page cannot drive MCP with your browser session.

Set PUBLIC_BASE_URL (API origin) and APP_BASE_URL (operator UI origin) in production. Without them the endpoints derive URLs from the request's Host and forwarded headers, which works behind the bundled ingress and UI proxy but leaves the advertised issuer to whatever the proxy forwards.

Tools

tools/list is tailored to the connection: read-only connections see no write tools, API keys see no tenant-admin or superadmin tools, and only superadmins see user and SSO-mapping tools. This is a convenience; the API enforces access on every call regardless. Tools carry MCP annotations (readOnlyHint, destructiveHint, idempotentHint) derived from the route, so clients can ask before running deletes.

describe_monitor_type / list_monitor_types

Return a monitor type's config JSON schema (reflected from the struct its validator decodes), its secret fields, and whether it is an active check. Agents call it before creating or editing a monitor; test_monitor_config then validates a config without saving.

wait_for_alert_events

Listens to the workspace's live alert stream for up to 60 seconds and returns the alert events that arrive, as soon as one does. It stands in for GET /alerts/stream, which as server-sent events cannot be a tool.

Results are the API's JSON as text. API errors come back as tool errors carrying the HTTP status and the API's message, so the agent can correct its arguments. Images come back as image content and file downloads (PDF and CSV reports, the AI label export) as embedded resources. Text over 256 KiB is cut with a note to narrow the call.

Not exposed, with the reason: browser login, refresh, logout and SSO routes (MCP has its own sign-in); first-run bootstrap; telemetry ingest (/otlp/v1/metrics, /push/{token}); the in-cluster discovery collector's config and snapshot routes (/discovery-collectors/…, collector-token authenticated); the retired legacy agent endpoint and alert-policy routes (410); and the OAuth protocol routes themselves.

Resources and prompts

Audit and security

• Every write a tool performs is audited under the real route and action (for example monitor.create), attributed to the signed-in user or the API key, with details.via = "mcp". Authorizing and disconnecting connections are audited as mcp_connection.authorize and mcp_connection.revoke.
• Agent install scripts embed the caller's credential only when it is a workspace API key. Over a sign-in connection they carry no key, so a short-lived personal token is never written onto a host.
• The consent decision accepts only a signed-in browser session from the API's or the UI's own origin; API keys and MCP tokens cannot mint or manage connections.
• Destructive tools are marked destructiveHint; the server's instructions ask the agent to confirm them with you first. Use a read-only connection or a read API key for exploratory agents.

Limitations

• The endpoint is stateless (no MCP sessions), so the server never pushes notifications or list-changed events; wait_for_alert_events is the way to watch alerts.
• Reflected schemas do not mark which body fields are required (only the ones the catalog states); the API's validation error names what is missing.
• Each OAuth connection belongs to one user and one default workspace; there is no organization-wide connection policy and no allow-list of client applications.
• OAuth client registration is open (as the MCP specification expects); unused registrations are pruned after a day.