Skip to main content
Glama
mackerelio-labs

Mackerel MCP Server

Official

List Traces

list_traces
Read-only

Search and retrieve distributed traces by time range, service, environment, version, latency, or attributes to investigate slow requests and system behavior.

Instructions

Search and retrieve traces from Mackerel for distributed tracing analysis.

šŸ” USE THIS TOOL WHEN USERS:

  • Search for traces within a time range

  • Find slow traces by latency filtering

  • Filter traces by service, environment, or version

  • Investigate distributed system behavior

Filter by latency

list_traces(
  serviceName="my-service",
  from=1700000000,
  to=1700001800,
  minLatencyMillis=100,
  maxLatencyMillis=1000
)

Filter by environment and version

list_traces(
  serviceName="my-service",
  from=1700000000,
  to=1700001800,
  environment="production",
  version="v1.2.3"
)

Search by span name

list_traces(
  serviceName="my-service",
  from=1700000000,
  to=1700001800,
  spanName="HTTP GET /api/users"
)

Pagination and sorting

list_traces(
  serviceName="my-service",
  from=1700000000,
  to=1700001800,
  page=2,
  perPage=50,
  order={ column: "LATENCY", direction: "DESC" }
)

Input Schema

NameRequiredDescriptionDefault
toYesEnd time for trace search (Unix epoch seconds)
fromYesStart time for trace search (Unix epoch seconds)
pageNoPage number (starting from 1). Default is 1
orderNoSort preferences. Default is { column: 'START_AT', direction: 'DESC' }
perPageNoNumber of items per page (1-100). Default is 20
traceIdNoFilter by trace ID (32-digit hexadecimal string)
versionNoVersion. Corresponds to `service.version` in OpenTelemetry semantic conventions
spanNameNoFilter by span name
attributesNoCustom attribute filter conditions
environmentNoEnvironment name. Corresponds to `deployment.environment` or `deployment.environment.name` in OpenTelemetry semantic conventions
serviceNameYesService name. Corresponds to `service.name` in OpenTelemetry semantic conventions
issueFingerprintNoFilter by issue fingerprint
maxLatencyMillisNoMaximum latency in milliseconds
minLatencyMillisNoMinimum latency in milliseconds
serviceNamespaceNoService namespace. Corresponds to `service.namespace` in OpenTelemetry semantic conventions
resourceAttributesNoResource-level attribute filters

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.0

TDQS

A3.6/5.0
Behavior3/5

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful context about distributed tracing analysis and demonstrates filtering and pagination, but it does not disclose return shape, result limits, permissions, or pagination metadata beyond the examples.

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

Conciseness4/5

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

The description is front-loaded with purpose and usage guidance, then provides examples that are useful for a complex 16-parameter tool. The examples are somewhat repetitive, repeating serviceName, from, and to in every block, but the structure remains clear and the content generally earns its place.

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 the rich input schema, read-only annotation, and absence of an output schema, the description covers the main usage contexts and demonstrates key filters and pagination. It is sufficient for common invocation, though it could better explain what traces are returned and when to use get_trace instead.

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 all 16 parameters and nested attribute filters are already documented in the schema. The examples demonstrate common parameter combinations, but they do not add much semantic meaning beyond what the schema provides.

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?

States a specific verb and resource: search and retrieve traces from Mackerel for distributed tracing analysis. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling get_trace tool or clarify list/search vs single-trace retrieval.

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 'USE THIS TOOL WHEN USERS' list gives concrete usage contexts: time-range search, latency filtering, service/environment/version filtering, and distributed system investigation. It does not state when not to use it or name get_trace as the alternative for single-trace lookup.

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