Skip to main content
Glama

List Spans

list_spans
Read-only

List spans across every trace in the workspace (not grouped by trace), as a Markdown table — the cross-trace complement to get_agent_trace's single-trace waterfall. Use it to find spans by kind/session/agent regardless of which trace they landed in, e.g. "every failed tool call this week" or "this session's spans across however many traces it touched".

workspace: optional workspace id, name, or org-name/workspace-name when the same name occurs in two of your orgs (defaults to your default; use list_workspaces to discover them). hours: lookback window in hours (default 24), used for whichever of start/end is not given. start: optional absolute RFC3339 lower bound; overrides the hours-derived value when given. end: optional absolute RFC3339 upper bound; overrides the hours-derived value when given. kind: optional derived semantic span kind: "llm", "tool", "chain", "retriever", "reranker", "agent", "embedding", or "other". A rerank call is "reranker", not "llm", though it names a model. Distinct from each row's own kind column, which is the raw OTLP span kind (SERVER/CLIENT/INTERNAL/...). status: optional span status filter, "Ok", "Error", or "Incomplete". session_id: optional exact match on the span's session id, across every trace in that session. Read one off the session column (reported here, on list_agent_traces and by get_agent_trace) rather than guessing. A span with no session of its own reports its trace id there, so passing a trace id selects that one trace's session-less spans. agent: optional exact agent-name filter — the span's own agent, not a trace-level rollup. Reported back in the agent column, so a listing names the agents it can filter by; a span whose run declared no agent carries its service name there instead. instance: optional exact agent-instance filter, narrowing to one running copy of agent. user_id: optional end-user scope — the exact id, as the user_id column reports it. Here the column is the SPAN's own end user rather than a trace-level rollup, so every row of a scoped listing shows the id it matched on. (On list_agent_traces the same column name is the ROOT span's, which is why a trace row there can match and still read blank. When that happens, this tool is how you find the spans that did carry the user.) anonymous: list the spans carrying no end user instead of one user's. Pass either user_id or anonymous, never both. search: optional case-insensitive contains match on span name, span id, trace id, or session id. error_text: optional free text over the failure itself — the status message and any recorded exception. Finds a failing span by what it said. filters: optional list of {"field": ..., "op": ..., "values": [...]} clauses, ANDed and composable with the named parameters. Promoted columns (status, agent, service, model, span_kind, operation, session_id) are cheap over any window; attr.<key> and resource.<key> reach a customer's own attributes, cost ~10x more, and are accepted only over 31 days or less — narrow with a column first. Ops: eq, ne, in, not_in, gt, gte, lt, lte, exists, not_exists. Call describe_search_catalog before guessing a key. sort_field: optional sort column: "start_time" (default), "duration_ms", "tokens", or "cost". sort_dir: optional sort direction, "asc" or "desc" (default "desc"). limit: max rows (default 50). cursor: opaque page token from a previous call's next-page cursor, to fetch the page after it.

Example:

Show me every errored tool call in the last day.

{ "name": "list_spans", "arguments": { "kind": "tool", "status": "Error" } }

All spans in session user-42-chat-7.

{ "name": "list_spans", "arguments": { "session_id": "user-42-chat-7" } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNo
kindNo
agentNo
hoursNo
limitNo
startNo
cursorNo
searchNo
statusNo
filtersNo
user_idNo
instanceNo
sort_dirNo
anonymousNo
workspaceNo
error_textNo
session_idNo
sort_fieldNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld, but the description adds substantial context beyond them: Markdown-table output shape, the ~10x cost and 31-day cap on attr./resource. filters, the advice to call describe_search_catalog first, and the cross-trace column semantics for session/agent/user_id. This is rich disclosure of behavior annotations cannot carry.

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?

Front-loaded with purpose, then parameters, then worked examples — a clean structure. It is long and occasionally parenthetical (e.g. comparisons back to list_agent_traces), but for an 18-param tool with no schema docs the length is largely earned.

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?

Given 18 parameters, no required fields, an output schema (so return values need not be explained), and only readOnly annotations, the description supplies everything an agent needs to call it correctly, including examples. No material gap remains.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden — and it documents all 18 parameters with defaults, edge cases (start/end override hours), the derived-vs-raw kind distinction, session_id fallback to trace id, and the user_id-vs-anonymous exclusivity. It more than compensates for the empty 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 (list) plus resource (spans) plus scope (across every trace in the workspace, not grouped by trace) and explicitly contrasts itself with get_agent_trace's single-trace waterfall. An agent can distinguish it from every sibling without opening a schema.

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?

Gives explicit when-to-use framing ('find spans by kind/session/agent regardless of which trace they landed in') with two concrete scenarios, and names the alternative tool (get_agent_trace) it complements. Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources