Rootly MCP server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROOTLY_API_TOKEN | No | Your Rootly API token | |
| ROOTLY_AUTH_HEADER | No | Bearer token for authentication (format: Bearer <YOUR_ROOTLY_API_TOKEN>) |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| listIncidentAlertsD | List incident alerts Path Parameters:
Query Parameters:
Responses:
|
| attachAlertC | Attach alerts to an incident from provided data Path Parameters:
Responses:
|
| listAlertsD | List alerts Query Parameters:
Responses:
|
| createAlertC | Creates a new alert from provided data Responses:
|
| listEnvironmentsD | List environments Query Parameters:
Responses:
|
| createEnvironmentC | Creates a new environment from provided data Responses:
|
| listFunctionalitiesD | List functionalities Query Parameters:
Responses:
|
| createFunctionalityC | Creates a new functionality from provided data Responses:
|
| listWorkflowsC | List workflows Query Parameters:
Responses:
|
| createWorkflowB | Creates a new workflow from provided data Responses:
|
| listIncidentActionItemsC | List incident action items Path Parameters:
Query Parameters:
Responses:
|
| createIncidentActionItemC | Creates a new action item from provided data Path Parameters:
Responses:
|
| listIncident_TypesC | List incident types Query Parameters:
Responses:
|
| createIncidentTypeC | Creates a new incident_type from provided data Responses:
|
| listIncidentsC | List incidents Query Parameters:
Responses:
|
| createIncidentC | Creates a new incident from provided data Responses:
|
| listServicesD | List services Query Parameters:
Responses:
|
| createServiceC | Creates a new service from provided data Responses:
|
| listSeveritiesD | List severities Query Parameters:
Responses:
|
| createSeverityC | Creates a new severity from provided data Responses:
|
| listTeamsD | List teams Query Parameters:
Responses:
|
| createTeamC | Creates a new team from provided data Responses:
|
| listUsersC | List users Query Parameters:
Responses:
|
| getCurrentUserB | Get current user Responses:
|
| list_endpointsA | List all available Rootly API endpoints with their descriptions. |
| search_incidents_paginatedC | Search incidents with enhanced pagination control. This tool provides better pagination handling than the standard API endpoint. |
| get_all_incidents_matchingB | Get all incidents matching a query by automatically fetching multiple pages. This tool automatically handles pagination to fetch multiple pages of results. |
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 27 tools
Most tools are clearly distinct by resource and action, such as createIncident vs listIncidents, with minimal overlap. However, get_all_incidents_matching and search_incidents_paginated both search incidents, potentially causing confusion, and attachAlert vs createAlert have subtle differences that might not be immediately clear from names alone.
The majority of tools follow a consistent verb_noun pattern (e.g., createIncident, listServices), but there are notable deviations like get_all_incidents_matching (snake_case with underscores), list_endpoints (snake_case), and search_incidents_paginated (mixed style). This inconsistency reduces predictability, though the core pattern is still readable.
With 27 tools, the count feels heavy for an incident management domain, especially given some redundancy (e.g., multiple incident search tools). While the domain is broad, the tool set could be more streamlined, as many tools are simple CRUD operations that might be better consolidated or scoped down to avoid overwhelming agents.
The tool set covers a wide range of incident management resources (incidents, alerts, services, teams, etc.) with create and list operations for most, providing good lifecycle coverage. However, there are gaps in update and delete operations for many resources, which could limit agent workflows, though the core create and list functions are well-represented.