kener-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KENER_URL | Yes | Base URL of the Kener instance, for example https://status.example.com. | |
| KENER_NAME | No | A short name for the instance. It is used in the server name and in error messages. | |
| KENER_API_KEY | No | A Kener API key. Create one in the Kener dashboard under Manage > API Keys. | |
| KENER_API_KEY_CMD | No | A command that prints the API key on stdout, for example `op read op://Vault/Item/api_key`. | |
| KENER_INSTRUCTIONS | No | Extra text for the agent, for example "This page is client-facing; updates also post to the client's Slack." | |
| KENER_API_KEY_CMD_TIMEOUT | No | Seconds to wait for the key command. Default 30. | 30 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_monitorsA | List the monitors on this Kener instance (tag, name, status, type, category). Use the tags with create_incident. |
| list_incidentsA | List incidents, newest first. By default only open (not RESOLVED) incidents. |
| get_incidentA | Get one incident with its update timeline (oldest first). |
| post_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). |
| resolve_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). |
| create_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). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.