Skip to main content
Glama

Summarize Agent Traces

agent_traces_summary
Read-only

Summary KPIs for agent traces over a time window, for the whole workspace or for ONE agent: trace count, LLM calls, error rate, failed vs errored traces, sessions, total/average cost, token usage, and latency and TTFT percentiles. With group_by="bucket" it also answers the same figures per time bucket, the read behind the console's Drift figure, so "is this agent getting slower or more expensive over the week" is one call.

Scope it with agent to get that agent's own numbers. This is the same read, with the same arguments, that the Rius console's agent page makes, so a number you report here and a number a human reads there are the same number — not two measurements that happen to agree.

Read the Failed traces and Errored traces lines as the two different questions they are, and do not add them together or report one as "errors": a run whose ROOT span errored FAILED, while a run that errored somewhere and then recovered did not. The error rate is errored traces over traces.

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 (e.g. "2026-08-01T00:00:00Z"); overrides the hours-derived value when given. end: optional absolute RFC3339 upper bound; overrides the hours-derived value when given. service: optional service-name filter (traces that involve this service). agent: optional exact agent-name filter, matched against the trace's root span — the same value the root_agent column reports on list_agent_traces, so read a name off a listing rather than guessing one. Agent identity is its own field, not the service name: a run that declares no agent falls back to its service name, so equal root_agent and service are that fallback, not two facts. instance: optional exact agent-instance filter, narrowing to one running copy of agent. filters: optional list of {"field": ..., "op": ..., "values": [...]} clauses, ANDed together and composable with the named parameters above — the same grammar and the same field registry as list_agent_traces, so a slice you listed and the summary of that slice cannot disagree. Call describe_search_catalog before guessing a key; a rejected clause comes back naming itself. group_by: optional; "bucket" adds one row per time bucket under the whole-window figures, with the same definitions and composable with every scope argument above. A trace counts once, whole, in the bucket its first span opened in, so the rows sum to the whole-window figures. Rows are sparse: a bucket no trace opened in has NO row, so never read an absent bucket as zero traces, zero cost or a 0% error rate. bucket: optional grain for group_by="bucket": "minute", "hour" or "day". Omit it and the server picks from the window (minute up to 2h, hour up to 48h, day beyond; day buckets open at UTC midnight, so the first may be partial). A grain that cuts the window into more than 1000 buckets is refused with the count in the message.

Example:

How did my agents do over the last 24 hours?

{ "name": "agent_traces_summary", "arguments": { "hours": 24 } }

How is the planner agent doing this week?

{
    "name": "agent_traces_summary",
    "arguments": { "hours": 168, "agent": "planner" }
}

Is one copy of planner worse than the others?

{
    "name": "agent_traces_summary",
    "arguments": { "agent": "planner", "instance": "inst-planner-01" }
}

Summarize the checkout-agent service this week.

{
    "name": "agent_traces_summary",
    "arguments": { "hours": 168, "service": "checkout-agent" }
}

What do planner's gpt-4o runs cost?

{
    "name": "agent_traces_summary",
    "arguments": {
        "agent": "planner",
        "filters": [{ "field": "model", "op": "eq", "values": ["gpt-4o"] }]
    }
}

Is planner getting slower or more expensive over the week?

{
    "name": "agent_traces_summary",
    "arguments": { "hours": 168, "agent": "planner", "group_by": "bucket" }
}

Summarize traces between two specific dates.

{
    "name": "agent_traces_summary",
    "arguments": { "start": "2026-08-01T00:00:00Z", "end": "2026-08-08T00:00:00Z" }
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNo
agentNo
hoursNo
startNo
bucketNo
filtersNo
serviceNo
group_byNo
instanceNo
workspaceNo

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 already declare readOnlyHint=true, yet the description adds substantial semantics beyond them: failed vs errored traces are defined and must not be summed, error rate is defined as errored/traces, a trace counts whole in its first-span bucket, sparse buckets mean absent is not zero, and buckets over 1000 are refused. It also discloses that this is the identical read the Rius console performs, so figures reconcile.

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 the KPI list and the core routing rule, then per-parameter documentation, then examples — a logical order with almost no filler. It is long, and seven examples plus two separate expository paragraphs on failed/errored semantics push it toward the verbose end, but for a ten-parameter tool with zero schema coverage that 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?

An output schema exists so return values need not be described, yet the description goes further by naming which KPIs are returned and how derived figures are computed. Combined with complete parameter documentation and failure-mode notes (rejected filter clauses, refused grain), an agent has everything needed to call it correctly and interpret the result.

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 does: it documents all ten parameters including defaults (hours=24), override precedence (start/end over hours), the workspace org-name/workspace-name disambiguation form, the agent-vs-service fallback distinction, filters grammar and composition, bucket grain auto-selection thresholds, and the day-bucket UTC-midnight partial-first-bucket caveat.

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+resource (summary KPIs for agent traces) and enumerates exactly what is returned: trace count, LLM calls, error rate, sessions, cost, token usage, latency/TTFT percentiles. It also implicitly distinguishes itself from the sibling list_agent_traces by framing this as the aggregate read of the same population, and explicitly names the console Drift figure it backs.

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 routing conditions: use list_workspaces to discover workspace ids, call describe_search_catalog before guessing a filter key, and read an agent name off list_agent_traces rather than guessing. It also states when to reach for group_by="bucket" (trend questions) versus the flat window figures, plus seven worked scenario examples.

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