kener-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@kener-mcpcreate an incident for the API outage and post an investigating update"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
kener-mcp
An MCP server for Kener v4 status pages. It lets an AI agent (Claude Code, Claude Desktop, or any MCP client) read monitors and incidents, and create, update, and resolve incidents.
Tested against Kener 4.1.7.
Tools
Tool | What it does | Writes? |
| Lists monitors: tag, name, status, type, category. Monitor config ( | No |
| Lists incidents, newest first. Only open incidents unless | No |
| Gets one incident with its update timeline. | No |
| Creates an incident that starts now. It can attach monitors and post a first update. | Yes |
| Posts an update and sets the state ( | Yes |
| Posts a | Yes |
There is no delete tool. Delete incidents in the Kener dashboard.
The read tools have the MCP readOnlyHint annotation, so clients can allow them without a prompt and still ask before a write.
Related MCP server: mcp-incident-triage-agent
Configuration
One server serves one Kener instance. To use more than one instance, register one server per instance, each with its own URL and key.
Variable | Required | Description |
| Yes | Base URL of the Kener instance, for example |
| One of these two | A Kener API key. Create one in the Kener dashboard under Manage > API Keys. |
| One of these two | A command that prints the API key on stdout, for example |
| No | Seconds to wait for the key command. Default |
| No | A short name for the instance. It is used in the server name and in error messages. |
| No | Extra text for the agent, for example "This page is client-facing; updates also post to the client's Slack." |
The --url, --api-key-cmd, and --name flags override the matching variables. There is no --api-key flag, because process lists show command-line arguments.
API key command
Use KENER_API_KEY_CMD (or --api-key-cmd) to get the key from a secret manager, so that the key is not in your MCP config:
The command runs on the first tool call, not at server start. A slow or locked secret manager does not block the MCP handshake.
The key is kept in memory. If Kener rejects it (HTTP 401), the next tool call runs the command again, so a rotated key is picked up.
The command is split like a shell command line (
shlex) but does not run in a shell. Pipes,$VARS, and~are not expanded. For those, point it at a script.The command must print only the key. If it fails, the error shows its exit code and stderr, never its stdout.
Examples:
# 1Password
KENER_API_KEY_CMD='op read "op://Infra/Kener API key/api_key"'
# macOS Keychain
KENER_API_KEY_CMD='security find-generic-password -s kener -w'
# pass
KENER_API_KEY_CMD='pass show kener/api-key'Install
uv tool install kener-mcpOr run it without installing: uvx kener-mcp. With pip: pip install kener-mcp.
Then check the URL and key:
KENER_URL=https://status.example.com KENER_API_KEY=... kener-mcp checkRegister with Claude Code
claude mcp add kener -s user \
-e KENER_URL=https://status.example.com \
-e KENER_API_KEY=your-key \
-- kener-mcpFor two instances, add two servers:
claude mcp add kener-prod -s user -e KENER_URL=https://status.example.com -e KENER_API_KEY=... -- kener-mcp
claude mcp add kener-staging -s user -e KENER_URL=https://status-staging.example.com -e KENER_API_KEY=... -- kener-mcpWith a key command instead of a stored key:
claude mcp add kener -s user -- kener-mcp \
--url https://status.example.com \
--api-key-cmd 'op read "op://Infra/Kener API key/api_key"'Register with Claude Desktop (or another MCP client)
{
"mcpServers": {
"kener": {
"command": "kener-mcp",
"env": {
"KENER_URL": "https://status.example.com",
"KENER_API_KEY": "your-key"
}
}
}
}Kener API notes
These notes describe Kener 4.1.7 as read from its source:
An update is
POST /api/v4/incidents/{id}/commentswith{"comment": "...", "state": "..."}. The Kener docs showmessageandstatus. The server rejects those names.There is no resolve endpoint. A comment with state
RESOLVEDsets the incident state and its end time.PATCH /api/v4/incidents/{id}cannot change the state.API-created incidents start in state
INVESTIGATING.Updates posted through the API do not email subscribers (rajnandan1/kener#886). Updates made in the dashboard do.
Development
uv sync
uv run pytest
uv run ruff check . && uv run ruff format --check .The tests use respx to check the HTTP request shapes. They call no real Kener instance.
Releasing
Bump the version:
uv version --bump patch(orminor/major).Move the
Unreleasednotes inCHANGELOG.mdunder the new version.Commit, push, and wait for CI to pass.
Publish a GitHub release with the tag
v<version>, for examplegh release create v0.1.1 --generate-notes.
The Release workflow then checks that the tag matches the version in pyproject.toml, runs the tests, builds the package, and publishes it to PyPI with Trusted Publishing.
License
MIT. See LICENSE.
Available Tools
6 toolscreate_incidentCreate IncidentA
Create a public incident, starting now, in state INVESTIGATING. Optionally attach monitors (tags from list_monitors) and post a first update. On Kener 4.1.7 and earlier, updates posted through the API do not email subscribers (rajnandan1/kener#886).
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | State for the first update. | INVESTIGATING |
| title | Yes | Incident title. | |
| impact | No | Impact on each listed monitor. | DOWN |
| first_update | No | Optional first update text. | |
| monitor_tags | No | Monitor tags the incident affects. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
get_incidentGet IncidentARead-only
Get one incident with its update timeline (oldest first).
| Name | Required | Description | Default |
|---|---|---|---|
| incident_id | Yes | Kener incident ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
list_incidentsList IncidentsARead-only
List incidents, newest first. By default only open (not RESOLVED) incidents.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum incidents to return. | |
| include_resolved | No | Also return RESOLVED incidents. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
list_monitorsList MonitorsARead-only
List the monitors on this Kener instance (tag, name, status, type, category).
Use the tags with create_incident.
| Name | Required | Description | Default |
|---|---|---|---|
| include_hidden | No | Include hidden monitors. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
post_incident_updatePost Incident UpdateA
Post a public update on an incident and set its state. The state becomes the incident's current state. To close an incident, use resolve_incident. On Kener 4.1.7 and earlier, updates posted through the API do not email subscribers (rajnandan1/kener#886).
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | New incident state. | |
| comment | Yes | Update text shown on the status page. | |
| incident_id | Yes | Kener incident ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
resolve_incidentResolve IncidentA
Resolve an incident. Kener has no separate resolve call: this posts an update with state RESOLVED, which closes the incident and sets its end time. On Kener 4.1.7 and earlier, updates posted through the API do not email subscribers (rajnandan1/kener#886).
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Closing update text. | This incident has been resolved. |
| incident_id | Yes | Kener incident ID. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
v0.1.0- First observed
create_incident - First observed
get_incident - First observed
list_incidents - First observed
list_monitors - First observed
post_incident_update - First observed
resolve_incident
TDQS
Scored across 6 tools
Most tools target distinct actions (list, get, create, update, resolve), but resolve_incident and post_incident_update overlap since both post updates and set state. The descriptions explicitly clarify ('To close an incident, use resolve_incident'), which mitigates the confusion but the boundary is not fully clean.
All six tools use consistent snake_case verb-first naming (resolve_incident, list_monitors, list_incidents, get_incident, post_incident_update, create_incident). The pattern is predictable and readable throughout.
Six tools is well-scoped for an incident-management server, covering the core read/write lifecycle without redundancy. Each tool earns its place.
Incident lifecycle is well covered (create, list, get, update, resolve), but there is no delete incident and monitors are read-only (only list_monitors, no create/update/delete monitor). Minor gaps an agent can live with, depending on intent.
Maintenance
Related MCP Connectors
Status pages and uptime monitoring: read status, monitors and incidents; open incidents.
Uptime monitoring, status pages and on-call in one place. Create and tune monitors for HTTP, TCP, DNS, ping, TLS certificates, domain expiry, heartbeats and scripted browser logins. Run a check on demand, read uptime and response-time history, acknowledge and resolve incidents, post incident updates, schedule maintenance windows and edit public status pages. Read-only until you grant write access.
Read status-page status, services, incidents and metrics; create, update and publish incidents.
Uptime monitoring and status pages: set up monitors, read incidents, draft status updates.
1
Related MCP Servers
AlicenseCqualityCmaintenanceConnects AI assistants to GetMonitor status pages, monitors, incidents, and maintenance schedules via read-only tools.1003 npmApache 2.0- AlicenseNot gradedqualityDmaintenanceExposes service health and log search tools for incident triage, enabling AI agents to investigate and summarize operational issues.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to check real-time status, uptime, and incidents for 200+ popular APIs (Stripe, OpenAI, AWS, GitHub, Twilio, etc.) through read-only, no-authentication tools.MIT
- AlicenseAqualityCmaintenanceEnables AI agents to check whether anything on a status page is down, open, update and resolve incidents, change component statuses, and schedule maintenance windows through Instatus's public API. Writes keep subscriber notifications off by default and expose MCP annotations so clients can confirm before publishing anything.144 npmMIT