Skip to main content
Glama
initMAX

Zabbix MCP Server

apmtrace_get

Read-only

Retrieve OpenTelemetry APM traces from Zabbix by time range, trace ID, attributes, or duration; filter, sort, and page root-span records for trace analysis.

Instructions

Retrieve OpenTelemetry (OTel) APM traces (Zabbix 8.0+): one record per trace, described by its root span (service_name, span_name, duration in nanoseconds, status_code, span_count, resource and span attributes). time_from and time_till are required and bound the root span start. Filter by traceids, resource_attributes / span_attributes conditions, or min_duration / max_duration. Page with limit and offset. Use apmspan_get for the spans of a trace and apmlog_get for its log records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of records to return.
filterNoReturn only results whose properties exactly match the given values (a single value or a list of values per key). Example: {"status": 0} or {"status": [0, 1]}. Keys: duration, error_count, events, links, resource_attributes, scope_name, scope_version, service_name, span_attributes, span_count, span_kind, span_name, spanid, status_code, status_message, timestamp, trace_state, traceid. Text properties cannot be filtered; use 'search' for them.
offsetNoNumber of records to skip before returning the result (paging).
outputNoProperties of the apmtrace object to return. Pass 'extend' for all, 'count' for the number of matches only, or a comma-separated list of property names. Default when omitted: timestamp, traceid, service_name, span_name, duration, status_code, span_count. Properties: duration, error_count, events, links, resource_attributes, scope_name, scope_version, service_name, span_attributes, span_count, span_kind, span_name, spanid, status_code, status_message, timestamp, trace_state, traceid.
searchNoReturn results whose string properties contain the given pattern (case-insensitive; '*' is a wildcard when searchWildcardsEnabled is true). Example: {"name": "web"}. Keys: scope_name, scope_version, service_name, span_kind, span_name, spanid, status_code, status_message, trace_state, traceid.
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
raw_jsonNoStrips the security disclaimer preamble from the response so it is pure JSON. Default: false. Requires the bearer token to have 'allow_raw_json' explicitly enabled by an operator in the admin portal - tokens without that policy receive a PolicyError instead. WARNING: setting true bypasses the prompt-injection mitigation marker that wraps untrusted Zabbix data (host names, item descriptions, problem text). LLM clients (Claude, GPT, Cursor, ...) should leave this false; only programmatic non-LLM consumers (Python scripts, n8n workflows that json.loads the result) should set true.
traceidsNoReturn only traces with the given IDs.
sortfieldNoSort by one or more of: timestamp, traceid, spanid, trace_state, span_name, span_kind, service_name, scope_name, scope_version, duration, status_code, status_message (comma-separated for several; pair with 'sortorder'). No other property is sortable.
sortorderNoSort order: 'ASC' or 'DESC'.
time_fromYesReturn only traces whose root span started at or after this time (required). Unix timestamp, ISO 8601 date-time or a relative time such as now-1h or now-1d/d.
time_tillYesReturn only traces whose root span started before this time (required). Unix timestamp, ISO 8601 date-time or a relative time such as now or now/d.
extra_paramsNoOther native apmtrace.get parameters, merged into the request as-is. apmtrace.get has no parameters beyond the typed ones. Any other key is refused here, because Zabbix would silently ignore it. For a parameter you are sure exists on your release but is not listed, use zabbix_raw_api_call.
max_durationNoReturn only traces whose root span lasted less than this many nanoseconds.
min_durationNoReturn only traces whose root span lasted at least this many nanoseconds.
span_attributesNoSpan attributes: Attribute conditions as a list of {"key": ..., "value": ..., "operator": ...} objects; operators: 0 Contains, 1 Equals, 2 Not like, 3 Not equal, 4 Exists, 5 Does not exist. An empty list returns everything.
resource_attributesNoResource attributes: Attribute conditions as a list of {"key": ..., "value": ..., "operator": ...} objects; operators: 0 Contains, 1 Equals, 2 Not like, 3 Not equal, 4 Exists, 5 Does not exist. An empty list returns everything.
span_attributes_evaltypeNoHow the conditions in span_attributes combine: 0 = And/Or (default), 2 = Or.
resource_attributes_evaltypeNoHow the conditions in resource_attributes combine: 0 = And/Or (default), 2 = Or.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.41.0

TDQS

A4.5/5.0
Behavior4/5

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

With readOnlyHint=true already covering the safety profile, the description adds the key behavioral constraints: time_from/time_till are required and bound root span start, duration is in nanoseconds, and pagination uses limit/offset. It does not mention the raw_json policy or rate/auth nuances, but the data-model context is genuinely useful.

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

Conciseness5/5

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

Dense but front-loaded: identity of the record comes first, then required time params, then filtering and paging, then sibling routing. Every sentence carries distinct information with no filler.

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

Completeness5/5

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

An output schema exists, so return values need not be spelled out, and the description still names the returned fields at a high level. For a 19-parameter read tool it covers the required params, filtering model, and cross-tool routing adequately.

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 every parameter is already documented in the schema; this sets the baseline at 3. The description summarizes which knobs exist (traceids, attribute conditions, min/max_duration, paging) but adds no syntax or format detail beyond the schema.

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

Purpose5/5

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

States a specific verb (Retrieve) and resource (OpenTelemetry APM traces), and clarifies the record granularity: one record per trace, described by its root span. It disambiguates from siblings by naming apmspan_get and apmlog_get with their distinct scopes.

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

Usage Guidelines5/5

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

Explicitly routes the agent: use apmspan_get for the spans of a trace and apmlog_get for its log records, while this tool returns trace-level records. It also enumerates the filtering avenues (traceids, attribute conditions, duration bounds) so the agent knows how to narrow results.

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