This server acts as a persistent context ledger and flight recorder for AI coding agents. Key capabilities:
Lossless file reading: Single or batch (up to 50) reads with deduplication (full content, unchanged markers, or diffs), symbol/line-range extraction, and forced full content.
Context restoration: After compaction, restore the working set from disk with budget capping and change annotations.
Working set overview: Heat-ranked list of files the agent has seen, with staleness info.
Structural outline: Cheap structural map (declarations) of a file for navigation.
Forensic analysis: context_blame reveals every version of a file shown to the model and co-context at any moment.
Context packs: Export deterministic, cache-friendly packs for subagent system prompts to reduce token costs.
Metering: Token and USD cost breakdown per session, including deduplication savings.
Receipts: Issue and verify HMAC-SHA256-signed, git-bound attestations of everything the model saw.
Hook integration: Automatically captures file versions and guards against blind edits.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lossless-context-mcp show my token usage per repo for this session"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The flight recorder for your agent's context. A persistent, hook-fed ledger of every file version your coding agent was shown — so a compaction can't destroy the working set, a subagent fleet doesn't pay for the same files N times, and you can prove afterward exactly what the model saw.
┌──────────────────────┐
ledger reads ──────▶│ │──▶ RESTORE working set survives /compact
(read_file, MCP) │ flight recorder │──▶ PACKS one cache-cached prefix for a fan-out fleet
transcript sweeps ─▶│ (content-addressed │──▶ RECEIPTS signed, git-bound "what did it see"
(native Read/Edit) │ archive on disk) │──▶ METERING where the read tokens went, in dollars
└──────────────────────┘Compaction destroys your agent's working set. Not anymore — sweep at PreCompact, manifest injected after, blind edit blocked, working set restored, edit allowed:
Two agents, one file — air traffic control. The second agent is stopped mid-clobber, with the culprit named:
Every line in these recordings is genuine output from the shipped code — the demos are
generated by docs/demo/make-demo.mjs, which drives the real
hooks and server and renders what they actually said. Re-run it yourself.
Related MCP server: V.I.S.O.R.
When Claude Code compacts, roughly two-thirds of a typical context is tool output — mostly file contents — and compaction discards it permanently. The model then flails: re-reading files it half-remembers, or worse, guessing at contents it no longer has (#27242 is the ask, at 80 👍).
The flight recorder closes the loop automatically:
PreCompact — the sweep hook parses the session transcript and archives every file
the session touched (native Read/Edit/Write included, not just MCP reads), then
writes a ranked working-set manifest. Fast enough to sit on the compaction path — one
real 14 MB transcript swept in 361 ms; measure yours:
node bench/sweep-bench.mjs <transcript.jsonl>.
SessionStart(compact) — the inject hook puts a compact manifest back into the fresh context: "your working set was these 12 files (edited ones first); restore any of them instead of guessing."
restore_context — re-emits the working set from current disk state,
budget-capped, annotating any file that changed since the model last saw it.
Cross-session memory tools (claude-mem and friends) summarize what happened for the next session. This is the complementary, mid-session layer: file-version-exact recovery of what you were just working on.
The recorder knows exactly which file versions the model has actually seen this context
epoch. A PreToolUse hook uses that to stop the two ugliest edit failures before the
write lands:
Post-compaction guess-edits — the model edits a file it hasn't read since its context was compacted/reset, working from a summary's memory of the content. (The harness's own read-before-edit tracking is not documented to survive compaction, and newer models are allowed to edit unread files at all.) Denied, with a one-line reason the model sees: read it (or restore_context), then retry. Self-healing — costs exactly one extra read.
Stale-base edits — the file changed on disk since the model read it (another agent, you, a formatter). Content-hash compared, not mtime-guessed. Denied with the same re-read instruction.
Fail-open by construction: any doubt (unparseable transcript, partial reads, files the
model itself just edited, oversized files) → the edit proceeds untouched. Disable
anytime with LOSSLESS_GUARD=off.
Run two agent sessions on one repo and they clobber each other blind: B edits a file A read ten minutes ago; A edits from its stale copy; the merge is garbage and neither notices. Nothing on the market mediates this locally — but the recorder already knows, per session, what each agent holds and edits. v2 makes that knowledge active:
Edit-in-flight detection — when one agent process is allowed an edit, it publishes
an intent to a local presence plane (~/.lossless-context/presence/, one file per
process, no daemon, no locks). Another agent editing the same file seconds later is
denied with the culprit named: "agent session 3f2a91b0 started an edit on this file
12s ago and it may not have landed yet." Covers sibling subagents of the same
session too.
Cross-session stale-base detection — when another session's landed edit postdates what your session holds and your last contact left no verifiable hash, the edit is denied with a re-read instruction. When the ordinary drift check fires, the reason now names who changed the file.
The radar — coordination_status shows every visible agent session, what it's
been editing, and which files have cross-session or in-flight activity.
Honest limits: advisory, not locking. Sessions without the hooks are invisible, a
same-second race can still slip through, and presence files are unauthenticated local
JSON — any local process could fabricate one to cause false denies (structurally never
a false allow; presence can only add deny classes). An intent whose edit is then declined
at the permission prompt lingers up to LOSSLESS_COORD_INTENT_SECS (90 s) before
expiring. It substantially narrows the concurrent-clobber window; it cannot close it, and
how much it catches in practice is not yet measured. LOSSLESS_COORD=off disables
coordination independently of the guard. (The guard's compaction tracking is
session-scoped; only the dedup engine uses the machine-global epoch file, where a
cross-session bump merely costs one conservative full re-send.)
Fan-outs are where token waste actually lives. Measured across 195 real multi-agent runs:
19.6% of all subagent Read tokens were duplicate reads of identical content by sibling
agents (5.18M of 26.4M tokens) — every sibling starts cold and reads the same CLAUDE.md,
the same spec, the same core modules.
export_pack ranks the archive's cross-session read history for stable hot files and
renders them as one deterministic block for a custom agent-type's system prompt. The
block is a stable prefix, so the whole fleet hits the provider prompt cache on it. On a
real review fan-out this measured 46.55% cheaper than baseline — and the same pack
injected per-task measured 19.6% worse (every sibling cache-writes it), which is why
the tool tells you where to put it. Both numbers were measured externally on one real
corpus, not by a harness in this repo — exact figures, method, and that caveat are in
BENCHMARK.md. Generate the pack once per run and embed it verbatim:
ranking follows live read history, so repeated export_pack calls can differ.
context_blame (also a CLI: lossless-context-mcp blame <path>) answers the debugging
question every agent incident report wishes it could: for a given file, every content
version the model was shown (SHA-256 + git blob SHA-1, first/last seen, capture source,
sessions) and what else was in context around a chosen moment. When an agent produces a
wrong change, you query the recording instead of arguing with the agent's self-report.
Observability vendors capture what your agent read into mutable trace stores. Nobody signs it or binds it to repo identity — and agent self-reports are not evidence (ask anyone whose agent claimed it "verified" something it never read).
context_receipt issues an HMAC-SHA256-signed attestation: every file/view shown, the
SHA-256 of every content version, the git blob SHA-1 of each version (so any verifier
with a clone can check git cat-file -e <sha1> — was this ever committed?), repo HEAD
at issue time, delivery kinds, token totals, and an explicit coverage statement of
which capture paths it attests (mcp, and transcript-sweep with include_sweep). By
default it signs with the same key file as trust-mcp receipts, so one key verifies a full
evidence chain: what the agent saw + what it did.
The honest scope: a receipt attests what passed through the ledger and sweeps — it
never claims coverage of unmediated paths, and says so in its own coverage.note.
context_stats shows where the session's file-read tokens went — per repo, per file, in
dollars, counted with a real tokenizer.
Reality check, kept from earlier versions because it's true: as an intra-session token saver this measures ~0% on real Claude Code transcripts (+0.4% with the never-lose engine; the native file-state cache already ate the opportunity — full data in BENCHMARK.md). The savings that DO exist are cross-agent (packs, above). Read-path dedup remains because it is provably lossless and never negative — not because it will save you much on its own.
npm i -g lossless-context-mcp
lossless-context-mcp init # wires all hooks into ~/.claude/settings.json
claude mcp add lossless-context --scope user -- lossless-context-mcpinit is idempotent (re-run it after upgrades — it updates paths instead of
duplicating), backs up your settings file first, refuses to touch a settings file it
can't parse, and never removes hooks that aren't its own. --dry-run previews. It wires:
sweep-transcript.mjs (PreCompact + SessionEnd) — captures the working set + exact
versions; bumps the dedup epoch on PreCompact; never blocks compaction.
inject-manifest.mjs (SessionStart, matcher compact) — injects the recovered
working-set manifest after a compaction.
reset-epoch.mjs (SessionStart) — keeps read dedup lossless across new sessions.
guard-edit.mjs (PreToolUse, Edit|Write|MultiEdit) — the blind-edit guard
(LOSSLESS_GUARD=off disables without unwiring).
Restart Claude Code after init. Without the hooks everything still works — you just lose automatic native-tool capture, post-compaction injection, and the guard; the ledger then records MCP reads only.
Tool | What it does |
| Lossless read: full / unchanged-marker / diff. Optional single- |
| A working set in one call; per-file errors don't fail the batch. |
| Heat-ranked table of what the recorder knows this session (+ last 24h), with staleness vs disk. |
| Re-emit the working set after compaction — manifest top-K by default, budget-capped, change-annotated. |
| Deterministic fan-out context pack from cross-session read history, for an agent-type system prompt. |
| Forensics: every version of a file the model was shown, plus co-context around a moment. Also: |
| The radar: visible agent sessions, their recent edits, cross-session and in-flight files. |
| Cheap structural map of a file (declarations only). |
| Token/dollar breakdown of this session's reads. |
| Signed, git-bound context receipt with explicit coverage. |
| Timing-safe, canonicalized verification. |
The archive lives at ~/.lossless-context/archive (override: LOSSLESS_CONTEXT_DIR),
content-addressed, capped at 512 MiB (LOSSLESS_ARCHIVE_BYTES) with LRU eviction; event
logs age out after 30 days (LOSSLESS_EVENTS_DAYS). Nothing ever leaves your machine.
Files matching secret patterns (.env*, keys/certs, .ssh/.aws paths, credentials —
plus your own LOSSLESS_ARCHIVE_EXCLUDE globs) are never stored — the check covers
both the requested path and its resolved real path, so a symlink to a secret doesn't
bypass it. For excluded files only the path, touch counts, and timestamps are recorded
(no content, and no content-derived metadata like hashes or sizes, which could enable
offline confirmation of low-entropy secrets).
The engine only withholds or diffs content it can prove the model still has, bounded by context epochs (the hooks bump the epoch on compaction, so post-compaction reads are always full). A 400-op randomized invariant test asserts the model's reconstructable view equals disk truth after every operation. Anything less provable is sent in full.
Restore serves current disk state (annotated when it drifted), not a time machine of the conversation; exact historical versions live in the archive for receipts.
The transcript format is internal to Claude Code and can change; the sweep is deliberately two-tier (stable-surface discovery + best-effort exact capture) and fail-silent — a format change degrades capture, never breaks a session.
Receipts attest mediated paths only, and say so; they are HMAC (shared-key), not third-party-verifiable signatures — Ed25519 receipts are a candidate for a future version if anyone needs them.
Pack effectiveness assumes provider prompt caching and a stable prefix; the 46.55% figure is one measured workload, not a promise.
Symbol extraction is a heuristic brace/indent pass, not a parser (tree-sitter was evaluated and deferred for WASM/ABI fragility).
v2.0.0 — the coordination plane, on top of the full flight recorder: persistent
content-addressed archive, transcript sweep + manifest inject hooks, working-set
restore, fan-out packs, git-bound receipts v2, one-command init, the blind-edit
guard, context blame, and cross-agent coordination (in-flight intents, landed-edit
conflicts, the coordination_status radar). 121 tests green including the losslessness
invariant; over-the-wire smoke covers sweep → inject → restore → guard → coordination →
receipts; real-transcript sweep and guard runs validated on live data. MIT.
Issue an HMAC-SHA256-signed context receipt for this session: every file/view the model was shown, the SHA-256 of each content version, how it was delivered (full/diff/unchanged), and token totals. The auditable answer to "what did the AI see when it did this?". Signs with LOSSLESS_RECEIPT_KEY or the shared trust key file, so it verifies with the same key as trust-mcp receipts. Verify later with verify_context_receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| artifact | Yes | What this context evidence is for (repo, ticket, deploy, session id). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it signs with HMAC-SHA256 using specific keys and that the receipt verifies with the same key. It does not describe return format, side effects, or error cases (e.g., missing key), but the core signing behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but slightly long—four sentences covering purpose, contents, signing mechanism, and verification. All sentences add value and are front-loaded with the core action. No wasted words, though it could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (signing, key management, verification), and the description covers the key aspects: what it signs, how it signs, and how to verify. It lacks an explicit return-value description (no output schema exists), but the purpose and integration with verify_context_receipt make the context complete enough for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for the 'artifact' parameter; it mentions 'for this session' but does not elaborate on how to choose artifact values. This is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Issue') and resource ('HMAC-SHA256-signed context receipt'), listing exactly what it contains (files/views, SHA-256 hashes, delivery modes, token totals). It clearly distinguishes itself from siblings by describing the receipt generation role and pointing to 'verify_context_receipt' for verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by framing it as 'the auditable answer to what did the AI see when it did this?' and mentions verification with a sibling tool. It does not explicitly state when not to use it or compare to context_stats, but the purpose is clear enough for an agent to select it for audit needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where did this session’s file-read tokens go? Totals, per-repo breakdown, heaviest files, dedup savings, and a USD estimate (LOSSLESS_PRICE_PER_MTOK, default $3/MTok input). Counted with a real tokenizer on exactly what this server sent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals methodology ('real tokenizer'), scope ('exactly what this server sent'), and the price assumption (LOSSLESS_PRICE_PER_MTOK, default $3/MTok). It does not explicitly state read-only safety, but the nature of stats reporting makes that implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with an engaging question, and each clause adds substantive detail (breakdown types, pricing, tokenizer). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description fully specifies what is reported and how it is computed. The agent can infer the return types (counts, USD amounts, file paths) and the scope (session file-read tokens) without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description need not explain parameters. It adds context about an environment variable (LOSSLESS_PRICE_PER_MTOK) which is relevant to the output, exceeding the schema's empty property list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Where did this session’s file-read tokens go?' and enumerates specific outputs (totals, per-repo breakdown, heaviest files, dedup savings, USD estimate). This makes it distinct from the sibling tools, which focus on reading files or context receipts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for analyzing file-read token consumption within the current session. It does not explicitly mention alternatives or when-not-to-use, but the purpose is self-evident and adequately guides selection among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a cheap structural outline of a file: declaration lines (functions, classes, types, methods) with line numbers, bodies elided. Use this to navigate a large/unknown file before reading specific parts with read_file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to outline. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the outline is 'cheap' and specifies the output (declaration lines, line numbers, bodies elided), implicitly indicating a read-only, non-mutating operation. It doesn't cover error handling or permissions, but provides strong behavioral detail for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function followed by usage guidance. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description sufficiently explains the return value (declarations, line numbers, bodies elided) and the intended use case. It is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single 'path' parameter. The tool description adds usage context but no additional parameter format or syntax details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a structural outline of a file, listing declaration lines with line numbers and bodies elided. It distinguishes itself from sibling read_file by explicitly positioning itself as a pre-navigation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this to navigate a large/unknown file before reading specific parts with read_file.' This names the exact scenario and the alternative tool, making the conditional use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a text file through the context ledger. The FIRST read of a file/view (or the first after a context compaction) returns full content. A later read of an UNCHANGED view returns a short "reuse what you have" marker. A later read of a CHANGED view returns a unified DIFF to apply to the copy you already have. Optionally read just one symbol (function/class by name) or a line range instead of the whole file. All dedup is lossless: it only diffs/withholds content it can prove you still have. Every read is metered (see context_stats) and attested in the signed context receipt. Pass force_full:true for the whole content regardless.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file to read (absolute, or relative to the server cwd). | |
| lines | No | Return only this 1-based inclusive line range, e.g. "40-90". | |
| symbol | No | Return only this function/class/type by name (heuristic brace/indent extraction). | |
| force_full | No | Return full content even when a diff or unchanged-marker would suffice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and exceeds expectations. It discloses the deduplication algorithm, lossless property, metering, signed receipt, and the exact semantics of force_full. It also clarifies that a later read returns either a marker or a diff, giving the agent a complete mental model of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but information-dense. Every sentence adds value, from the initial purpose to the lossless guarantee and force_full option. The structure front-loads the core purpose, then explains edge cases, and ends with a concrete override—logical and easy to parse, though not as terse as the highest-caliber examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of an output schema, the description is thorough enough. It specifies return behavior for every scenario (full content, marker, diff) and mentions integration points like context_stats and signed receipts. The agent can confidently select and invoke this tool without needing further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the schema already covers all four parameters, the description adds extra meaning: it explains that 'lines' is a 1-based inclusive range, 'symbol' uses heuristic extraction, and force_full overrides the diff mechanism. This goes beyond the schema's dry parameter names and enriches the agent's understanding of when each parameter is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read a text file through the context ledger.' It specifies the resource (text file) and the verb (read), and uniquely distinguishes itself from siblings like read_files by detailing the deduplication/diff behavior and optional symbol/line-range reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on behavior under different conditions (first read vs. later reads, unchanged vs. changed views) and explains when to use options like symbol, lines, and force_full. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a working set of text files in one call, each through the same lossless ledger as read_file (full on first contact, unchanged-marker or diff on re-reads). One call for N files instead of N calls. Per-file errors are reported inline without failing the batch.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Files to read, in order. | |
| force_full | No | Return full content for every file regardless of ledger state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the lossless ledger behavior (full first, diff on re-reads) and per-file error handling without failing the batch. This gives agents a solid expectation of output and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by behavioral details. Every clause earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the key behaviors (ledger, error isolation) enough for an agent to predict the call's effect. Minor lack of explicit return format or ordering, but sufficient given the tool is a batch variant of read_file.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both paths and force_full, so parameters are already well-documented. Description adds general batching context but no extra semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly it reads a working set of text files in one call, with a specific verb and resource. Explicitly distinguishes from sibling read_file by contrasting 'one call for N files' vs 'N calls'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for batch reading multiple files and contrasts with the alternative of making N calls. Doesn't explicitly say 'use read_file for a single file' but the contrast implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a context receipt + signature pair against the local receipt key (timing-safe, canonicalized so JSON field order does not matter).
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | The receipt object exactly as returned by context_receipt. | |
| signature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses two meaningful traits: 'timing-safe' and 'canonicalized so JSON field order does not matter', which are security-relevant. It stops short of 5 because it does not describe the return value or failure behavior (e.g., boolean vs exception) for an invalid signature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action, inputs, and two important behavioral caveats without any filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description should ideally indicate what the verification returns or whether it throws on failure. The description omits this, but the security details and clear purpose provide enough context to push it above a minimal score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the receipt parameter as 'exactly as returned by context_receipt', which is helpful. The signature parameter is only typed as string with no description. The tool description adds value by noting that canonicalization makes field order irrelevant for the receipt JSON, but it does not clarify the signature's format, encoding, or how it is obtained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Verify' against a 'context receipt + signature pair', clearly distinguishing it from sibling tools like context_receipt (creation) and read_file (reading files). Mentioning 'local receipt key' adds precision about the verification target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action 'Verify' clearly implies this tool is for validating a receipt+signature pair, so usage context is evident. However, it does not explicitly state when not to use it or mention alternatives such as context_receipt for creating receipts, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.3context_receiptcontext_statsoutlineread_fileread_filesverify_context_receiptEach tool has a clearly distinct purpose: single-file read, batch read, structural outline, usage statistics, receipt creation, and receipt verification. The only overlapping pair is read_file/read_files, but the plural and description make the batch distinction unambiguous.
The naming is mostly predictable but mixes verb-led tools (read_file, read_files, verify_context_receipt) with noun-led tools (outline, context_stats, context_receipt). The underscore convention is consistent, but the lack of a uniform verb_noun pattern is a minor deviation.
Six tools is well-scoped for a file-context ledger server, covering reading, outlining, batching, statistics, and audit without unnecessary bloat or obvious omissions.
The server covers the full intended workflow: navigate with outline, read with read_file/read_files, monitor usage with context_stats, and audit with context_receipt/verify_context_receipt. No critical operations are missing for its stated purpose.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Read-only Remote MCP for externally grounded AI agent trust receipts.
A paid remote MCP for Context7 MCP docs, built to return verdicts, receipts, usage logs, and audit-r
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/NORTHTEKDevs/lossless-context-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
