Skip to main content
Glama
Rootly-AI-Labs

Rootly MCP server

Official

createIncidentActionItem

Generate an action item for a specific incident, including details like summary, priority, status, and assigned users or groups, to track and resolve tasks effectively.

Instructions

Creates a new action item from provided data

Path Parameters:

  • incident_id (Required): No description.

Responses:

  • 201 (Success): incident_action_item created

    • Content-Type: application/vnd.api+json

    • Example:

{
  "key": "value"
}
  • 401: responds with unauthorized for invalid token

    • Content-Type: application/vnd.api+json

    • Example:

{
  "key": "value"
}
  • 422: invalid request

    • Content-Type: application/vnd.api+json

    • Example:

{
  "key": "value"
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes
incident_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The FastMCP.from_openapi call dynamically generates and registers all MCP tools from the filtered OpenAPI specification, including the 'createIncidentActionItem' tool derived from POST /incident_action_items or POST /incidents/{incident_id}/action_items endpoints.
    # By default, all routes become tools which is what we want
    mcp = FastMCP.from_openapi(
        openapi_spec=filtered_spec,
        client=http_client.client,
        name=name,
        timeout=30.0,
        tags={"rootly", "incident-management"},
    )
  • Defines the allowed API paths that are exposed as MCP tools. Includes paths for incident action items (/incident_action_items, /incidents/{incident_id}/action_items) from which the createIncidentActionItem tool is generated.
    DEFAULT_ALLOWED_PATHS = [
        "/incidents/{incident_id}/alerts",
        "/alerts",
        "/alerts/{alert_id}",
        "/severities",
        "/severities/{severity_id}",
        "/teams",
        "/teams/{team_id}",
        "/services",
        "/services/{service_id}",
        "/functionalities",
        "/functionalities/{functionality_id}",
        # Incident types
        "/incident_types",
        "/incident_types/{incident_type_id}",
        # Action items (all, by id, by incident)
        "/incident_action_items",
        "/incident_action_items/{incident_action_item_id}",
        "/incidents/{incident_id}/action_items",
        # Workflows
        "/workflows",
        "/workflows/{workflow_id}",
        # Workflow runs
        "/workflow_runs",
        "/workflow_runs/{workflow_run_id}",
        # Environments
        "/environments",
        "/environments/{environment_id}",
        # Users
        "/users",
        "/users/{user_id}",
        "/users/me",
        # Status pages
        "/status_pages",
        "/status_pages/{status_page_id}",
        # On-call schedules and shifts
        "/schedules",
        "/schedules/{schedule_id}",
        "/schedules/{schedule_id}/shifts",
        "/shifts",
        "/schedule_rotations/{schedule_rotation_id}",
        "/schedule_rotations/{schedule_rotation_id}/schedule_rotation_users",
        "/schedule_rotations/{schedule_rotation_id}/schedule_rotation_active_days",
        # On-call overrides
        "/schedules/{schedule_id}/override_shifts",
        "/override_shifts/{override_shift_id}",
        # On-call shadows and roles
        "/schedules/{schedule_id}/on_call_shadows",
        "/on_call_shadows/{on_call_shadow_id}",
        "/on_call_roles",
        "/on_call_roles/{on_call_role_id}",
    ]
  • The AuthenticatedHTTPXClient.request method handles all HTTP requests for generated MCP tools, including the API call to create an incident action item.
    async def request(self, method: str, url: str, **kwargs):
        """Override request to transform parameters."""
        # Transform query parameters
        if 'params' in kwargs:
            kwargs['params'] = self._transform_params(kwargs['params'])
    
        # Call the underlying client's request method and let it handle everything
        return await self.client.request(method, url, **kwargs)
  • Sanitizes parameter names in the OpenAPI spec to make them MCP-compliant. Called before tool registration to prepare input schemas for all generated tools including createIncidentActionItem.
    def sanitize_parameters_in_spec(spec: Dict[str, Any]) -> Dict[str, str]:
        """
        Sanitize all parameter names in an OpenAPI specification.
        
        This function modifies the spec in-place and builds a mapping 
        of sanitized names to original names.
        
        Args:
            spec: OpenAPI specification dictionary
            
        Returns:
            Dictionary mapping sanitized names to original names
        """
        parameter_mapping = {}
        
        # Sanitize parameters in paths
        if "paths" in spec:
            for path, path_item in spec["paths"].items():
                if not isinstance(path_item, dict):
                    continue
                    
                # Sanitize path-level parameters
                if "parameters" in path_item:
                    for param in path_item["parameters"]:
                        if "name" in param:
                            original_name = param["name"]
                            sanitized_name = sanitize_parameter_name(original_name)
                            if sanitized_name != original_name:
                                logger.debug(f"Sanitized path-level parameter: '{original_name}' -> '{sanitized_name}'")
                                param["name"] = sanitized_name
                                parameter_mapping[sanitized_name] = original_name
                
                # Sanitize operation-level parameters
                for method, operation in path_item.items():
                    if method.lower() not in ["get", "post", "put", "delete", "patch", "options", "head", "trace"]:
                        continue
                    if not isinstance(operation, dict):
                        continue
                        
                    if "parameters" in operation:
                        for param in operation["parameters"]:
                            if "name" in param:
                                original_name = param["name"]
                                sanitized_name = sanitize_parameter_name(original_name)
                                if sanitized_name != original_name:
                                    logger.debug(f"Sanitized operation parameter: '{original_name}' -> '{sanitized_name}'")
                                    param["name"] = sanitized_name
                                    parameter_mapping[sanitized_name] = original_name
        
        # Sanitize parameters in components (OpenAPI 3.0)
        if "components" in spec and "parameters" in spec["components"]:
            for param_name, param_def in spec["components"]["parameters"].items():
                if isinstance(param_def, dict) and "name" in param_def:
                    original_name = param_def["name"]
                    sanitized_name = sanitize_parameter_name(original_name)
                    if sanitized_name != original_name:
                        logger.debug(f"Sanitized component parameter: '{original_name}' -> '{sanitized_name}'")
                        param_def["name"] = sanitized_name
                        parameter_mapping[sanitized_name] = original_name
        
        return parameter_mapping
  • Filters and sanitizes the OpenAPI spec to include only allowed paths and prepare schemas for MCP tool generation.
    filtered_spec = _filter_openapi_spec(swagger_spec, allowed_paths_v1)
    logger.info(f"Filtered spec to {len(filtered_spec.get('paths', {}))} allowed paths")
    
    # Sanitize all parameter names in the filtered spec to be MCP-compliant
    parameter_mapping = sanitize_parameters_in_spec(filtered_spec)
    logger.info(f"Sanitized parameter names for MCP compatibility (mapped {len(parameter_mapping)} parameters)")
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions HTTP responses (201, 401, 422), it doesn't explain key behavioral traits: whether this is a mutation (implied by 'creates' but not explicit), what permissions are needed, if there are rate limits, or how errors are handled beyond status codes. The response examples are generic ('key': 'value'), adding little value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat structured with sections for path parameters and responses, but it's inefficient. The first sentence is clear, but the response details are verbose with generic examples that don't add useful information. It could be more front-loaded and concise by removing redundant examples or integrating key details into the main description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (2 parameters with nested objects, no annotations, but has an output schema), the description is incomplete. It lacks guidance on usage, doesn't explain parameter meanings beyond a bare list, and provides minimal behavioral context. The output schema exists, so return values don't need description, but other gaps make this inadequate for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the input schema provides no parameter descriptions. The description adds minimal value: it lists 'incident_id' as a required path parameter but gives no description, and it doesn't mention the 'data' parameter at all. For a tool with 2 parameters and complex nested objects, this leaves most semantics undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Creates a new action item from provided data'. This specifies the verb ('creates') and resource ('action item'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'createIncident' or 'listIncidentActionItems' beyond the resource name, so it's not a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing incident), when-not-to-use scenarios, or comparisons to sibling tools like 'listIncidentActionItems'. The agent must infer usage from the tool name and parameters alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rootly-AI-Labs/Rootly-MCP-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server