Incident Management Event Log
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_dimension_valuesA | List the exact values available for a filter dimension, with the number of cases carrying each. Call this before filtering: e.g. priority is 'High', not '1 - High'. |
| case_processing_durationB | Aggregate case processing duration (first event to last event) grouped by priority, issue_type and/or report_channel. Returns count, mean and median seconds per group. |
| counter_value_distributionA | Distribution of reassignment_count or reopen_count across cases. Each case contributes its final counter value; rows give value, case count and share. Both counters are derived from the activity sequence, not raw columns. |
| keyword_searchA | BM25 keyword search over incidents. Splits |
| write_incident_reportA | Return a finished markdown incident report for one dimension (priority, issue_type or report_channel) over an optional time window. The server aggregates the data and asks your model to write it up (MCP sampling), so this needs the client's sampling capability; without it, call case_processing_duration and counter_value_distribution and write the report yourself. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| incident_report | Draft a formatted incident report for one dimension (priority, issue_type or report_channel) over an optional time window. The server runs the aggregations and embeds the results in the prompt, so the model writes the report over fixed numbers instead of calling the tools and re-deriving them. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a fairly distinct role: search, list filter values, two different aggregations, and report generation. The only overlap is that write_incident_report internally composes the same kind of aggregations exposed by case_processing_duration and counter_value_distribution, which could make an agent wonder when to use the report tool versus the raw aggregators.
All names use snake_case, but the grammatical pattern is mixed: some are verb-led (write_incident_report, list_dimension_values), one is noun-led (keyword_search), and two are noun phrases without a verb (case_processing_duration, counter_value_distribution). It remains readable, but the set does not follow a predictable verb_noun convention throughout.
Five tools is well within the appropriate range for an incident analytics server. Each tool covers a distinct analysis capability, and none feels like filler.
The set covers search, filter-value discovery, aggregation, and report generation, but it lacks direct incident retrieval (e.g., get incident by ID) and explicit structured filtering by dimension for incident lists. The aggregation tools also do not advertise time-window filtering except through the report tool, leaving notable gaps for incident investigation workflows.