Skip to main content
Glama

session_stats

Summarize and rank coding agent sessions by agent, project, date, type, or model for a birds-eye audit view. Get session counts, edits, intents, and token usage in one call.

Instructions

Summarise sessions, grouped and ranked — the bird's-eye audit view.

Where find_file_edits / find_tool_calls return flat record streams, this rolls the sessions themselves up by one dimension so you can see how the work is distributed in a single call.

group_by is one of:

  • "agent" (default) — claude vs codex vs opencode vs ...

  • "dir" — by working directory / project (the normalized project_dir first — one real directory = one bucket across agents — then cwd for codex/pi / project slug for claude; "(unknown)" for agents without any signal).

  • "date" — by calendar day (YYYY-MM-DD).

  • "kind" — top-level agent sessions vs spawned subagent sessions.

  • "model" — by the model that produced the session. A session that mixed models buckets as "(mixed)" rather than being attributed to one of them; one whose transcript records no model is "(unknown)". Neither is guessed. Pair with with_tokens=True to see what each model actually cost.

Each group carries its session count plus enrichment from the shared find_file_edits core: edits (file edits attributed to the group's sessions), intents (distinct requests behind those edits), the distinct agents in the group, and total messages.

RISK-4 note: subagent detection is currently Claude-only. When no subagent sessions are in scope, a group_by="kind" result shows a single agent bucket — so the result always carries kind_split_available (False here) plus a note making clear that this is NOT a verified "no subagents", just an absent split.

with_tokens=True (F3.3) additionally reads every matched session's token usage at request time (nothing runs in the background) and adds a folded tokens block to each group and to totals: {input, output, reasoning, cache_read, cache_write, total, exact, estimated, unknown}. Per session the numbers are exact where the agent's own files record usage (Claude message.usage, Codex token_count, OpenCode message.data.tokens, Pi usage); a session without a recorded signal (e.g. Antigravity) gets a transcript-volume estimate — tokenized with the optional tiktoken dependency (pip install "ai-r[tokens]") when installed, else a rough chars/4 heuristic — and counts under estimated, never silently mixed in as exact; no signal at all counts under unknown. Sums that no session carried stay null (never a fabricated 0). The block contains only ai-r-computed integers and labels — no raw session text — so it is outside the redaction surface by construction. Default False: byte-identical historical output, no extra reads.

Scan guard (token_scan_limit): because with_tokens reads every matched session's files at request time, an unscoped run over a huge corpus is a multi-hour I/O storm. When with_tokens is set with no narrowing filter (agent/since/until) and more than token_scan_limit sessions match, the call returns {"error": "scope_required", ...} (naming the count and the limit) INSTEAD of scanning — the check runs on the cheap inventory count before any file is read. Narrow the scope, or raise token_scan_limit (0 disables the cap) to force the full scan. A permitted-but-large scan runs but carries a warning.

Thin wrapper over :func:ai_r.session_stats.session_stats that translates the core ValueError contract into the {"error": "invalid_argument", "message": str(exc)} shape the MCP client expects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topNo
agentNo
sinceNo
untilNo
group_byNoagent
edit_pathNo/
with_tokensNo
token_scan_limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly. It discloses that with_tokens reads at request time (nothing in background), explains exact vs estimate vs unknown token accounting, states that sums with no data stay null (never fabricated), notes the redaction-safe nature, and details the scan guard's error/return behavior. This is exemplary transparency.

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?

The description is long but every paragraph earns its place: purpose, grouping options, token behavior, scan guard, and error mapping. It is well-structured with clear headers (RISK-4 note, group_by enumeration) and uses examples. No redundancy or 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?

For an 8-parameter tool with no annotations and 0% schema description coverage, this description is exceptionally complete. It explains the output group fields (edits, intents, agents, messages), token block contents, totals behavior, error shapes, and the exact wrapper contract. The existing output schema plus this description leaves a well-rounded picture.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It thoroughly documents group_by (all five enum values with nuances like '(mixed)' and '(unknown)'), with_tokens (including sub-fields and exact/estimate/unknown semantics), and token_scan_limit (including 0 disables cap). However, top and edit_path are not explicitly explained, though their meanings are partially inferable. The gap prevents a 5 but is still strong overall.

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?

The description opens with 'Summarise sessions, grouped and ranked — the bird's-eye audit view,' which uses a specific verb and resource. It explicitly contrasts with siblings (find_file_edits / find_tool_calls return flat record streams) and explains the grouping/rollup distinction, so it clearly differentiates from alternatives.

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?

It provides explicit when-to-use guidance: 'Where find_file_edits / find_tool_calls return flat record streams, this rolls the sessions themselves up by one dimension.' It also gives actionable tips (e.g., 'Pair with with_tokens=True to see what each model actually cost') and warns about the scan guard, including when to narrow scope or raise token_scan_limit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pro-target/ai-r'

If you have feedback or need assistance with the MCP directory API, please join our Discord server