Summary
Current session statistics capture flat tool counts, but miss important dimensions needed to understand user usage patterns across MCP servers and workflows.
Current State
The statistics JSON files capture:
- Session metadata (id, project, branch, model, timestamps, duration)
- Token counts (input, output, cache, subagent)
- Message counts (user, assistant)
tools_summary — flat count per tool name
Proposed Additions
High Value
-
Tool call sequence — Ordered list of tool calls (or at least common subsequences). Reveals workflow patterns like list-spaces → search-space → get-object → update-object.
-
Tool success/failure counts — Per-tool error rates to surface MCP reliability issues. e.g. {"API-update-object": {"success": 10, "failure": 3}}
-
MCP server grouping — Aggregate tool counts by MCP server. e.g. {"anytype": 24, "google": 2, "ai-usage-log": 3}. Currently requires parsing tool name prefixes manually.
-
Session tags/intent — A tags array (e.g. ["learning", "anytype", "google-classroom"]) or session_summary string for easy filtering without grepping file contents.
-
Tool call timing — Average/max latency per tool to identify slow MCP tools.
Medium Value
-
Tool call pairs (co-occurrence) — Which tools are called together in the same turn. Reveals parallel vs sequential usage.
-
User message density — avg_time_between_user_messages to show engagement intensity.
-
Error messages — Count + last error string per tool. Currently errors vanish after session ends.
-
Objects touched count — For MCP tools, count of unique object IDs operated on (without storing IDs). Shows breadth vs depth of interaction.
Low Value (Nice to Have)
- Context compression events — How many times context was compressed during the session.
- Skills invoked — Which
/skill commands were triggered (separate from raw tool calls).
- Git diff stats — Lines added/removed during the session.
Motivation
When analyzing Anytype MCP usage across sessions, the current stats only revealed tool call counts. With the proposed fields, we could answer questions like:
- What's the typical workflow when interacting with Anytype?
- Which MCP tools fail most often?
- How much time is spent waiting on MCP tool responses?
- Are sessions focused (few objects, deep) or broad (many objects, shallow)?
Summary
Current session statistics capture flat tool counts, but miss important dimensions needed to understand user usage patterns across MCP servers and workflows.
Current State
The statistics JSON files capture:
tools_summary— flat count per tool nameProposed Additions
High Value
Tool call sequence — Ordered list of tool calls (or at least common subsequences). Reveals workflow patterns like
list-spaces → search-space → get-object → update-object.Tool success/failure counts — Per-tool error rates to surface MCP reliability issues. e.g.
{"API-update-object": {"success": 10, "failure": 3}}MCP server grouping — Aggregate tool counts by MCP server. e.g.
{"anytype": 24, "google": 2, "ai-usage-log": 3}. Currently requires parsing tool name prefixes manually.Session tags/intent — A
tagsarray (e.g.["learning", "anytype", "google-classroom"]) orsession_summarystring for easy filtering without grepping file contents.Tool call timing — Average/max latency per tool to identify slow MCP tools.
Medium Value
Tool call pairs (co-occurrence) — Which tools are called together in the same turn. Reveals parallel vs sequential usage.
User message density —
avg_time_between_user_messagesto show engagement intensity.Error messages — Count + last error string per tool. Currently errors vanish after session ends.
Objects touched count — For MCP tools, count of unique object IDs operated on (without storing IDs). Shows breadth vs depth of interaction.
Low Value (Nice to Have)
/skillcommands were triggered (separate from raw tool calls).Motivation
When analyzing Anytype MCP usage across sessions, the current stats only revealed tool call counts. With the proposed fields, we could answer questions like: