Skip to main content
Glama

flatten-mcp

The same Claude Code session, resumed for a fraction of the tokens — nothing summarized, nothing lost. A long session carries its entire history on every message, and deep in, most of that is no longer conversation: it is files Claude already read and boiled down to a line or two, still riding along in context. flatten-mcp does what the name says — the digested bulk moves to a local backup, a small marker stays behind, and every prompt, reply, and decision survives word for word, any block one call from coming back. Claude gets cheaper and sharper.

What is all that weight? The 2 MB log that became one line, the screenshot Claude described, the five files it summarized — raw source that did its job and turned into a sentence. flatten-mcp moves each tool result above a size threshold into a local backup next to the session and leaves a small [FLATTENED …] marker in its place; any block is one call from coming back.

/compact

Auto tool-result clearing

flatten-mcp

What happens

history rewritten into a summary

old tool results cleared as the limit nears

bulk moved to a local backup, markers remain

Speed & cost

slow — a full model pass over your history, spends tokens/budget

automatic, no token cost

instant, zero tokens — a local file rewrite

Lossy?

yes — an interpretation

cleared content is gone from context

no — byte-identical restore any time

You choose when?

you or the auto-cliff

automatic

yes

Session file on disk

rewritten

unchanged

shrinks; the backup keeps every original

Try it first — nothing installed, nothing written:

npx -y flatten-mcp-session flatten --dry-run

Run it from a project you use Claude Code in — any terminal, or straight from inside a session with the ! prefix: it prints what a flatten would save on your most recent session and writes nothing.

The report doesn't just total the savings — it shows exactly where the weight sits:

  context tokens   : 168707 saved of 444927 (37.9%) exact
  breakdown        : (exact tokens)
    claude-in-chrome (MCP)  126x  8.9 MB    94,342 tok
    Read                    55x   1.6 MB    64,028 tok
    Bash                    23x   40.9 KB   7,301 tok
    …

Add --breakdown deep and every row opens into its individual blocks — each command, file, and screenshot that built the bulk, largest first.

Quick start

Runs through npx — no global install, nothing added to your project. Every read/write stays inside the agent's own session store — Claude Code's ~/.claude/projects/ by default, Codex's ~/.codex/sessions when you target it — and there are zero network calls by default. (Node ≥ 18, which Claude Code already runs on.)

1. Install — either path:

# Terminal: register the server user-wide (pinned; use @latest if you prefer auto-updates)
claude mcp add flatten -s user -- npx -y flatten-mcp@2.6.0

# Optional: the /flatten slash command
curl -fsSL https://raw.githubusercontent.com/shayaShav/flatten-mcp/main/commands/flatten.md -o ~/.claude/commands/flatten.md
# Or as a Claude Code plugin — registers the server AND bundles /flatten in one step
claude plugin marketplace add shayaShav/flatten-mcp
claude plugin install flatten-mcp@flatten-mcp

2. Restart Claude Code (or open a new session) — an already-open session does not pick up a newly added server. Check with /mcp: flatten should be listed as connected.

3. Use it — two steps, always:

/flatten     → the session file is rewritten in place, right after a complete backup is written
/resume      → switch to another session and back; the reloaded copy is the lighter one

Until you /resume, the window you are in still holds the full pre-flatten copy in memory — nothing will look different. After it, watch the context indicator drop.

In ~/.claude.json or your project's .mcp.json:

{
    "mcpServers": {
        "flatten": { "command": "npx", "args": ["-y", "flatten-mcp@2.6.0"] }
    }
}

For development: git clone https://github.com/shayaShav/flatten-mcp.git && cd flatten-mcp && npm install, then point the config at node /absolute/path/to/dist/index.js.

Related MCP server: Claude Code MCP Server

Usage

  • Bare /flatten (or asking "flatten this session") targets the current session — the server identifies it from CLAUDE_CODE_SESSION_ID. Pass a UUID to target another session.

  • Preview first with a dry run"dry-run flatten this session" — nothing is written.

  • See what's in there: every dry run includes the breakdown; pass breakdown: true on a real flatten (CLI: --breakdown) to get it there too, or breakdown: "deep" (CLI: --breakdown deep) to list every block — each command and file with its own size and tokens, largest first.

  • Undo completely by asking to unflatten: every block returns to its exact original value.

  • Don't flatten a session that is mid-generation; flatten between turns, or from a second window — which also keeps the tool schemas out of your working session entirely.

  • Working in Codex CLI instead? The same tools take agent: "codex" — see OpenAI Codex CLI, too.

TIP

Flattening is pure file surgery — no model intelligence involved — so a fast, inexpensive model (/model haiku) flattens just as well as a frontier one. Or skip the model turn entirely: ! npx -y flatten-mcp-session flatten runs the CLI from inside the session — zero tokens, no model pass over your still-heavy history.

What you'll actually save

The reduction is the bulk you remove, not a fixed percentage:

  • Read-heavy sessions (large files, long logs, screenshots): the demo above measured 340,071 → 132,800 tokens, a 61% cut. The more ingested bulk, the bigger the cut — base64-screenshot-heavy sessions can go higher.

  • Prose-heavy sessions (little external data): savings are small — there's not much bulk to move.

A common point to reach for it is around 200k tokens; the most dramatic cuts show up at 250k–400k. It's repeatable — a re-flatten only touches bulk that arrived since the last one. The three tool schemas cost ~1,200 tokens per turn while the server is connected; one flatten of a read-heavy session removes orders of magnitude more from every later turn (207k in the demo), and the separate-window pattern above makes even that overhead zero.

Where the saving lands: a session re-sends its history on every message, so removed bulk stops costing you on every later turn — prompt caching softens that (cache reads bill at roughly a tenth of the input price), but a cold cache re-warms the full context at a premium, and on subscription plans the same tokens draw down your usage limits. Just as important, a leaner window keeps the context ceiling — and lossy auto-compaction — further away.

OpenAI Codex CLI, too

The same engine, the same guarantees, for Codex sessions. Install flatten-mcp as a Codex plugin — it bundles the server plus a flatten-codex skill that keeps every call on the Codex store — or skip installing and drive the terminal CLI:

# Codex plugin
codex plugin marketplace add https://github.com/shayaShav/flatten-mcp
# then /plugins → install flatten-mcp

# Or zero-install: the CLI reaches Codex rollouts directly
npx -y flatten-mcp-session flatten --agent codex
codex resume <session-id>        # the resumed rollout is the lighter copy

Measured live on real sessions: resuming a flattened rollout sent 39–51% fewer input tokens by Codex's own counter (27,029 → 13,139 on the largest run). Codex rebuilds resume context from the rollout file, so what leaves the file leaves the model's context — and restore stays byte-identical, proven on every candidate-bearing rollout of a 728-file corpus (209/209). A resumed Codex session has no MCP retrieve tool, so each marker's tail carries the exact command that fetches its block back (flatten-mcp-session retrieve <session> <id> --agent codex); the backup sits next to the rollout, invisible to codex resume.

Two honest notes. Codex token savings are local estimates — Anthropic's count_tokens does not measure GPT-5's tokenizer, so the context total comes from Codex's own usage events. And the size of the win depends on how much output Codex persisted: it sometimes stores only a preview of large command output. Claude Code stays the first-class path; Codex rides the SessionAdapter seam more agents can follow (see Compatibility & roadmap).

Tools

Tool

What it does

flatten_session

Move bulky tool results into the backup, leaving [FLATTENED …] markers. Crash-safe, reversible. No argument = current session; supports dry_run, breakdown (true or "deep"), min_size, include_tool_use_result, and agent ("claude" default, "codex").

retrieve_flattened

Fetch one original block back by id — text, or a flattened screenshot re-rendered as a real image. Takes agent to match the session's store.

unflatten_session

Reverse everything: re-inline every block from the backup, then delete the backup. Takes agent too.

In a flattened session the model sees markers like this, carrying everything needed to fetch the original:

[FLATTENED id=toolu_01AbC… tool=Read file_path=/src/server.ts | text 48213B/612L | session=2f9c… | retrieve_flattened(id,session) for raw content]

How it works

  • One backup, not deletion. <session>.jsonl.bak holds the complete session fully inlined; the live file carries markers. Kept in lockstep every run (backup = unflatten(live), live = flatten(backup)).

  • Crash-safe. Originals are written to the backup before bulk leaves the session, each write via atomic temp-file-and-rename — an interrupted run can't leave a half-written session.

  • Self-cleaning. A full unflatten restores everything inline and deletes the backup — zero artifacts left.

  • Re-flatten friendly. As the session grows, run it again; only new bulk is touched, and content added after a flatten is never lost on restore.

  • Lossless. Text and base64 images are stored exactly as they appeared — unflatten_session restores byte-identical values.

  • Honest numbers. Claude Code stores each tool result twice on disk but sends one to the model; reports separate diskBytesSaved from contextTokensSaved (the number that matters), estimated locally — or exact via count_tokens when you opt in with FLATTEN_COUNT_EXACT=1 (plus ANTHROPIC_API_KEY). The breakdown's per-group counts ride the same opt-in; per-block figures in deep mode stay estimates.

Details — session JSONL format, backup model, marker protocol — in docs/ARCHITECTURE.md.

Validate the claims yourself: (1) pick a meaty session; (2) ask for a dry run and read the report; (3) /flatten for real, /resume, and watch the context indicator drop by the reported amount; (4) unflatten and confirm the session file returns byte-identical (diff against a copy if you kept one).

Security & verification

  • Provenance you can check. Every release is published from CI via npm trusted publishing (OIDC) with provenance attestations, from a signed tag — no npm token exists anywhere. Verify: npm audit signatures. Pin an exact version (as the Quick start does) and the committed package-lock.json documents the tree we test against; npx resolves the two direct dependencies' own trees at install time — audit with npm ls --omit=dev.

  • File access. Confined to the session stores: <CLAUDE_CONFIG_DIR or ~/.claude>/projects/<encoded-project-dir>/ and, under agent: "codex", <CODEX_HOME or ~/.codex>/sessions/ — rewriting session files there is the tool's entire job, always backup-first and atomic. The one exception: flatten-mcp-session retrieve --out writes a retrieved image where you tell it to.

  • Network. Zero outbound calls unless you explicitly opt in to exact token counts. With both FLATTEN_COUNT_EXACT=1 and ANTHROPIC_API_KEY set — key presence alone is not enough — exactly one endpoint is ever contacted: POST api.anthropic.com/v1/messages/count_tokens (free). The request body contains the counting model id (FLATTEN_COUNT_MODEL) and a single user message holding the tool results being flattened, reduced to their text and image blocks; a second identical call counts the replacement markers, and — when the breakdown is requested — one more of the same shape per report row. Sent only to Anthropic; the key is read from the environment and never stored or logged. There is no other outbound URL in the codebase. The optional flatten-mcp-http bin (below) accepts inbound connections when you run it — localhost by default — and makes no outbound calls.

  • Small enough to audit in one sitting. A few small TypeScript files, two direct dependencies, no telemetry, no shell, no hooks — no analytics, no spawned processes, no permission bypasses. Vulnerability reports: SECURITY.md.

Beyond Claude Code — CLI & library

The same engine ships as a terminal CLI, an in-memory library, and a Streamable HTTP server, so raw Messages API callers (any language) get the identical flatten/unflatten semantics with no MCP and no session files.

npx -y flatten-mcp-session flatten                     # most-recent session in this project
npx -y flatten-mcp-session flatten <session> --dry-run
npx -y flatten-mcp-session flatten last --dry-run --breakdown deep   # per-block x-ray
npx -y flatten-mcp-session list
npx -y flatten-mcp-session unflatten <session>
npx -y flatten-mcp-session retrieve <session> <tool_use_id> --out shot.png

# Target OpenAI Codex CLI rollouts instead of Claude Code sessions:
npx -y flatten-mcp-session flatten --agent codex
npx -y flatten-mcp-session list --agent codex
npx -y flatten-mcp-session retrieve <uuid> <call_id> --agent codex
  • <session>: UUID, last, "last N", current, or a keyword — same grammar as the MCP tool. Shared flags: --agent <claude|codex> (default claude), --project-dir, --claude-dir, --codex-home, --json.

  • --agent codex targets ~/.codex/sessions (override with --codex-home or $CODEX_HOME). A UUID reaches any rollout in the tree; last/"last N"/keyword are scoped to rollouts whose cwd equals the project dir, and current falls back to last (Codex has no live-session linkage). Codex token savings are reported as local estimates only — the context total comes from Codex's own usage events. The backup sits next to the rollout as <rollout>.jsonl.bak, invisible to codex resume.

  • Drives the exact same on-disk engine as the MCP server — ideal for cron and scripts. After a real flatten, /resume the session in Claude Code (or codex resume the rollout) to load the lighter copy.

echo '[{"role":"user","content":"hi"}]' | npx -y flatten-mcp-cli --flatten
npx -y flatten-mcp-cli --flatten --min-size 2000 < body.json > flattened.json
npx -y flatten-mcp-cli --unflatten < flattened.json > restored.json
  • --flatten prints { messages, extracted, flattenedCount, contextTokensSaved, … }persist extracted yourself; you are the store. --unflatten restores byte-for-byte. No server, no disk, no network. Bad input → stderr + exit 1.

import { flattenMessages, unflattenMessages } from 'flatten-mcp';

const { messages, extracted, contextTokensSaved } = flattenMessages(myMessages);
// send `messages` to the API; persist `extracted` yourself — you are the store.
const original = unflattenMessages(messages, extracted);   // byte-for-byte restore
  • Synchronous, never mutates input (deep-copies first). flattenRequestBody / unflattenRequestBody handle a full { system, messages, tools, … } body.

  • Exact token counts (optional, async): flattenMessagesExact uses Anthropic's free count_tokens when ANTHROPIC_API_KEY is set — calling the *Exact variant is the opt-in here (countExact: false forces the estimate); the FLATTEN_COUNT_EXACT variable gates only the MCP server and session CLI.

  • Prompt-caching caveat: flattening earlier messages changes the cached prefix and invalidates cache_control breakpoints from that point on — flatten before establishing a breakpoint, or the cache re-write can cost more than the flatten saves in short-lived conversations.

npx -y flatten-mcp-http            # POST http://127.0.0.1:8787/mcp
npx -y flatten-mcp-http --port 3000 --host 0.0.0.0
  • Serves flatten_messages / unflatten_messages — the same stateless in-memory engine as the library, callable from any MCP client or hosted registry inspector. Persist the returned extracted yourself and feed it back to restore, exactly like the library.

  • The three disk tools are not exposed over HTTP: they operate on the local Claude Code session store, which does not exist wherever a remote client calls from. (On the stdio server, FLATTEN_INMEMORY_TOOLS=1 adds these two tools alongside the disk ones.)

  • No auth, permissive CORS, no outbound network calls — the tools are pure functions over the request's JSON. Binds 127.0.0.1 by default; put your own proxy/auth in front before exposing it further. Note the transport cost: the conversation you flatten travels to this server and back — inside your own process, prefer the library.

A public flatten-mcp-http instance runs at https://shaya.cloud/flatten-mcp (Streamable HTTP, no credentials). Same contract as the library: it serves flatten_messages / unflatten_messages only — persist the returned extracted yourself — and the disk tools still need the local install above. Mind the transport: your conversation travels to this server and back, so send only what you would route through a third-party service.

# Claude Code
claude mcp add --transport http flatten-remote https://shaya.cloud/flatten-mcp
  • Claude (claude.ai / Desktop): Settings → Connectors → Add custom connector → paste the URL.

  • Cursor: Add to Cursor, or "flatten": { "url": "https://shaya.cloud/flatten-mcp" } in mcp.json.

  • VS Code: "flatten": { "type": "http", "url": "https://shaya.cloud/flatten-mcp" } in mcp.json.

  • Liveness: curl https://shaya.cloud/flatten-mcp/health

FAQ

Won't Anthropic just build this in? Claude Code already clears old tool results automatically near the limit (see the table up top). Flatten is a different contract: you pick the moment, the restore is byte-identical, and the on-disk session you /resume from actually shrinks.

Will the model fetch a flattened block, or hallucinate around it? Each marker carries the id and session, and in practice the model calls retrieve_flattened when it needs raw bytes back. Deterministic recovery is always there regardless: unflatten_session re-inlines everything.

Does it need Node in my project? No — it runs through npx ephemerally and touches only your agent's session files, not your project or toolchain.

Can a team use it? It's per-developer (each dev's local session store). Standardize by committing the mcpServers block to your project's .mcp.json, or point the team at the plugin install.

Compatibility & roadmap

  • Claude Code and OpenAI Codex CLI session stores — selected per call with --agent <claude|codex> (CLI) or the agent parameter (MCP), default claude. The disk engine runs behind a SessionAdapter seam, so each agent's store is a self-contained adapter over the shared block logic; more agents can follow the same seam — contributions welcome (CONTRIBUTING.md). WSL2 counts as Linux: if your agent runs inside WSL2, flatten-mcp runs in the same environment and targets those sessions normally. Native Windows is untested.

Configuration

Operates on the project the CLI runs in; pass project_dir on any call to target another.

Env var

Required

Purpose

CLAUDE_CONFIG_DIR

no

Claude config dir whose projects/ store is read (default ~/.claude). Same variable Claude Code uses for profiles, so an alternate-profile server targets its own sessions automatically; override per call with claude_dir.

CODEX_HOME

no

Codex home whose sessions/ tree is targeted under agent: "codex" (default ~/.codex); override per call with codex_home (MCP) / --codex-home (CLI).

FLATTEN_COUNT_EXACT

no

Set to 1 to count token savings exactly via Anthropic's free count_tokens — the only outbound call, and it needs ANTHROPIC_API_KEY too. Off by default: key presence alone never triggers the request (see Security).

ANTHROPIC_API_KEY

no

The key for the exact count. Ignored by the MCP server and session CLI unless FLATTEN_COUNT_EXACT=1.

FLATTEN_COUNT_MODEL

no

Model id for the exact count (default claude-haiku-4-5-20251001).

FLATTEN_INMEMORY_TOOLS

no

Set to 1 to also register flatten_messages/unflatten_messages on the stdio server (see the HTTP section above). Off by default to keep the local tool surface lean.

Uninstall

Unflatten anything you want back inline first — a flattened session needs its <session>.jsonl.bak for retrieve_flattened/unflatten_session, and uninstalling does not remove backups. Then:

claude mcp remove flatten -s user && rm -f ~/.claude/commands/flatten.md   # terminal install
claude plugin uninstall flatten-mcp                                        # plugin install

To reclaim disk for sessions you'll never restore, delete their .jsonl.bak files from ~/.claude/projects/<encoded-project-dir>/ (Claude Code) or from next to the rollouts under ~/.codex/sessions/ (Codex).

Contributing

Issues and PRs welcome — dev setup, project map, and workflow in CONTRIBUTING.md; security reports via SECURITY.md.

License

MIT © Shaya Shaviv

Available Tools

5 tools
flatten_messagesFlatten messages[] (in memory)A
Read-onlyIdempotent

Flatten a raw Anthropic Messages API messages[] array in memory: every bulky tool_result block (large text or base64 image) larger than min_size bytes is swapped for a compact [FLATTENED id=...] marker, and the originals are returned in "extracted". Persist "extracted" yourself — you are the store — and feed it back to unflatten_messages to restore the conversation byte-for-byte. Purely functional: no session file, no disk, no network; the input is never mutated. This is the same engine as the flatten-mcp library export; for production use inside your own process, prefer importing the library so the conversation does not travel over a transport.

ParametersJSON Schema
NameRequiredDescriptionDefault
messagesYesThe raw Messages API messages[] array ({ role, content } objects, verbatim).
min_sizeNoOnly flatten tool_result blocks larger than N serialized bytes.

Output Schema

ParametersJSON Schema
NameRequiredDescription
messagesYesThe flattened messages[] array — safe to send — with every bulky tool_result replaced by a compact [FLATTENED id=...] marker. Deep-copied; the input is never mutated.
extractedYesThe originals removed from the conversation. Persist this array yourself and pass it back to unflatten_messages to restore byte-for-byte.
flattenedCountYesHow many tool_result blocks were flattened.
contextTokensExactYesAlways false here — the in-memory tool never makes a network call; use the library flattenMessagesExact for an exact count.
contextTokensSavedYesEstimated context tokens removed from the conversation.
imageBlocksFlattenedYesHow many image blocks were among the flattened results.

TDQS

A4.3/5.0
Behavior4/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds that it is purely functional with no session file, disk, or network, and the input is never mutated. This enriches behavioral understanding.

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?

The description is front-loaded with the action and each sentence adds value. While somewhat long, it is well-structured and informative without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description appropriately focuses on usage and behavior. It covers the functional nature, persistence requirement, and alternative, making it complete for the tool's complexity.

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 100%, but the description adds meaning: it explains min_size is for blocks larger than N bytes, and that messages should be a raw Messages API array. This adds value beyond the 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?

The description clearly states it flattens a raw Anthropic Messages API messages[] array in memory, swapping bulky tool_result blocks with markers and returning originals in 'extracted'. It uses a specific verb and resource, and distinguishes from siblings like unflatten_messages.

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 tells the agent to persist 'extracted' itself and feed it back to unflatten_messages for restoration. It also advises using the library directly for production, providing clear context on when to use this tool vs alternatives.

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

flatten_sessionFlatten Claude Code or Codex sessionA

Flatten a Claude Code or OpenAI Codex CLI session: move bulky tool results (large text output and, for Claude, base64 image/screenshot blocks) out of the session JSONL into a backup copy, leaving a compact [FLATTENED ...] marker. The conversation reads identically — every prompt and event stays verbatim — but resumes with far fewer context tokens. Crash-safe (atomic rewrite + a single backup holding the complete session) and reversible via unflatten_session. Choose the store with agent ("claude" default, or "codex"). Reports diskBytesSaved and contextTokensSaved out of contextTokensTotal. For claude these are estimated locally, or exact when FLATTEN_COUNT_EXACT=1 and ANTHROPIC_API_KEY are both set; for codex the token savings are ALWAYS a local estimate (Anthropic count_tokens does not measure the GPT-5 tokenizer) and contextTokensTotal comes from Codex's own token_count events. With no session_id, flattens the current live session (claude); under codex "current" falls back to "last" (Codex has no live-session linkage). Also accepts a UUID, "last", "last N", or "current"; under codex a UUID reaches any rollout in the tree, while "last"/"last N"/keyword are scoped to the project dir. After flattening, /resume the session (claude) or codex resume the rollout (codex) to load the lighter copy.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentNoWhich agent's session store to target: "claude" (default) or "codex".claude
dry_runNoReport what would be flattened without modifying files
min_sizeNoOnly flatten tool results larger than N bytes
breakdownNoInclude the per-tool/resource breakdown of what was flattened. false, true, or "summary" = the aggregated adaptive rows plus byKind/bySlot groupings; "deep" ALSO lists every individual block under its row (tool + arg summary + bytes + per-block token estimate), groups sorted by context tokens then blocks by bytes. Dry runs always include at least the summary; set true/"summary"/"deep" to also get it on a real flatten.
sessionIdNocamelCase alias for session_id (accepted so a camelCase call does not fail validation).
claude_dirNoAbsolute path (or ~/...) to the Claude config dir whose sessions to target — the dir holding projects/. Default: $CLAUDE_CONFIG_DIR if set, else ~/.claude. Applies to agent "claude" only.
codex_homeNoAbsolute path (or ~/...) to the Codex home whose sessions to target — the dir holding sessions/. Default: $CODEX_HOME if set, else ~/.codex. Applies to agent "codex" only.
session_idNoSession UUID, "last", "last N", or "current". Omit to flatten the current live session (claude); under codex "current" falls back to "last".
project_dirNoAbsolute path to project. Default: the project the CLI runs in (cwd). Under codex, scopes "last"/"last N"/keyword to rollouts whose cwd equals this dir.
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.

Output Schema

ParametersJSON Schema
NameRequiredDescription
sessionsYesOne entry per session flattened (a single entry for one session_id, or several for "last N").

TDQS

A4.8/5.0
Behavior5/5

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

Discloses crash-safe atomic rewrite, reversible nature, estimation vs exact token savings for each agent, and behavior with 'current' under codex. No contradiction with annotations (readOnlyHint=false, destructiveHint=false). Adds extensive behavioral context beyond annotations.

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 core purpose; but the description is long and includes many details that could be condensed. However, given the tool's complexity, the length is justified and well-structured.

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?

Covers all aspects: agent differences, token calculation, session ID handling, directory paths, output fields mentioned. Comprehensive for a 10-parameter tool with output schema.

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 has 100% description coverage, so baseline is 3. The description adds moderate extra context, e.g., explaining dry_run reports without modifying, breakdown options in detail, and behavior of session_id. But the schema descriptions are already good, so only slight improvement.

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?

Description clearly states the tool flattens Claude Code or Codex CLI sessions by moving bulky tool results to a backup copy and leaving compact markers. It distinguishes from siblings like unflatten_session and flatten_messages.

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?

Provides explicit guidance on when to use (to reduce context tokens), how to choose agent, fallback behaviors for different session_id values, and mentions reversible via unflatten_session. Clearly states alternatives and context.

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

retrieve_flattenedRetrieve flattened contentA
Read-onlyIdempotent

Retrieve original tool result content from a flattened session, read straight from its backup. When you see [FLATTENED id=XXX tool=Read ... | text NNNB/NNL | session=YYY | ...] in the conversation, call this with the value after "id=" as tool_use_id and the value after "session=" as session_id, and set agent to match the session ("claude" default, or "codex"). Returns the original text output, or — for flattened screenshots (claude) — the actual image so you can view it again.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentNoWhich agent's session store the flattened session lives in: "claude" (default) or "codex".claude
claude_dirNoAbsolute path (or ~/...) to the Claude config dir whose sessions to target — the dir holding projects/, e.g. ~/.claude-2 for a second profile. Default: $CLAUDE_CONFIG_DIR if set, else ~/.claude. Applies to agent "claude" only.
codex_homeNoAbsolute path (or ~/...) to the Codex home whose sessions to target — the dir holding sessions/. Default: $CODEX_HOME if set, else ~/.codex. Applies to agent "codex" only.
session_idYesValue after "session=" in the [FLATTENED ... session=YYY ...] marker
project_dirNoAbsolute path to project. Default: the project the CLI runs in (cwd). Ignored under codex (rollouts are located by UUID globally).
tool_use_idYesValue after "id=" in the [FLATTENED id=XXX ...] marker

Output Schema

ParametersJSON Schema
NameRequiredDescription
kindYes"text", "image", or "mixed".
slotYes"content"/"toolUseResult" (claude) or "output" (codex).
tool_nameYesOriginating tool name of the retrieved result.
line_countYesLine count of the original text projection.
tool_use_idYesThe tool_use_id that was retrieved.
original_sizeYesByte size of the original content.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds valuable context: it reads 'straight from its backup', returns original text output, and for flattened screenshots (claude) returns the actual image for viewing. No contradictions with annotations.

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 efficient and front-loaded, starting with the core purpose then immediately giving usage instructions. Every sentence adds value—no filler. It's appropriately sized for the tool's complexity.

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 the tool has 6 parameters (2 required), a complex trigger pattern, and an output schema, the description covers all necessary aspects: trigger identification, parameter extraction, agent selection, default paths, and return types. The output schema exists and the description hints at what is returned (text or image), making it complete.

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 100% with descriptions for all 6 parameters. The description adds extra meaning beyond the schema by explaining how to derive parameters from the FLATTENED marker (e.g., 'value after id=') and providing context for agent and directory defaults.

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 retrieves original tool result content from a flattened session, with a specific verb ('Retrieve') and resource ('original tool result content from a flattened session'). It distinguishes from sibling tools like flatten_session by explaining the use case of reading previously flattened content.

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?

The description explicitly tells when to use the tool: when a [FLATTENED ...] marker appears in the conversation. It provides step-by-step instructions on extracting tool_use_id and session_id from the marker, setting the agent, and default values.

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

unflatten_messagesUnflatten messages[] (in memory)A
Read-onlyIdempotent

Restore a conversation flattened by flatten_messages: re-inlines every tool_result whose content is a [FLATTENED id=...] marker from the matching entry in "extracted", byte-for-byte. Markers with no matching entry are left in place. Purely functional — no disk, no network, input never mutated.

ParametersJSON Schema
NameRequiredDescriptionDefault
messagesYesThe flattened messages[] array (the "messages" field of a flatten_messages result).
extractedYesThe "extracted" array returned by flatten_messages for this conversation.

Output Schema

ParametersJSON Schema
NameRequiredDescription
messagesYesThe restored messages[] array, byte-for-byte identical to the pre-flatten conversation. Any [FLATTENED id=...] marker with no matching extracted entry is left in place.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and idempotentHint=true. Description reinforces with 'purely functional — no disk, no network, input never mutated.' Also details behavior for missing markers. Fully transparent and consistent with annotations.

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?

Two sentences, no wasted words. First sentence defines the core function, second adds important caveats. Perfectly front-loaded and concise.

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 the straightforward nature of the tool, the description covers the restoration process, marker handling, and principles (functional, idempotent). Output schema exists (as per context signal), so no need to detail return values. Comprehensive for the task.

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 descriptions provide clear definitions for both parameters (messages and extracted). The tool description adds behavioral context about the marker format and byte-for-byte restoration, enhancing understanding beyond schema. With 100% schema coverage, baseline is 3, but the additional context merits a 4.

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?

Clearly states it restores a conversation flattened by flatten_messages, re-inlining tool_result markers byte-for-byte. The verb 'restore' and resource 'conversation' are explicit. Distinguishes from sibling tools like flatten_messages by directly referencing the inverse operation.

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?

Implicitly specifies usage: use when you have a flattened conversation and want to restore it. Does not explicitly state when not to use or list alternatives, but the context of being the inverse of flatten_messages is clear.

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

unflatten_sessionUnflatten (restore) sessionA
Destructive

Reverse a flatten: re-inline every flattened tool result back into the session JSONL from the backup, restoring the session to its pre-flatten state, then delete the backup so nothing is left behind. Choose the store with agent ("claude" default, or "codex"). Under codex a UUID reaches any rollout in the tree; "last"/"current" are scoped to the project dir ("current" falls back to "last").

ParametersJSON Schema
NameRequiredDescriptionDefault
agentNoWhich agent's session store to target: "claude" (default) or "codex".claude
claude_dirNoAbsolute path (or ~/...) to the Claude config dir whose sessions to target — the dir holding projects/, e.g. ~/.claude-2 for a second profile. Default: $CLAUDE_CONFIG_DIR if set, else ~/.claude. Applies to agent "claude" only.
codex_homeNoAbsolute path (or ~/...) to the Codex home whose sessions to target — the dir holding sessions/. Default: $CODEX_HOME if set, else ~/.codex. Applies to agent "codex" only.
session_idYesSession UUID, "last", or "current" (the live session; under codex "current" falls back to "last")
project_dirNoAbsolute path to project. Default: the project the CLI runs in (cwd). Under codex, scopes "last"/keyword to rollouts whose cwd equals this dir.

Output Schema

ParametersJSON Schema
NameRequiredDescription
newSizeYesSession file size after restoring, in bytes.
skippedNoPresent with a reason when the restore was skipped (e.g. no backup to restore from).
notFoundYesMarker ids that had no matching backup entry and were left in place.
sessionIdYesThe session UUID that was processed ("" when nothing matched).
backupPathYesThe backup that was restored from (and removed on a full restore).
originalSizeYesSession file size before restoring, in bytes.
restoredCountYesHow many flattened tool results were re-inlined.

TDQS

A4.8/5.0
Behavior5/5

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

The description adds behavioral details beyond annotations: it explicitly states the backup is deleted, which aligns with destructiveHint=true. It also explains per-agent behavior and keyword scoping, providing full 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 two sentences, each carrying essential information: core action in the first, agent-specific nuances in the second. No redundancy or fluff.

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 the complexity (5 parameters, 1 required, output schema exists), the description covers all necessary aspects: purpose, behavioral details, parameter semantics, and agent-specific behavior. The output schema handles return values, so no gap.

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?

With 100% schema coverage, baseline is 3. The description adds meaning by explaining how 'agent' selects the store, how 'session_id' handles UUID/keywords, and how 'project_dir' scopes lookups for codex. This significantly aids correct invocation.

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 reverses a flatten operation by re-inlining tool results and deleting the backup. It distinguishes from siblings like flatten_session (the opposite) by specifying it restores the pre-flatten state.

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 (restoring a flattened session) and provides context for agent and scope selection. It lacks explicit when-not-to-use or alternatives, but the sibling list and context make it clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool update
    • Addedunflatten_session
  2. 2 tool updatesv2.6.1
    • Addedretrieve_flattened
    • Removedunflatten_session
  3. 3 tool updatesv2.6.0
    • Changedflatten_session12 fields changed
      • addedInput schema / properties / agent
        {
          "default": "claude",
          "description": "Which agent's session store to target: \"claude\" (default) or \"codex\".",
          "enum": [
            "claude",
            "codex"
          ],
          "type": "string"
        }
      • addedInput schema / properties / breakdown
        {
          "anyOf": [
            {
              "type": "boolean"
            },
            {
              "enum": [
                "summary",
                "deep"
              ],
              "type": "string"
            }
          ],
          "default": false,
          "description": "Include the per-tool/resource breakdown of what was flattened. false, true, or \"summary\" = the aggregated adaptive rows plus byKind/bySlot groupings; \"deep\" ALSO lists every individual block under its row (tool + arg summary + bytes + per-block token estimate), groups sorted by context tokens then blocks by bytes. Dry runs always include at least the summary; set true/\"summary\"/\"deep\" to also get it on a real flatten."
        }
      • changedInput schema / properties / claude_dir / description
        Before
        "Absolute path (or ~/...) to the Claude config dir whose sessions to target — the dir holding projects/. Default: $CLAUDE_CONFIG_DIR if set, else ~/.claude."
        After
        "Absolute path (or ~/...) to the Claude config dir whose sessions to target — the dir holding projects/. Default: $CLAUDE_CONFIG_DIR if set, else ~/.claude. Applies to agent \"claude\" only."
      • addedInput schema / properties / codex_home
        {
          "description": "Absolute path (or ~/...) to the Codex home whose sessions to target — the dir holding sessions/. Default: $CODEX_HOME if set, else ~/.codex. Applies to agent \"codex\" only.",
          "type": "string"
        }
      • changedInput schema / properties / project_dir / description
        Before
        "Absolute path to project. Default: the project the CLI runs in (cwd)"
        After
        "Absolute path to project. Default: the project the CLI runs in (cwd). Under codex, scopes \"last\"/\"last N\"/keyword to rollouts whose cwd equals this dir."
      • changedInput schema / properties / session_id / description
        Before
        "Session UUID, \"last\", \"last N\", or \"current\". Omit to flatten the current live session."
        After
        "Session UUID, \"last\", \"last N\", or \"current\". Omit to flatten the current live session (claude); under codex \"current\" falls back to \"last\"."
      • addedOutput schema / properties / sessions / items / properties / breakdown
        {
          "additionalProperties": false,
          "description": "X-ray of what was flattened: adaptive tool/resource rows plus byKind and bySlot groupings, each with the bytes and context tokens freed. Present on every dry run with at least one qualifying block, and on a real flatten only when breakdown=true. contextTokens are exact when tokensExact (per-group count_tokens, requiring the FLATTEN_COUNT_EXACT=1 + ANTHROPIC_API_KEY opt-in), otherwise a local estimate; they are always 0 for the toolUseResult slot (the mirror is disk-only and never in model context).",
          "properties": {
            "byKind": {
              "description": "Grouped by block kind.",
              "items": {
                "additionalProperties": false,
                "properties": {
                  "bytes": {
                    "description": "Disk bytes this group frees.",
                    "type": "number"
                  },
                  "contextTokens": {
                    "description": "Context tokens this group frees — exact when tokensExact, else estimated; 0 for toolUseResult-slot blocks.",
                    "type": "number"
                  },
                  "count": {
                    "description": "How many blocks this group holds.",
                    "type": "number"
                  },
                  "key": {
                    "description": "Block kind: \"text\", \"image\", or \"mixed\" (the group key).",
                    "type": "string"
                  }
                },
                "required": [
                  "key",
                  "count",
                  "bytes",
                  "contextTokens"
                ],
                "type": "object"
              },
              "type": "array"
            },
            "bySlot": {
              "description": "Grouped by storage slot.",
              "items": {
                "additionalProperties": false,
                "properties": {
                  "bytes": {
                    "description": "Disk bytes this group frees.",
                    "type": "number"
                  },
                  "contextTokens": {
                    "description": "Context tokens this group frees — the full contextTokensSaved on the content row, 0 on the disk-only toolUseResult row.",
                    "type": "number"
                  },
                  "count": {
                    "description": "How many blocks this group holds.",
                    "type": "number"
                  },
                  "key": {
                    "description": "Slot: \"content\" (message.content, in model context) or \"toolUseResult\" (the disk-only mirror).",
                    "type": "string"
                  }
                },
                "required": [
                  "key",
                  "count",
                  "bytes",
                  "contextTokens"
                ],
                "type": "object"
              },
              "type": "array"
            },
            "rows": {
              "description": "Adaptive tool/resource rows: MCP tools collapse per server, heavyweight resources get their own row, and the light tail folds into a single \"other\" row (at most 9 rows). Partitions the flattened blocks exactly. In deep mode each row also carries its individual blocks in .entries.",
              "items": {
                "additionalProperties": false,
                "properties": {
                  "bytes": {
                    "description": "Disk bytes this row frees.",
                    "type": "number"
                  },
                  "contextTokens": {
                    "description": "Context tokens this row frees — exact when tokensExact, else estimated; 0 for toolUseResult-slot blocks.",
                    "type": "number"
                  },
                  "count": {
                    "description": "How many blocks this row holds.",
                    "type": "number"
                  },
                  "entries": {
                    "description": "Deep mode only (breakdown=\"deep\"): the individual blocks this row aggregates, sorted by bytes desc — the per-command attribution. Absent in summary mode.",
                    "items": {
                      "additionalProperties": false,
                      "properties": {
                        "args": {
                          "description": "Short arg summary (command=…, file_path=…); \"\" when none.",
                          "type": "string"
                        },
                        "bytes": {
                          "description": "Disk bytes this block frees.",
                          "type": "number"
                        },
                        "contextTokens": {
                          "description": "Per-block net context-token estimate (local; never reconciled to the exact per-group total).",
                          "type": "number"
                        },
                        "kind": {
                          "description": "\"text\", \"image\", or \"mixed\".",
                          "type": "string"
                        },
                        "lineCount": {
                          "description": "Line count of the block's text projection.",
                          "type": "number"
                        },
                        "name": {
                          "description": "Originating tool name of this block.",
                          "type": "string"
                        },
                        "slot": {
                          "description": "\"content\" (in model context) or \"toolUseResult\" (disk-only mirror, 0 context tokens).",
                          "type": "string"
                        }
                      },
                      "required": [
                        "name",
                        "args",
                        "bytes",
                        "kind",
                        "slot",
                        "contextTokens",
                        "lineCount"
                      ],
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "key": {
                    "description": "Row key: a tool family (\"<server> (MCP)\" for MCP tools, else the built-in tool name), or \"other\" for the tail-collapsed row.",
                    "type": "string"
                  },
                  "resource": {
                    "description": "Present only on a resource-promoted row: the raw file_path/path/url value that earned this tool family its own line.",
                    "type": "string"
                  }
                },
                "required": [
                  "key",
                  "count",
                  "bytes",
                  "contextTokens"
                ],
                "type": "object"
              },
              "type": "array"
            },
            "tokensExact": {
              "description": "True when the rows' contextTokens are exact (per-group count_tokens), false when locally estimated.",
              "type": "boolean"
            }
          },
          "required": [
            "tokensExact",
            "rows",
            "byKind",
            "bySlot"
          ],
          "type": "object"
        }
      • changedOutput schema / properties / sessions / items / properties / entries / description
        Before
        "One row per flattened block (id, originating tool name, size, kind, and slot)."
        After
        "One row per flattened block — id, originating tool name, arg summary, size, kind, slot, per-block token estimate, and line count. The machine-readable per-command attribution the breakdown aggregates."
      • addedOutput schema / properties / sessions / items / properties / entries / items / properties / args
        {
          "description": "Short arg summary of the originating call (e.g. command=…, file_path=…), same grammar as the marker; \"\" when none.",
          "type": "string"
        }
      • addedOutput schema / properties / sessions / items / properties / entries / items / properties / contextTokens
        {
          "description": "Per-block net context-token estimate (local; not reconciled to the exact per-group total).",
          "type": "number"
        }
      • addedOutput schema / properties / sessions / items / properties / entries / items / properties / lineCount
        {
          "description": "Line count of the block's text projection.",
          "type": "number"
        }
      • changedOutput schema / properties / sessions / items / properties / entries / items / required
        Before
        [
          "id",
          "name",
          "size",
          "kind",
          "slot"
        ]
        After
        [
          "id",
          "name",
          "args",
          "size",
          "kind",
          "slot",
          "contextTokens",
          "lineCount"
        ]
    • Removedretrieve_flattened
    • Changedunflatten_session5 fields changed
      • addedInput schema / properties / agent
        {
          "default": "claude",
          "description": "Which agent's session store to target: \"claude\" (default) or \"codex\".",
          "enum": [
            "claude",
            "codex"
          ],
          "type": "string"
        }
      • changedInput schema / properties / claude_dir / description
        Before
        "Absolute path (or ~/...) to the Claude config dir whose sessions to target — the dir holding projects/, e.g. ~/.claude-2 for a second profile. Default: $CLAUDE_CONFIG_DIR if set (so a server running inside an alternate profile targets it), else ~/.claude."
        After
        "Absolute path (or ~/...) to the Claude config dir whose sessions to target — the dir holding projects/, e.g. ~/.claude-2 for a second profile. Default: $CLAUDE_CONFIG_DIR if set, else ~/.claude. Applies to agent \"claude\" only."
      • addedInput schema / properties / codex_home
        {
          "description": "Absolute path (or ~/...) to the Codex home whose sessions to target — the dir holding sessions/. Default: $CODEX_HOME if set, else ~/.codex. Applies to agent \"codex\" only.",
          "type": "string"
        }
      • changedInput schema / properties / project_dir / description
        Before
        "Absolute path to project. Default: the project the CLI runs in (cwd)"
        After
        "Absolute path to project. Default: the project the CLI runs in (cwd). Under codex, scopes \"last\"/keyword to rollouts whose cwd equals this dir."
      • changedInput schema / properties / session_id / description
        Before
        "Session UUID, \"last\", or \"current\" (the live session)"
        After
        "Session UUID, \"last\", or \"current\" (the live session; under codex \"current\" falls back to \"last\")"
  4. 5 tool updates
    • Changedflatten_messages1 field changed
      • changedOutput schema / (root)
        Before
        null
        After
        {
          "$schema": "http://json-schema.org/draft-07/schema#",
          "additionalProperties": false,
          "properties": {
            "contextTokensExact": {
              "description": "Always false here — the in-memory tool never makes a network call; use the library flattenMessagesExact for an exact count.",
              "type": "boolean"
            },
            "contextTokensSaved": {
              "description": "Estimated context tokens removed from the conversation.",
              "type": "number"
            },
            "extracted": {
              "description": "The originals removed from the conversation. Persist this array yourself and pass it back to unflatten_messages to restore byte-for-byte.",
              "items": {
                "additionalProperties": false,
                "properties": {
                  "content": {
                    "description": "The original tool_result value, verbatim (string or content-block array)."
                  },
                  "id": {
                    "description": "tool_use_id — the marker key used to restore this block.",
                    "type": "string"
                  },
                  "input": {
                    "additionalProperties": {},
                    "description": "Originating tool input, or {}.",
                    "type": "object"
                  },
                  "kind": {
                    "description": "\"text\", \"image\", or \"mixed\".",
                    "type": "string"
                  },
                  "lineCount": {
                    "description": "Newline count of the original text projection.",
                    "type": "number"
                  },
                  "name": {
                    "description": "Originating tool name, or \"unknown\".",
                    "type": "string"
                  },
                  "size": {
                    "description": "Serialized byte size of the original.",
                    "type": "number"
                  }
                },
                "required": [
                  "id",
                  "name",
                  "input",
                  "size",
                  "lineCount",
                  "kind"
                ],
                "type": "object"
              },
              "type": "array"
            },
            "flattenedCount": {
              "description": "How many tool_result blocks were flattened.",
              "type": "number"
            },
            "imageBlocksFlattened": {
              "description": "How many image blocks were among the flattened results.",
              "type": "number"
            },
            "messages": {
              "description": "The flattened messages[] array — safe to send — with every bulky tool_result replaced by a compact [FLATTENED id=...] marker. Deep-copied; the input is never mutated.",
              "items": {
                "additionalProperties": {},
                "type": "object"
              },
              "type": "array"
            }
          },
          "required": [
            "messages",
            "extracted",
            "flattenedCount",
            "imageBlocksFlattened",
            "contextTokensSaved",
            "contextTokensExact"
          ],
          "type": "object"
        }
    • Changedflatten_session1 field changed
      • changedOutput schema / (root)
        Before
        null
        After
        {
          "$schema": "http://json-schema.org/draft-07/schema#",
          "additionalProperties": false,
          "properties": {
            "sessions": {
              "description": "One entry per session flattened (a single entry for one session_id, or several for \"last N\").",
              "items": {
                "additionalProperties": false,
                "properties": {
                  "backupPath": {
                    "description": "Path to the single self-syncing backup holding the complete inlined session.",
                    "type": "string"
                  },
                  "contextSavingsPercent": {
                    "description": "contextTokensSaved as a percent of contextTokensTotal, or \"n/a\".",
                    "type": "string"
                  },
                  "contextTokensExact": {
                    "description": "True if counted via count_tokens, false if estimated locally.",
                    "type": "boolean"
                  },
                  "contextTokensSaved": {
                    "description": "Context tokens removed from the model context (the number that matters for --resume/compaction).",
                    "type": "number"
                  },
                  "contextTokensTotal": {
                    "description": "Real context size from the last turn API usage, or null if unknown.",
                    "type": [
                      "number",
                      "null"
                    ]
                  },
                  "diskBytesSaved": {
                    "description": "Bytes removed from the .jsonl on disk (speeds --resume parsing).",
                    "type": "number"
                  },
                  "diskSavingsPercent": {
                    "description": "diskBytesSaved as a percent of the original file size.",
                    "type": "string"
                  },
                  "dryRun": {
                    "description": "True when dry_run was set — no files were modified.",
                    "type": "boolean"
                  },
                  "entries": {
                    "description": "One row per flattened block (id, originating tool name, size, kind, and slot).",
                    "items": {
                      "additionalProperties": false,
                      "properties": {
                        "id": {
                          "type": "string"
                        },
                        "kind": {
                          "type": "string"
                        },
                        "name": {
                          "type": "string"
                        },
                        "size": {
                          "type": "number"
                        },
                        "slot": {
                          "type": "string"
                        }
                      },
                      "required": [
                        "id",
                        "name",
                        "size",
                        "kind",
                        "slot"
                      ],
                      "type": "object"
                    },
                    "type": "array"
                  },
                  "flattenedCount": {
                    "description": "How many tool results were flattened (0 on a no-op or dry run with nothing to do).",
                    "type": "number"
                  },
                  "imageBlocksFlattened": {
                    "description": "How many image/screenshot blocks were among them.",
                    "type": "number"
                  },
                  "newSize": {
                    "description": "Session file size after flattening, in bytes.",
                    "type": "number"
                  },
                  "originalSize": {
                    "description": "Session file size before flattening, in bytes.",
                    "type": "number"
                  },
                  "resumeHint": {
                    "description": "Present only when a live session was actually rewritten — reminds you to /resume to load the lighter copy.",
                    "type": "string"
                  },
                  "sessionId": {
                    "description": "The session UUID that was processed.",
                    "type": "string"
                  }
                },
                "required": [
                  "sessionId",
                  "dryRun",
                  "flattenedCount",
                  "imageBlocksFlattened",
                  "diskBytesSaved",
                  "diskSavingsPercent",
                  "contextTokensTotal",
                  "contextTokensSaved",
                  "contextSavingsPercent",
                  "contextTokensExact",
                  "originalSize",
                  "newSize",
                  "backupPath",
                  "entries"
                ],
                "type": "object"
              },
              "type": "array"
            }
          },
          "required": [
            "sessions"
          ],
          "type": "object"
        }
    • Changedretrieve_flattened1 field changed
      • changedOutput schema / (root)
        Before
        null
        After
        {
          "$schema": "http://json-schema.org/draft-07/schema#",
          "additionalProperties": false,
          "properties": {
            "kind": {
              "description": "\"text\", \"image\", or \"mixed\".",
              "type": "string"
            },
            "line_count": {
              "description": "Line count of the original text projection.",
              "type": "number"
            },
            "original_size": {
              "description": "Byte size of the original content.",
              "type": "number"
            },
            "slot": {
              "description": "\"content\" (message.content) or \"toolUseResult\" (the disk mirror).",
              "type": "string"
            },
            "tool_name": {
              "description": "Originating tool name of the retrieved result.",
              "type": "string"
            },
            "tool_use_id": {
              "description": "The tool_use_id that was retrieved.",
              "type": "string"
            }
          },
          "required": [
            "tool_use_id",
            "tool_name",
            "original_size",
            "line_count",
            "kind",
            "slot"
          ],
          "type": "object"
        }
    • Changedunflatten_messages1 field changed
      • changedOutput schema / (root)
        Before
        null
        After
        {
          "$schema": "http://json-schema.org/draft-07/schema#",
          "additionalProperties": false,
          "properties": {
            "messages": {
              "description": "The restored messages[] array, byte-for-byte identical to the pre-flatten conversation. Any [FLATTENED id=...] marker with no matching extracted entry is left in place.",
              "items": {
                "additionalProperties": {},
                "type": "object"
              },
              "type": "array"
            }
          },
          "required": [
            "messages"
          ],
          "type": "object"
        }
    • Changedunflatten_session1 field changed
      • changedOutput schema / (root)
        Before
        null
        After
        {
          "$schema": "http://json-schema.org/draft-07/schema#",
          "additionalProperties": false,
          "properties": {
            "backupPath": {
              "description": "The backup that was restored from (and removed on a full restore).",
              "type": "string"
            },
            "newSize": {
              "description": "Session file size after restoring, in bytes.",
              "type": "number"
            },
            "notFound": {
              "description": "Marker ids that had no matching backup entry and were left in place.",
              "items": {
                "type": "string"
              },
              "type": "array"
            },
            "originalSize": {
              "description": "Session file size before restoring, in bytes.",
              "type": "number"
            },
            "restoredCount": {
              "description": "How many flattened tool results were re-inlined.",
              "type": "number"
            },
            "sessionId": {
              "description": "The session UUID that was processed (\"\" when nothing matched).",
              "type": "string"
            },
            "skipped": {
              "description": "Present with a reason when the restore was skipped (e.g. no backup to restore from).",
              "type": "string"
            }
          },
          "required": [
            "sessionId",
            "restoredCount",
            "notFound",
            "originalSize",
            "newSize",
            "backupPath"
          ],
          "type": "object"
        }

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct operation: flatten_session for session files, flatten_messages for in-memory arrays, unflatten_messages for reversing in-memory, and retrieve_flattened for retrieving backed-up content. No overlap in purpose.

Naming Consistency5/5

All tool names follow a verb_noun pattern (e.g., flatten_session, unflatten_messages, retrieve_flattened). The pattern is consistent and predictable.

Tool Count5/5

Four tools is well-scoped for the domain of conversation flattening and restoration. Each tool serves a specific need without unnecessary duplication.

Completeness3/5

The set covers flattening and in-memory restoration, but misses an explicit unflatten_session tool, which is referenced in flatten_session's description as reversible. This gap may force agents to adapt.

Maintenance

ActivityActive
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

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