Skip to main content
Glama
brukhabtu

Datadog MCP Server

by brukhabtu

GetUsageApplicationSecurityMonitoring

Retrieve hourly usage metrics for application security monitoring via API. Specify start and end times in ISO-8601 format to access detailed usage data for analysis. Deprecated; use the unified hourly usage API for product families.

Instructions

Get hourly usage for application security . Note: This endpoint has been deprecated. Hourly usage data for all products is now available in the Get hourly usage by product family API

Query Parameters:

  • start_hr (Required): Datetime in ISO-8601 format, UTC, precise to hour: [YYYY-MM-DDThh] for usage beginning at this hour.

  • end_hr: Datetime in ISO-8601 format, UTC, precise to hour: [YYYY-MM-DDThh] for usage ending before this hour.

Responses:

  • 200 (Success): OK

    • Content-Type: application/json;datetime-format=rfc3339

    • Response Properties:

      • data: Response containing Application Security Monitoring usage.

    • Example:

{
  "data": [
    "unknown_type"
  ]
}
  • 400: Bad Request

    • Content-Type: application/json;datetime-format=rfc3339

    • Response Properties:

      • errors: A list of errors.

    • Example:

{
  "errors": [
    "Bad Request"
  ]
}
  • 403: Forbidden - User is not authorized

    • Content-Type: application/json;datetime-format=rfc3339

    • Response Properties:

      • errors: A list of errors.

    • Example:

{
  "errors": [
    "Bad Request"
  ]
}
  • 429: Too many requests

    • Content-Type: application/json;datetime-format=rfc3339

    • Response Properties:

      • errors: A list of errors.

    • Example:

{
  "errors": [
    "Bad Request"
  ]
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_hrNoDatetime in ISO-8601 format, UTC, precise to hour: `[YYYY-MM-DDThh]` for usage ending **before** this hour.
start_hrYesDatetime in ISO-8601 format, UTC, precise to hour: `[YYYY-MM-DDThh]` for usage beginning at this hour.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoResponse containing Application Security Monitoring usage.

Implementation Reference

  • Registers the GetUsageApplicationSecurityMonitoring tool by whitelisting the /api/v2/usage.* GET endpoint (line 109) as an MCP TOOL via FastMCP route maps. This is part of the security filter that exposes only safe read-only Datadog API endpoints.
    def _get_route_filters(self) -> list[RouteMap]:
        """Get route filtering rules for safe observability-focused tools.
    
        Security Model:
        1. DENY ALL destructive operations (POST, PUT, PATCH, DELETE)
        2. ALLOW ONLY specific read-only GET endpoints
        3. DEFAULT DENY everything else
    
        This whitelist approach ensures only safe, read-only operations
        are exposed through the MCP interface.
        """
        # Define safe read-only endpoints for observability workflows
        safe_endpoints = [
            # Metrics and time-series data
            r"^/api/v2/metrics.*",  # Query metrics data
            r"^/api/v2/query/.*",  # Time-series queries
            # Dashboards and visualizations
            r"^/api/v2/dashboards.*",  # Dashboard configurations
            r"^/api/v2/notebooks.*",  # Notebook data
            # Monitoring and alerts
            r"^/api/v2/monitors.*",  # Monitor configurations
            r"^/api/v2/downtime.*",  # Scheduled downtimes
            r"^/api/v2/synthetics.*",  # Synthetic tests
            # Logs and events
            r"^/api/v2/logs/events/search$",  # Search logs
            r"^/api/v2/logs/events$",  # List log events
            r"^/api/v2/logs/config.*",  # Log pipeline configs
            # APM and traces
            r"^/api/v2/apm/.*",  # APM data
            r"^/api/v2/traces/.*",  # Trace data
            r"^/api/v2/spans/.*",  # Span data
            # Infrastructure
            r"^/api/v2/hosts.*",  # Host information
            r"^/api/v2/tags.*",  # Tag management (read)
            r"^/api/v2/usage.*",  # Usage statistics
            # Service management
            r"^/api/v2/services.*",  # Service catalog
            r"^/api/v2/slos.*",  # Service level objectives
            r"^/api/v2/incidents.*",  # Incident management
            # Security and compliance
            r"^/api/v2/security_monitoring.*",  # Security signals
            r"^/api/v2/cloud_workload_security.*",  # CWS data
            # Teams and organization (read-only)
            r"^/api/v2/users.*",  # User information
            r"^/api/v2/roles.*",  # Role information
            r"^/api/v2/teams.*",  # Team structure
            # API metadata
            r"^/api/v2/api_keys$",  # List API keys (no create/delete)
            r"^/api/v2/application_keys$",  # List app keys (no create/delete)
        ]
    
        filters = [
            # SECURITY: Block ALL destructive operations first
            RouteMap(
                methods=["POST", "PUT", "PATCH", "DELETE"], mcp_type=MCPType.EXCLUDE
            ),
        ]
    
        # Add whitelisted read-only endpoints
        filters.extend(
            RouteMap(
                pattern=pattern,
                methods=["GET"],
                mcp_type=MCPType.TOOL,
            )
            for pattern in safe_endpoints
        )
    
        # SECURITY: Default deny everything else
        filters.append(RouteMap(pattern=r".*", mcp_type=MCPType.EXCLUDE))
    
        return filters
  • Creates all MCP tools from Datadog OpenAPI spec using FastMCP.from_openapi, applying the security route_maps that include the usage endpoint. The authenticated httpx client proxies requests to Datadog API.
    self.mcp_server = FastMCP.from_openapi(
        openapi_spec=openapi_spec,
        client=auth_client,
        route_maps=route_maps,
    )
  • Monkey patch for FastMCP OpenAPI parser to ensure proper parameter handling for generated tools like GetUsageApplicationSecurityMonitoring.
    def patch_fastmcp_parameter_parsing() -> None:
        """Patch FastMCP to handle enum parameter locations correctly.
        
        This fixes an incompatibility where FastMCP expects parameter locations
        as strings (e.g., "path", "query") but receives enum objects from the
        OpenAPI spec parser (e.g., <ParameterLocation.PATH: 'path'>).
        """
        try:
            import fastmcp.utilities.openapi as openapi_utils
            
            # Store original function
            original_convert = getattr(openapi_utils.OpenAPIParser, '_convert_to_parameter_location', None)
            
            def patched_convert_to_parameter_location(self, param_in):
                """Patched parameter location converter that handles enum values."""
                # Convert enum to string if needed
                if hasattr(param_in, 'value'):
                    param_in = param_in.value
                elif hasattr(param_in, 'name'):
                    param_in = param_in.name.lower()
                
                # Call original function with string value
                if original_convert:
                    return original_convert(self, param_in)
                else:
                    # Fallback implementation
                    if param_in in ["path", "query", "header", "cookie"]:
                        return param_in
                    return "query"
            
            # Apply the patch
            if hasattr(openapi_utils, 'OpenAPIParser'):
                openapi_utils.OpenAPIParser._convert_to_parameter_location = patched_convert_to_parameter_location
                
        except ImportError:
            # If we can't import the modules, the patch won't work but we'll continue
            pass
    
    
    # Apply patches when module is imported
    patch_fastmcp_parameter_parsing()
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the deprecation status (important behavioral context), includes HTTP response codes (200, 400, 403, 429) with explanations, and describes authentication requirements (403 indicates authorization needs). It doesn't mention rate limits beyond the 429 response, but covers key behavioral aspects for a deprecated API.

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

Conciseness2/5

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

The description is excessively long and poorly structured for an AI agent. It includes detailed HTTP response documentation with examples that belong in an output schema (which exists). The deprecation warning is front-loaded appropriately, but the bulk of the text (response codes, examples, error details) is redundant information that should be in structured fields rather than the description.

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

Completeness4/5

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

Given that an output schema exists (context signals indicate 'Has output schema: true'), the description doesn't need to explain return values. It provides essential context about deprecation and authorization requirements. The description is complete enough for the agent to understand this is a deprecated read operation with time-based filtering, though the excessive response documentation adds noise rather than value.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description repeats the same parameter information verbatim from the schema without adding any additional semantic context. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no additional param info in the description.

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

Purpose3/5

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

The description states 'Get hourly usage for application security' which provides a clear verb ('Get') and resource ('hourly usage for application security'), but it doesn't distinguish this tool from sibling tools like 'GetHourlyUsage' or 'GetUsageLambdaTracedInvocations'. The purpose is understandable but lacks sibling differentiation.

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

Usage Guidelines4/5

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

The description provides explicit guidance by noting that this endpoint is deprecated and pointing to an alternative API ('Get hourly usage by product family API'). This tells the agent when NOT to use this tool and provides a clear alternative. However, it doesn't specify when this deprecated tool might still be appropriate (e.g., for legacy systems).

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/brukhabtu/datadog-mcp'

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