Skip to main content
Glama

flatten_session

Reduce session file size and context tokens by moving bulky tool results to a sidecar file, preserving the full conversation for lossless restoration.

Instructions

Flatten a session: move bulky tool results (large text output and base64 image/screenshot blocks) out of the session JSONL into a sidecar file, leaving a lightweight [FLATTENED ...] marker in their place. The conversation reads identically — every prompt and event stays verbatim — but resumes with far fewer context tokens. Crash-safe (atomic rewrite + idempotent sidecar) and fully reversible via unflatten_session. Reports diskBytesSaved (file shrink, affects --resume parse speed) and contextTokensSaved out of contextTokensTotal (the number that matters for compaction); token savings are estimated locally, or exact when ANTHROPIC_API_KEY is set. Accepts a UUID, "last", "last N", or "current". Refuses to rewrite a session edited in the last 10s (likely live) unless force=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idNoSession UUID, "last", "last N", or "current" (most recent). Any other value is treated as a keyword matched against first messages and branch names, and may flatten MULTIPLE matching sessions — prefer a UUID here.
sessionIdNocamelCase alias for session_id (the list_sessions output uses this name). Use session_id; this is accepted so a camelCase call does not fail validation.
project_dirNoAbsolute path to project. Default: the project the CLI runs in (cwd)
min_sizeNoOnly flatten tool results larger than N bytes
dry_runNoReport what would be flattened without modifying files
forceNoFlatten even if the session was modified seconds ago (may be live). Use only when the session is idle.
include_tool_use_resultNoAlso flatten the top-level toolUseResult mirror Claude Code keeps per result line (roughly doubles disk savings; lossless & restorable). Set false to only touch message.content.
Behavior5/5

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

With no annotations provided, the description carries full burden and excels. It discloses atomic rewrite, idempotent sidecar, crash-safety, full reversibility, the 10-second edit guard, the force flag, and details on what the tool reports (diskBytesSaved, contextTokensSaved) with clarification on estimation vs. exact values depending on API key presence. No behavioral trait is obscured.

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 well-structured and front-loaded with the primary action. Every sentence contributes meaningful information without redundancy. It efficiently covers purpose, behavior, parameters, and output in a compact block.

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?

Despite lacking an output schema, the description fully explains return values and their significance. It covers all 7 parameters indirectly by referencing their behavior (e.g., session_id, force). The crash-safety and estimation details fill gaps that structured metadata would otherwise handle.

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 coverage is 100% with detailed parameter descriptions. The tool description adds no new meaning to parameters beyond what is already in the schema; it only provides overall context. Thus, baseline score of 3 is appropriate.

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 clearly states the tool's purpose: flatten a session by moving bulky tool results into a sidecar file, replacing them with lightweight markers. It distinguishes itself from siblings like unflatten_session (reverse operation) and other session management tools (list, search, prune, retrieve).

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

Usage Guidelines4/5

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

The description explains when to use the tool (to reduce context tokens), and provides conditions for safe usage (crash-safe, reversible, force flag for live sessions). It mentions the reversible counterpart (unflatten_session) but does not explicitly compare to prune_flatten_artifacts or retrieve_flattened, though the sibling tools' purposes are sufficiently distinct.

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/shayaShav/flatten-mcp'

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