Incident Triage MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUDIT_MODE | No | Audit log destination: 'stdout' or 'file' | |
| EVIDENCE_DIR | No | Local directory for evidence when EVIDENCE_BACKEND='fs' | |
| MCP_TRANSPORT | No | Transport mode: 'stdio' or 'streamable-http' | |
| AIRFLOW_BASE_URL | No | Base URL for Airflow (required when WORKFLOW_BACKEND='airflow' or EVIDENCE_BACKEND='airflow') | |
| EVIDENCE_BACKEND | No | Evidence backend: 'none', 'fs', 's3', or 'airflow' | |
| MCP_HTTP_API_KEY | No | API key for HTTP auth when MCP_HTTP_AUTH_MODE='api_key' | |
| WORKFLOW_BACKEND | No | Workflow backend: 'none' or 'airflow' | |
| DEPLOYMENT_PROFILE | No | Deployment profile: 'local', 'staging', or 'prod' | |
| MCP_HTTP_AUTH_MODE | No | HTTP auth mode: 'none', 'api_key', or 'jwt_hs256' |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| incident_triage_runC | One-call triage orchestration. Airflow trigger is optional and backend-dependent. |
| alerts_fetch_activeD | – |
| service_health_snapshotD | – |
| logs_fetch_recentD | – |
| traces_fetch_recentD | – |
| runbooks_searchD | – |
| pingD | – |
| mcp_healthD | – |
| mcp_metricsD | – |
| mcp_traces_recentD | – |
| notify_post_updateC | Provider-agnostic notification entrypoint. Routes to Slack or Teams based on provider/env defaults. |
| slack_post_updateB | Post an incident update to Slack via Incoming Webhook. Safe-by-default: dry_run=True returns payload without sending. |
| teams_post_updateC | Post an incident update to Microsoft Teams via Incoming Webhook. Safe-by-default: dry_run=True returns payload without sending. |
| evidence_get_bundleD | – |
| evidence_wait_for_bundleD | – |
| evidence_seed_sampleC | Offline helper: writes a deterministic Evidence Bundle v1 JSON to EVIDENCE_DIR. |
| incident_triage_summaryB | Deterministic (non-LLM) summary of an incident from the Evidence Bundle. |
| jira_draft_ticketD | – |
| jira_create_ticketB | Safe action:
|
| jira_list_projectsD | – |
| jira_list_issue_typesD | – |
| jira_validate_credentialsD | – |
| jira_add_commentA | Add a comment to an existing Jira/ServiceNow ticket. Safe-by-default: dry_run=True returns the comment body without posting. |
| jira_transition_issueA | Transition an existing Jira/ServiceNow ticket to a new workflow state. Safe-by-default: dry_run=True returns the intended transition without applying it. Common transition_name values: 'In Progress', 'Resolved', 'Done', 'Closed'. |
| pd_acknowledge_alertA | Acknowledge a PagerDuty incident via the PagerDuty REST API. Safe-by-default: dry_run=True returns the intended action without sending. Requires PAGERDUTY_API_TOKEN and PAGERDUTY_FROM_EMAIL env vars. |
| pd_resolve_alertB | Resolve a PagerDuty incident via the PagerDuty REST API. Safe-by-default: dry_run=True returns the intended action without sending. Requires PAGERDUTY_API_TOKEN and PAGERDUTY_FROM_EMAIL env vars. |
| opsgenie_acknowledge_alertA | Acknowledge an OpsGenie alert via the OpsGenie REST API. Safe-by-default: dry_run=True returns the intended action without sending. Requires OPSGENIE_API_KEY env var. |
| opsgenie_close_alertA | Close an OpsGenie alert via the OpsGenie REST API. Safe-by-default: dry_run=True returns the intended action without sending. Requires OPSGENIE_API_KEY env var. |
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 28 tools
Most tools target distinct services (Jira, PagerDuty, OpsGenie, Slack, Teams, etc.) and actions. However, notify_post_update abstracts Slack/Teams and may overlap with the specific slack_post_update and teams_post_update, causing potential confusion.
Naming is generally noun_verb-based but inconsistent: 'alerts_fetch_active' (noun_verb_adj), 'incident_triage_run' (noun_noun_verb), 'mcp_health' (noun_noun), and 'ping' (single word) break the pattern. Variations in verb placement and mix of nouns reduce consistency.
28 tools is high but reasonable for an incident triage system covering alerts, evidence, Jira, notifications, monitoring integrations, and health checks. Each tool serves a distinct function, though a few could be consolidated (e.g., notify_post_update vs. slack/teams).
The tool set covers core incident triage workflows: alert fetching, evidence management, triage orchestration, Jira integration, notifications, and alert acknowledgment. Missing are incident listing/updating and more advanced alert lifecycle operations (e.g., list alerts, create/acknowledge beyond existing).