Skip to main content

MCP server for AI agents

Wakora exposes the workspace to AI agents through a Model Context Protocol server at https://mcp.wakora.io. An assistant with the token can list what is on fire, read the metric or the log lines behind an incident, pull the trace of a slow request, and, if you let it, acknowledge the incident or open a maintenance window. Every call is audited, and actions show up in the timeline as performed by "AI", never as you.

Available on the Business plan and above; see the pricing page.

Connecting a client​

  1. In the console, Settings, AI agents, mint a token. Pick the scope: read (observe only), act (acknowledge, resolve, maintenance, Jira, test runs) or admin (rules, APM sites). The token starts with wkm_ and is shown once.
  2. Point the client at the server with the token as a bearer header. For Cursor or Claude Desktop that is an entry in the MCP configuration file:
{
  "mcpServers": {
    "wakora": {
      "url": "https://mcp.wakora.io",
      "headers": { "Authorization": "Bearer wkm_..." }
    }
  }
}

The console shows this snippet ready to paste. The server speaks MCP over streamable HTTP, stateless, one JSON-RPC request per call, so it works with any client that supports remote HTTP servers; there is no long-lived stream to keep open. After adding the server, restart the client so it fetches the tool list.

Tools​

Tools mirror the REST API and follow the same nesting of scopes. A tool above the token's scope is still listed but answers an error naming the scope it needs, so an assistant can explain what it cannot do instead of failing silently.

Read

ToolWhat it answers
list_hosts, host_overview, host_detail, host_inventory, host_checks, host_uptimethe fleet and one host's meters, services, sites, inventory, checks, uptime
query_metrics, list_metric_namesa metric series (exact name) and the names a host produces
list_events, list_insightsthe event feed and insights (N+1, disk forecasts, deployment audits)
list_incidents, get_incidentincidents by state and one incident with its timeline and the runbooks that apply to it
apm_services, apm_red, apm_nplusone, get_traceAPM summary, per-endpoint RED, N+1 findings, one trace as a waterfall
search_logsfull-text log search with host, service and level filters
security_overview, security_cvepatches, SSH doors, integrity, hardening score, matched CVEs
list_rules, list_maintenance, usagethe armed rule catalog with overrides, maintenance windows, billing axes
list_definitions, list_market_templates, list_fleet_rolloutthe signed definition catalog, marketplace templates, rollout rings
list_txn_flows, list_slos, list_deliverabilitytransaction flows, SLA objectives with budgets, e-mail deliverability
list_auditthe audit chain (admin scope)

Act

ToolWhat it does
ack_incident, resolve_incidentacknowledge or resolve by incident number; attributed as AI
open_maintenanceopen a maintenance window for the workspace or one host
create_jira_issuecreate the Jira issue for an incident (Jira must be connected)
test_txn_flowrun a transaction flow once and return the step trace

Admin

ToolWhat it does
save_rule, reset_ruletune a rule or create a custom one; reset an override
enable_apm_site, disable_apm_siteswitch APM on or off for a site, quota rules included

What the assistant does not get​

Nothing the REST API does not give a human either. Credential values, visitor IP addresses and the raw command lines of processes never appear in any answer. Metric queries need an exact metric name; list_metric_names exists precisely so the assistant can discover them instead of guessing. Historical windows are clamped to the plan's retention.

Auditing​

Every tool call, read or write, is written to the workspace audit log with the token that made it. Acknowledgements and resolutions performed through MCP are attributed to "AI" in the incident timeline and in notifications, so a team always knows when an assistant, rather than a colleague, took an incident.