Skip to content
Last9
Book demo

Last9 MCP

Connect your AI agent to production observability data for intelligent debugging and issue resolution.

Last9’s MCP server transforms your development workflow by bringing production observability directly into your IDE. Ask your AI assistant questions like “What’s causing the recent spike in errors?” or “Show me the slowest endpoints from the last hour” and get instant insights with suggested fixes.

What is Model Context Protocol?

MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a universal adapter for AI applications — it provides a standardized way to connect AI models to different data sources and tools.

Using MCP, AI agents in your IDE (Cursor, Windsurf, VS Code, Claude Code) or Claude Desktop can access your observability data in Last9’s Telemetry Data Platform to provide intelligent assistance based on real production context.

Why use Last9 MCP?

Turn production issues into local solutions. The Last9 MCP server brings real-time production context directly to your development environment, enabling AI agents to deliver conversational observability through:

  • Debug with production context: Analyze exceptions, performance issues, and service dependencies using actual production data
  • Suggest intelligent fixes: Get code suggestions based on real observability signals, not just theoretical best practices
  • Eliminate “works on my machine”: Bridge the gap between local development and production reality with agentic dx

Gone are the days of switching between multiple tools to understand production issues. This represents the shift from traditional monitoring to an AI-native approach. Read more in our launch blog post and our thoughts on why your observability stack needs to speak agent.

Example Use Cases

Debug Production Exceptions

"I'm seeing errors in production. Can you help me understand what's happening?"

Agent uses get_exceptions and get_service_performance_details to analyze the issue

Performance Investigation

"My API response times seem slow. What's causing the latency?"

Agent uses get_service_dependency_graph and prometheus_range_query to identify bottlenecks

Trace Waterfall Analysis

"I have a slow trace ID — show me where the time is going."

Agent uses get_trace_waterfall to return a bounded parent/child waterfall with millisecond timing, self-time, and the slowest spans

Compare Slow vs Fast Spans

"What attributes differ between slow and fast requests on checkout-service?"

Agent uses get_trace_attribute_deviations with comparison_mode: latency to rank attribute values that correlate with slow spans

Detect Performance Regressions

"What services regressed in the last hour compared to the previous hour?"

Agent uses get_apm_service_deviations to compare the current window against an equal-duration baseline and return regressions/improvements leaderboards

Log Analysis for Issues

"Find error logs from the user-service in the last 30 minutes"

Agent uses get_logs with service and severity filters to surface relevant logs

Correlate Incidents with Deployments

"We had performance issues around 2pm. Were there any deployments around that time?"

Agent uses get_change_events to check for recent deployments and get_service_performance_details to analyze the correlation

Database Performance Investigation

"Which databases are my services hitting, and what are the slowest PostgreSQL queries in prod right now?"

Agent uses get_databases, get_database_queries, get_database_slow_queries, and get_database_server_metrics to connect database load, slow queries, and exporter-backed server health

Auto-Correcting Typos in Entity Names

"Can you look up last9-apiii logs"

Agent uses did_you_mean to detect the typo and surface the closest match (“last9-api”, 74%), then confirms before fetching logs

did_you_mean in action — agent detects "last9-apiii" as a typo and suggests "last9-api" (74% match)

Prerequisites

Before setting up Last9 MCP, ensure you have:

  • Observability data flowing to Last9 via OpenTelemetry integration
  • One of the supported clients: Claude Code, Cursor, VS Code, Windsurf, Claude.ai / Claude Desktop, Codex CLI, or ChatGPT
  • A Last9 account (any role — no admin access required)

Setup

  1. Find your organization slug

    Your org slug is in your Last9 URL when logged in:

    https://app.last9.io/<org_slug>/...

    For example, if your URL is https://app.last9.io/acme/..., your slug is acme.

  2. Configure your IDE

    No local binary needed — connect directly to Last9’s hosted MCP server. Authentication happens via OAuth — see the IDE-specific steps below to connect and authorize.

    1. Run the following command to add the Last9 MCP server:

      claude mcp add --transport http last9 https://app.last9.io/api/v4/organizations/<org_slug>/mcp

    2. Replace <org_slug> with your organization slug

    3. Type /mcp in Claude Code, select the last9 server, and authenticate

    4. After authorizing, all Last9 tools become available in your session

  3. Verify the connection

    Once configured, your AI agent will have access to Last9 tools. Try asking: “What exceptions occurred in the last hour?” or “Show me the performance summary for my services.”

Using Last9 MCP with OpenAI’s Responses API

If you are building an AI application on top of OpenAI’s Responses API or Agents SDK, you can connect it to Last9’s MCP server to give your agent access to live production data.

from openai import OpenAI


client = OpenAI()


response = client.responses.create(
    model="gpt-4o",
    tools=[
        {
            "type": "mcp",
            "server_label": "last9",
            "server_url": "https://app.last9.io/api/v4/organizations/<org_slug>/mcp",
            "headers": {
                "Authorization": "Bearer <your_api_key>"
            },
        }
    ],
    input="Why is payment-service throwing 500s right now?",
)


print(response.output_text)

Replace <org_slug> with your organization slug and <your_api_key> with an MCP token from Query Tokens (Token Type: Client → Client Type: MCP).

The agent can then call any of Last9’s tools (get_service_performance_details, get_exceptions, get_alerts, etc.) automatically as part of answering the question.

Advanced: Self-hosting the MCP Server

If you need to run the MCP server locally (e.g., for air-gapped environments or custom deployments), use the open-source binary instead.

Install:

# Homebrew (macOS/Linux)
brew tap last9/tap && brew install last9-mcp


# NPM (cross-platform, including Windows)
npm install -g @last9/mcp-server@latest

You can also download platform-specific binaries from GitHub Releases.

Get a Refresh Token (admin required) from API Access.

Configure your IDE using the local binary path and LAST9_REFRESH_TOKEN:

{
  "mcpServers": {
    "last9": {
      "command": "/opt/homebrew/bin/last9-mcp",
      "env": {
        "LAST9_REFRESH_TOKEN": "<your_refresh_token>"
      }
    }
  }
}

For VS Code, wrap in "mcp": { "servers": { ... } } and add "type": "stdio". See the last9-mcp-server README for full configuration options.

Toolsets (optional). By default the server exposes every tool. For automation hosts that only need investigation workflows, set LAST9_TOOLSETS (alias LAST9_MCP_TOOLSETS) or pass --toolsets to limit what appears in tools/list:

{
  "mcpServers": {
    "last9": {
      "command": "/opt/homebrew/bin/last9-mcp",
      "env": {
        "LAST9_REFRESH_TOKEN": "<your_refresh_token>",
        "LAST9_TOOLSETS": "investigate"
      }
    }
  }
}

Valid toolset names: logs, traces, metrics, alerts, dashboards, investigate, and all. The value is comma-separated; unset, empty, or all serves the full surface. Unknown names fail fast at startup. The metrics pack alone does not include list_datasources or did_you_mean — use investigate or combine toolsets when you need those discovery helpers.

Reference resources. Long query manuals for get_logs, get_traces, get_service_logs, and prometheus_range_query are served as MCP resources under last9://reference/* (logjson, tracejson, service_logs, metrics). Tool descriptions carry the critical query-construction rules; clients that need the full DSL reference should fetch these via resources/list and resources/read. Discover org-specific attribute names with get_log_attributes_for_pipeline and get_trace_attributes_for_pipeline — they are no longer injected into tool descriptions.

Available Tools

Your AI agent can now access these Last9 capabilities:

Observability & APM

  1. get_exceptions: Get server-side exceptions over a specified time range. For log-heavy services, the tool may continue to logs via aggregate-then-read: aggregate to isolate the hot logger, then read that logger’s lines with a limit to reach the error text.

    View parameters
    • limit (integer, optional): Maximum number of exceptions to return. Default: 20
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to use lookback_minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to default to current time
    • service_name (string, optional): Filter by service name
    • span_name (string, optional): Name of the span to filter by
    • env (string, optional): Filter by environment

  2. get_service_summary: Get service summary over a given time range. Includes service name, environment, throughput, error rate, and response time. All values are p95 quantiles over the time range.

    View parameters
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Default: end_time_iso - 1 hour
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time
    • env (string, optional): Environment to filter by. Default: ‘prod’

  3. get_service_environments: Get available service environments within a specified time range.

    View parameters
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Default: now - 60 minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time

    Note: Returns an array of environments that can be used with other APM tools. If the array is empty, use an empty string "" for environment parameters.

  4. get_service_performance_details: Get detailed performance metrics for a specific service.

    View parameters
    • service_name (string, required): Service name
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Now - 60 minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time
    • env (string, optional): Environment. Default: ‘prod’

  5. get_service_operations_summary: Get operations summary for a service like HTTP endpoints, database queries, messaging producer, and HTTP client calls.

    View parameters
    • service_name (string, required): Service name
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Now - 60 minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time
    • env (string, optional): Environment. Default: ‘prod’

  6. get_service_dependency_graph: Get service dependency graph showing incoming and outgoing dependencies, including infra. Includes throughput, response times and error rates.

    View parameters
    • service_name (string, optional): Name of the service
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Default: now - 60 minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time
    • env (string, optional): Environment. Default: ‘prod’

  7. get_change_events: Retrieves change events from the last9_change_events Prometheus metric to help correlate deployments and system modifications with performance issues or incidents.

    View parameters
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Defaults to now - lookback_minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Defaults to current time
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • service_name (string, optional): Filter by service name
    • env (string, optional): Environment filter
    • event_name (string, optional): Specific event type filter (use available_event_names to see valid values)

    Returns:

    • available_event_names: List of all available event types that can be used for filtering
    • change_events: Array of timeseries data with metric labels and timestamp-value pairs
    • count: Total number of change events returned
    • time_range: Start and end time of the query window

    Common event types: deployment, config_change, rollback, scale_up/scale_down, restart, upgrade/downgrade, maintenance, backup/restore, health_check, certificate, database

    Best practices:

    1. First call without event_name to get available_event_names
    2. Use exact event name from available_event_names for the event_name parameter
    3. Combine with other filters (service_name, env, time) for precise results

  8. get_apm_service_deviations: Compare APM performance across a current window and an equal-duration baseline. Use for regressions/improvements, incident-vs-prior-period comparisons, and fleet deviation discovery.

    View parameters
    • service_name (string, optional): Omit for fleet scope; provide for one service and its operation correlations
    • env (string, optional): Filter to one deployment environment
    • lookback_minutes (integer, optional): Current window length ending now. Default: 60
    • start_time_iso / end_time_iso (string, optional): Explicit current window
    • baseline_start_time_iso / baseline_end_time_iso (string, optional): Equal-duration baseline window; defaults to the immediately preceding period
    • datasource (string, optional): Select one datasource for the comparison
    • max_services / max_operations (integer, optional): Default: 10, maximum: 10

    Returns: regressions and improvements leaderboards, evidence_quality, Apdex reconciliation, and a terminal outcome. Treat stable, no_data, and unsupported_workload_shape as terminal — answer from the result without automatic follow-up tool calls. V1 supports server-request workloads.

Database Investigation

  1. get_databases: Discover databases observed in trace data across your infrastructure. Returns database type, host, throughput, p95 latency, error rate, and how many services are using each database.

    View parameters
    • env (string, optional): Deployment environment to filter by
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • start_time_iso (string, optional): Start time in RFC3339 format. Overrides lookback_minutes
    • end_time_iso (string, optional): End time in RFC3339 format

    Useful for:

    • Discovering which databases your services are talking to
    • Ranking database backends by throughput, latency, and error rate
    • Identifying shared databases used by many services

  2. get_database_slow_queries: Find the slowest database operations from traces and, when available, slow-query logs. Results are sorted by duration descending.

    View parameters
    • db_system (string, optional): Database system filter such as postgresql, mysql, mongodb, or redis
    • host (string, optional): Database host filter using net_peer_name
    • service_name (string, optional): Calling service name filter
    • env (string, optional): Deployment environment filter
    • min_duration_ms (number, optional): Minimum query duration in milliseconds
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • start_time_iso (string, optional): Start time in RFC3339 format
    • end_time_iso (string, optional): End time in RFC3339 format
    • limit (integer, optional): Maximum number of slow queries to return. Default: 20

    Returns:

    • Query source (trace or log)
    • Trace and span IDs when available
    • Service name, database system, query pattern or statement, duration, status, and timestamp
    • Slow-query metadata from logs such as plan summaries or rows examined when present

  3. get_database_queries: Get the top query patterns for a specific database, aggregated by operation. Helps identify hot, slow, or error-prone query shapes.

    View parameters
    • db_system (string, required): Database system such as postgresql, mysql, mongodb, or redis
    • host (string, optional): Database host filter using net_peer_name
    • env (string, optional): Deployment environment filter
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • start_time_iso (string, optional): Start time in RFC3339 format
    • end_time_iso (string, optional): End time in RFC3339 format
    • sort_by (string, optional): Sort by throughput (default), latency, or errors

    Returns:

    • span_name
    • calls_per_min
    • avg_latency_ms
    • p95_latency_ms
    • error_rate_pct

  4. get_database_server_metrics: Discover server-side database metrics from exporters and query key health signals such as connection utilization, cache hit ratios, replication lag, and throughput.

    View parameters
    • db_system (string, optional): Focus on a specific database type. Supported values: postgresql, mysql, oracle, redis, mongodb, mssql, elasticsearch
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • start_time_iso (string, optional): Start time in RFC3339 format
    • end_time_iso (string, optional): End time in RFC3339 format

    Notes:

    • If db_system is omitted, the tool auto-discovers available exporters
    • Requires database exporters such as postgres_exporter, mysqld_exporter, redis_exporter, or mongodb_exporter to be scraped into Prometheus or Levitate
    • Complements client-side trace data with server-side health metrics

Prometheus Integration

  1. list_datasources: List all available datasources configured for your organization. Use this before Prometheus queries to discover valid datasource names.

    Returns
    • Array of datasource objects, each with:
      • name: datasource identifier to pass via the datasource parameter in Prometheus tools
      • is_default: true for the datasource used when no datasource is specified

  2. prometheus_range_query: Execute Prometheus range queries for metrics over a time period.

    View parameters
    • query (string, required): Range query to execute
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Default: now - 60 minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time

  3. prometheus_instant_query: Execute Prometheus instant queries for metrics at a specific point in time.

    View parameters
    • query (string, required): Instant query to execute
    • time_iso (string, optional): Time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time

  4. prometheus_label_values: Get all label values for a specific label name.

    View parameters
    • match_query (string, required): Valid PromQL filter query
    • label (string, required): Label to get values for
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Default: now - 60 minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time

  5. prometheus_labels: Get all available label names.

    View parameters
    • match_query (string, required): Valid PromQL filter query
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Default: now - 60 minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Default: Current time

Log Management

  1. get_logs: Retrieves filtered log entries by service name and/or severity. Uses advanced v2 logs API with physical index optimization for better performance.

    View parameters
    • service_name (string, required): Name of the target service to get logs for
    • severity (string, optional): Severity level of the logs to get (automatically converted to severity_filters format)
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to use lookback_minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to default to current time
    • limit (integer, optional): Maximum logs to return. Default: 20
    • env (string, optional): Environment filter. Use get_service_environments to get available environments

  2. get_service_logs: Retrieves raw log entries for a specific service with advanced filtering capabilities. Useful for debugging issues, monitoring service behavior, and analyzing specific log patterns.

    View parameters
    • service_name (string, required): Name of the service to get logs for
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • limit (integer, optional): Maximum log entries to return. Default: 20
    • env (string, optional): Environment to filter by. Use get_service_environments to get available environments
    • severity_filters (array, optional): Filter by log severity levels (e.g., ["error", "warn"]). Uses OR logic
    • body_filters (array, optional): Filter by log message content (e.g., ["timeout", "failed"]). Uses OR logic
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS)
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS)

    Filtering behavior:

    • Multiple filter types are combined with AND logic (service AND severity AND body)
    • Each filter array uses OR logic (matches any pattern in the array)

  3. get_drop_rules: Gets drop rules for logs, which determine what logs get filtered out from reaching Last9.

  4. add_drop_rule: Adds a new drop rule to filter out specific logs at Last9 Control Plane

    View parameters
    • name (string, required): Name of the drop rule
    • filters (array, required): List of filter conditions to apply. Each filter has:
      • key (string, required): The key to filter on. Only attributes and resource.attributes keys are supported. For resource attributes, use format: resource.attributes[key_name] and for log attributes, use format: attributes[key_name]. Double quotes in key names must be escaped
      • value (string, required): The value to filter against
      • operator (string, required): The operator used for filtering. Valid values: “equals”, “not_equals”
    • conjunction (string, required): The logical conjunction between filters. Valid values: “and”

  5. get_log_attributes: Returns available log attribute names existing during the specified time window, grouped by category. Useful for discovering what attributes can be used for filtering and querying logs.

    View parameters
    • lookback_minutes (integer, optional): Number of minutes to look back from now for the time window. Default: 15
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to use lookback_minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to default to current time
    • region (string, optional): AWS region to query. Leave empty to use default from configuration

    Returns: Log attributes grouped into two categories:

    • Log Attributes: Standard log fields like service, severity, body, level, etc.
    • Resource Attributes: Resource-related fields prefixed with “resource_” like resource_k8s.pod.name, resource_service.name, etc.

  6. get_log_attributes_for_pipeline: Returns log fields present after applying a pipeline, each with the exact filter_field for get_logs conditions. Scoped to your pipeline — use after a filter stage and before building get_logs queries.

    View parameters
    • logjson_query (array, required): In-progress pipeline (e.g. a ServiceName filter stage)
    • lookback_minutes (integer, optional): Default: 15
    • start_time_iso / end_time_iso (string, optional): RFC3339 time bounds

    Returns: Each entry includes name, filter_field (use directly in get_logs), hint, and optional source/sample_coverage. Body-derived fields (source: body) require a parse stage before filtering.

Traces Management

  1. get_traces: Execute advanced trace queries using JSON pipeline syntax for complex filtering and aggregation. This tool provides powerful querying capabilities for traces using a pipeline-based approach with filters, aggregations, and transformations.

    View parameters
    • tracejson_query (array, required): JSON pipeline query for traces. Fetch the full DSL from the last9://reference/tracejson resource or discover fields with get_trace_attributes_for_pipeline first
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS)
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS)
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • limit (integer, optional): Maximum number of traces to return. Default: 20. Range: 1-100

    Notes:

    • Existence checks use {"$neq": [field, ""]} — $exists and $notnull are not supported
    • aggregate and window_aggregate pipelines run as a single request (not chunked)
    • A 408 response means the window is too wide — narrow the time range and retry

  2. get_service_traces: Retrieve traces from Last9 by trace ID or service name. Get specific traces either by providing a trace ID for a single trace, or by providing a service name to get all traces for that service within a time range.

    View parameters
    • trace_id (string, optional): Specific trace ID to retrieve. Cannot be used with service_name
    • service_name (string, optional): Name of service to get traces for. Cannot be used with trace_id
    • lookback_minutes (integer, optional): Number of minutes to look back from now. Default: 60
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to use lookback_minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to default to current time
    • limit (integer, optional): Maximum number of traces to return. Default: 10. Range: 1-100
    • env (string, optional): Environment filter. Use get_service_environments to get available environments

    Usage rules:

    • Exactly one of trace_id or service_name must be provided (not both, not neither)
    • Time range filtering only applies when using service_name

    Returns trace data including trace IDs, spans, duration, timestamps, and status information.

  3. get_trace_attributes: Identify all available trace attributes within a specified time window for use in filtering and querying. Returns the global tag catalog.

    View parameters
    • lookback_minutes (integer, optional): Number of minutes to look back from now for the time window. Default: 15
    • start_time_iso (string, optional): Start time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to use lookback_minutes
    • end_time_iso (string, optional): End time in ISO format (YYYY-MM-DD HH:MM:SS). Leave empty to default to current time
    • region (string, optional): AWS region to query. Leave empty to use default from configuration

  4. get_trace_attributes_for_pipeline: Returns trace attributes present after applying a pipeline, each with the exact filter_field for get_traces conditions. Scoped to your pipeline — use after a filter stage and before filtering on attribute keys.

    View parameters
    • tracejson_query (array, required): In-progress pipeline (e.g. a ServiceName filter stage)
    • lookback_minutes (integer, optional): Default: 15
    • start_time_iso / end_time_iso (string, optional): RFC3339 time bounds

    Returns: Each entry includes name, semantic_name, type, and filter_field ready to use in get_traces conditions.

  5. get_trace_attribute_values: Fetch distinct values for a single trace attribute. Use after get_trace_attributes or get_trace_attributes_for_pipeline to see what values exist (environments, HTTP methods, team names, etc.).

    View parameters
    • attribute (string, required): Tag name in raw API form (resource_department), filter syntax (resources['department']), or semantic form
    • tracejson_query (array, optional): Pipeline to scope values to a filtered slice of spans; omit for global values
    • lookback_minutes (integer, optional): Default: 15
    • start_time_iso / end_time_iso (string, optional): RFC3339 time bounds

    Returns: Canonical filter_field plus example condition for use in get_traces.

  6. get_trace_waterfall: Retrieve one exact trace as a bounded parent/child waterfall with millisecond timing, interval-correct self-time, slowest spans, and largest self-time contributors. Does not compute a critical path or claim root cause.

    View parameters
    • trace_id (string, required): Exact trace ID
    • environment (string, optional): Exact deployment environment
    • start_time_iso / end_time_iso (string, optional): RFC3339 time bounds
    • lookback_minutes (integer, optional): Default: 4320 (for exact trace lookup)
    • selected_span_id (string, optional): Include attributes, events, and links for this span only
    • max_spans (integer, optional): Default: 500, maximum: 1000

    Returns: An investigation-evidence/v1 envelope with the waterfall under data, plus evidence_quality, truncation warnings, and graph integrity warnings (cycles, orphans, duplicate spans). An empty result has evidence_quality: insufficient — widen the window or verify the trace ID before concluding the trace does not exist.

  7. get_trace_attribute_deviations: Compare attribute-value distributions between two bounded span cohorts and rank supported differences. Use for slow vs fast, error vs non-error, or two equal-duration time windows. Results describe correlation, not cause.

    View parameters
    • comparison_mode (string, required): latency, errors, or time
    • service_name (string, required): Exact service name
    • environment (string, required): Exact deployment.environment value
    • operation (string, optional): Exact operation/span name
    • filters (array, optional): Trace JSON filter conditions — discover valid fields with get_trace_attributes_for_pipeline first
    • candidate_attributes (array, optional): Up to 8 attribute names; omit for bounded auto-discovery
    • latency_threshold_ms (number, required for latency mode): Positive threshold in milliseconds
    • start_time_iso / end_time_iso (string, optional): Target window in RFC3339
    • lookback_minutes (integer, optional): Alternative target lookback ending now. Default: 15, maximum: 15
    • baseline_start_time_iso / baseline_end_time_iso (string, required for time mode): Non-overlapping baseline window equal in duration to the target window
    • minimum_cohort_size (integer, optional): Default: 100, minimum: 20
    • limit (integer, optional): Default: 10, maximum: 10

    Returns: Full-denominator shares, percentage-point deltas, representative trace IDs, and evidence_quality. Requires the trace-analysis capability to be enabled for your tenant.

Alert Management

  1. get_alert_config: Get all configured alert rules from Last9. Supports typed filters and free-text search.

    View parameters and returns

    Optional filters:

    • rule_id, search_term, rule_name, severity, rule_type (static or anomaly)
    • alert_group_name, alert_group_type, data_source_name, tags
    • only_without_notification_channel: Rules whose alert group has no per-entity channel binding (Alert Studio “Not configured”)
    • notification_channel_types: Rules with a per-entity channel of any listed type (e.g. slack, email, pagerduty)
    • notification_channel_names: Rules with a per-entity channel matching any listed name (AND-combined with other notification_channel_* filters on the same binding row)
    • notification_channel_severities: Rules with a per-entity channel matching any listed severity (breach or threat)

    Returns per rule:

    • Alert rule ID, name, primary indicator, entity ID, state, severity, algorithm
    • Alert group name, data_source, and tags when resolved
    • Notification Channels: configured types in dashboard order, or “Not configured”
    • Notification Channel Bindings: each binding row (type, name, severity) with snooze/in_use flags
    • Timestamps for creation/updates

  2. get_alerts: Get currently active alerts from the Last9 monitoring system.

    View parameters and returns

    Parameters:

    • timestamp (integer, optional): Unix timestamp. Default: current time
    • window (integer, optional): Time window in seconds. Default: 900 seconds, range: 60-3600

    Returns:

    • Alert rule details
    • Alert state and severity
    • Firing timestamps
    • Rule configurations
    • Metric degradation information
    • Group labels and annotations

  3. get_notification_channels: Get all notification channel configurations from Last9.

    Returns Returns all notification channels as a table with the following columns:

    • id, name, type
    • service_fqid: per-entity alert-group binding ID
    • global: whether the channel applies to all services
    • in_use: whether the channel is actively used in an alert rule
    • send_resolved: whether resolved alerts trigger a notification (true / false / null if not set)
    • snoozed_until: UTC timestamp if the channel is snoozed, - otherwise
    • severity, priority
    • services: comma-separated namespace/name pairs, - if the channel is global

  4. get_alert_rule_state: Get historical firing state (1/0) per alert rule over a time range, grouped by rule_id.

    View parameters
    • start_time (integer, required): Unix epoch start of the range (inclusive)
    • end_time (integer, required): Unix epoch end of the range (inclusive)
    • step (integer, required): Resolution in seconds between samples
    • alert_group_id (string, optional): Filter by alert group ID
    • rule_name (string, optional): Regex filter on rule name
    • alert_group_name (string, optional): Regex filter on alert group name
    • label_filters (string, optional): Comma-separated key=value label filters
    • state (string, optional): Filter by state (e.g. firing)

    Returns: JSON map of rule_id → [{timestamp, is_firing}]. Sample count is capped at 100.

Custom Dashboards

  1. list_dashboards: List all custom dashboards in your Last9 organization.

    Returns
    • JSON array of dashboard summaries: id, name, and metadata
    • reference_url in MCP metadata linking to the dashboards index in the Last9 UI

  2. get_dashboard: Get the full definition of a custom dashboard by ID.

    View parameters and returns

    Parameters:

    • id (string, required): Dashboard UUID
    • region (string, optional): Region for panel query population. Defaults to configured datasource region

    Returns:

    • Full dashboard JSON including name, panels[], and metadata
    • Each panel includes layout, visualization.type, and queries[]
    • reference_url in MCP metadata linking directly to the dashboard

  3. create_dashboard: Create a new custom dashboard with panels and queries.

    View parameters
    • dashboard (object, required): Dashboard definition with name and panels[]. Each panel requires name, version, layout (x, y, w, h), visualization.type, and queries[]
    • metadata (object, optional): Dashboard metadata — _category and _type fields (e.g. {"_category":"custom","_type":"metrics"})

    Returns the created dashboard JSON with its assigned id and a reference_url to open it in the Last9 UI.

  4. update_dashboard: Update an existing custom dashboard by ID.

    View parameters
    • id (string, required): Dashboard UUID to update
    • dashboard (object, required): Full replacement dashboard body (same shape as create_dashboard)
    • metadata (object, optional): Replacement metadata

    Readonly system dashboards return a 403 error. Returns updated dashboard JSON with reference_url.

  5. delete_dashboard: Delete a custom dashboard by ID.

    View parameters
    • id (string, required): Dashboard UUID to delete

    Readonly system dashboards cannot be deleted. Returns a reference_url to the dashboards index.

  6. list_dashboard_snapshots: List frozen point-in-time snapshots for a dashboard.

    View parameters
    • dashboard_id (string, required): Dashboard UUID

    Returns: Snapshot metadata (id, name, expires_at). Use get_dashboard_snapshot for full panel data.

  7. get_dashboard_snapshot: Get a frozen dashboard snapshot by ID, including panel data at capture time.

    View parameters
    • id (string, required): Snapshot UUID

    Returns: Full frozen snapshot with dashboard_definition, panel_data, time_range, and variables.

  8. delete_dashboard_snapshot: Delete a frozen dashboard snapshot by ID.

    View parameters
    • id (string, required): Snapshot UUID to delete

Entity Discovery

  1. did_you_mean: Suggests correct entity names when you’re unsure of the exact spelling. Use this proactively before querying with a name that might be a typo, abbreviation, or partial match.

    View parameters
    • query (string, required): The name to search for — can be a partial name, misspelling, or abbreviation
    • type (string, optional): Restrict suggestions to a specific entity type. Supported values: service, environment, host, database, k8s_deployment, k8s_namespace, job

    Returns up to 3 closest matches with similarity scores (0–100%) from the Last9 catalog, covering services, environments, hosts, databases, Kubernetes workloads, and more.

    When to use:

    • Before calling get_service_logs, get_service_traces, get_service_performance_details, etc. with a service name that might be misspelled (e.g. "paymnt-svc", "prod-srvice")
    • When a previous tool call returned empty results for a given entity name
    • When the user provides an ambiguous or abbreviated name (e.g. "the payment thing" or "prod env")

    Example results:

    • query="paymnt-svc" → payment-service (92%, service)
    • query="prod" → production (89%, environment), prod-eu (82%, environment)

Demos

  1. Fixing a recent exception

  2. Optimizing logs for a service

  3. Creating an RCA basis recent issues in the production environment

  4. Analyze background worker processes

Best Practices

  • Start broad, then narrow: Ask about overall service health before diving into specific issues
  • Include time context: Specify time ranges when investigating issues (“in the last hour”, “during the outage yesterday”)
  • Combine tools: The agent can correlate data across metrics, logs, traces, and alerts for comprehensive analysis
  • Discover attributes before filtering: Use get_log_attributes_for_pipeline and get_trace_attributes_for_pipeline to find valid field names for your scope before building log or trace queries
  • Use trace investigation tools for deep dives: get_trace_waterfall for single-trace timing analysis; get_trace_attribute_deviations to compare slow vs fast or error vs non-error cohorts
  • Pin toolsets for automation: Set LAST9_TOOLSETS=investigate on self-hosted deployments when your agent only needs logs, traces, and metrics — this keeps tools/list small and reduces description token cost

Troubleshooting

  • “Last9 tools not available”: Verify your IDE configuration and restart the application
  • OAuth flow not completing: Ensure you are logged in to app.last9.io before authorizing. If redirected to a 404, try logging in to the dashboard first and then re-initiating the OAuth flow from your IDE
  • “Authentication failed” or “401 Unauthorized” (Claude Desktop): Ensure your token is a valid Refresh Token from API Access
  • “No data returned”: Ensure your services are sending telemetry to Last9 and try broader time ranges
  • “Connection issues”: Double-check:
    • Your org slug is correct (it’s in your Last9 URL: app.last9.io/<org_slug>/...)
    • The URL format: https://app.last9.io/api/v4/organizations/<org_slug>/mcp

Please get in touch with us on Discord or Email if you have any questions.