TokenMizer is a local AI proxy that manages conversational context through graph-backed memory, checkpointing, intelligent compression, and file analysis across various LLMs.
Checkpoint a session — Save the current AI session to graph memory with an optional note for later retrieval.
Resume a previous session — Retrieve a token-efficient summary of a prior session at configurable detail levels: critical (~100 tokens), standard (~300 tokens), or full (~600 tokens).
Inspect graph stats — View the knowledge graph for a session, including counts of tracked tasks, decisions, files, and errors.
Analyze large files — Process CSV, Excel, PDF, or JSON files into a compact summary (~300–500 tokens) tailored to an optional query and configurable token budget, instead of pasting raw content into the chat.
Track token savings — View analytics on tokens saved today or this week across all sessions.
Transparent LLM proxy — Acts as a local proxy for popular LLMs (Claude, GPT, Gemini, Ollama), applying a multi-layer pipeline of file intelligence, compression, semantic caching, and graph memory to reduce token usage and preserve context.
Acts as a proxy for Google Gemini, applying compression, semantic caching, and memory graph features to reduce token consumption and maintain conversational context.
Supports proxying requests to Ollama's locally hosted models, with the same pipeline of compression, caching, and graph memory for efficient and persistent AI interactions.
Provides an OpenAI-compatible proxy endpoint that adds compression, semantic caching, and graph-based memory to any OpenAI model, reducing token usage and enabling session persistence.
Every AI session has a context limit. When you hit it, the model forgets every decision and every rationale built over hours of work, and you spend the first ten minutes of the next session re-explaining the project.
Summarising the history does not fix this. A summary tells you what was decided; it loses why, and it loses what was rejected — so the model happily re-proposes the thing you moved off three sessions ago.
Related MCP server: Hippocampus
TokenMizer is a local proxy between your app and any LLM. Every request passes through a pipeline that builds a live knowledge graph, compresses inputs, caches responses, and checkpoints before the context runs out.
flowchart LR
App["Your app<br/><sub>OpenAI-compatible client</sub>"]
subgraph TM["TokenMizer :8000"]
direction TB
L0["<b>L0</b> File intelligence"]
L1["<b>L1</b> Prompt compression"]
L2["<b>L2</b> Terse-output injection"]
L4["<b>L4</b> Graph memory<br/><sub>extract → window → inject</sub>"]
L3["<b>L3</b> Semantic cache"]
L5["<b>L5</b> Provider prompt cache"]
L0 --> L1 --> L2 --> L4 --> L3 --> L5
end
LLM["Claude · GPT · Gemini<br/>Grok · DeepSeek · Ollama"]
DB[("SQLite<br/><sub>graph · checkpoints · ownership</sub>")]
App -->|"POST /v1/chat/completions"| TM
TM --> LLM
LLM -.->|response| TM
TM -.->|"response + savings"| App
L4 <-->|"per-row, locked"| DBThe graph is not a summary. It is typed nodes and edges — decisions, tasks, files, errors, goals — with a lifecycle, so a decision that gets replaced is marked superseded rather than deleted. The resume block is a filtered projection of it: active decisions, open work, unresolved errors, in a few hundred tokens.
→ Architecture — the request sequence, the data model, and the decision lifecycle.
pip install "tokenmizer[anthropic,cache]"
export TOKENMIZER_ANTHROPIC_API_KEY=sk-ant-...
tokenmizer serveThen change one line in your client:
from openai import OpenAI
client = OpenAI(
api_key="your-key",
base_url="http://localhost:8000/v1", # ← only this changes
)
resp = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{"role": "user", "content": "Continue where we left off"}],
extra_body={"session_id": "my-project"}, # ← optional, enables memory
)Everything else is unchanged: same request shape, same response shape,
plus a tokenmizer block reporting what was saved.
Windows (PowerShell)
$env:TOKENMIZER_ANTHROPIC_API_KEY = "sk-ant-..." # this session
setx TOKENMIZER_ANTHROPIC_API_KEY "sk-ant-..." # persistentNo API key? Ollama runs locally and free:
ollama pull llama3
pip install tokenmizer
# then set `provider: ollama` in tokenmizer.yamlDocker
docker compose up -dFull installation notes, every provider's environment variable, and the configuration reference are in docs/configuration.md and docs/deployment.md.
Three ways in, depending on where you work. All three talk to the same graph, so a session checkpointed from Claude Code resumes in the CLI.
/plugin marketplace add Shweta-Mishra-ai/tokenmizer
/plugin install tokenmizer@Shweta-Mishra-ai/tokenmizerThen, in any session:
/tokenmizer:checkpoint my-project save the session to graph memory
/tokenmizer:resume my-project load it back (~300 tokens)
/tokenmizer:analyze data/sales.csv digest a large file
/tokenmizer:stats token savings report{
"mcpServers": {
"tokenmizer": {
"command": "tokenmizer-mcp",
"env": { "TOKENMIZER_URL": "http://localhost:8000" }
}
}
}Client | Where that goes |
Claude Desktop (macOS) |
|
Claude Desktop (Windows) |
|
Claude Code |
|
Cursor | Settings → MCP → Add server, same JSON |
VS Code / Zed | their MCP settings, same |
Codex CLI |
|
Restart the client afterwards. Keep tokenmizer serve running for the
checkpoint, resume, stats and reasoning tools; file analysis works
without it. If tokenmizer-mcp is not on your PATH, use
"command": "python", "args": ["-m", "tokenmizer.mcp.server"].
Six tools: checkpoint_session, resume_session, get_graph_stats,
get_savings_stats, analyze_file, and why_decision — ask your agent
"why did we pick X?" and it walks the supersession chain with the
reason and evidence for each hop.
Any OpenAI-compatible client works by pointing base_url at
http://localhost:8000/v1, as in the quick start above. That covers
Continue.dev, Aider, LangChain, LlamaIndex, the OpenAI SDKs in every
language, and curl.
→ API & CLI reference — every endpoint, every command, every MCP tool.
Goal: Build FastAPI auth service with JWT + PostgreSQL
Done: Project setup | User model | Login endpoint | Fix 422 | 18 tests passing
In progress: Refresh token rotation
Decided: PostgreSQL (concurrent writes) | bcrypt | Redis for refresh tokens
Changed: ~~React~~ → Next.js (better SEO)
Files: api/auth.py, api/models.py, config.py
Continue: Implement token refresh endpointA few hundred tokens in place of the whole conversation. The Changed:
line is the part a summary loses — and asking
GET /api/graph/{session}/why?q=react replays the full chain with the
trigger, the reason and the evidence for each hop.
python -m benchmarks.eval scores extraction against a labelled corpus
of 14 sessions, 6 of them real transcripts:
Category | Precision | Recall | F1 |
Files | 98% | 100% | 99% |
Pending tasks | 100% | 90% | 95% |
Errors | 96% | 96% | 96% |
Decisions | 90% | 95% | 92% |
Completed tasks | 92% | 90% | 91% |
macro F1 | 95% |
Precision is reported, not just recall. An extractor that emits the whole transcript as one node scores 100% recall, which is why recall-only extraction numbers should be distrusted — including our own earlier ones.
Scored separately by origin, because hand-written fixtures are easier than real transcripts and a single headline hides that: synthetic 96%, real 90%. Treat 90% as the number that describes real sessions. n=14 is a small sample and the same person wrote every label.
Independently verified against 7 other methods. A separate 100-session benchmark (tokenmizer-research, a different corpus and scorer than the numbers above) ties TokenMizer 0.5.4 for first place at 60% macro F1 — level with Mem0-style (60%) and Graphiti-style (59%), ahead of GraphRAG-style (44%), MemGPT-style (35%), and every naive baseline (≤20%). Decisions and errors are still its weakest categories relative to the two methods it ties overall — 59%/44% F1 against 65%/66% for Graphiti/Mem0-style, up from 50%/36% in 0.5.3 after a fix (see CHANGELOG) targeted at the specific gaps that benchmark found.
→ Benchmarks — memory quality against a plain-summary baseline, storage, and how to score your own sessions.
Why not just use Git history? Git stores what changed, not why you decided to change it. You can't ask Git "what did we decide about auth?" or "why did we switch from MySQL to PostgreSQL?" TokenMizer stores decisions with trigger, reason, and evidence — not diffs.
Why not RAG (retrieval-augmented generation)?
RAG retrieves relevant chunks — it doesn't model decision state. If you switched from bcrypt to Argon2 mid-session, RAG might retrieve both and confuse the model about which is current. TokenMizer tracks decision supersession explicitly: the old decision is marked SUPERSEDED, the new one ACTIVE, and the resume context only includes current state.
Why not a plain summary at the start of each session? Summaries lose structure. You can't query "all superseded decisions" or "what triggered the auth change" from a blob of text. Our benchmark shows graph memory preserves 89% of labelled information against 79% for a summary baseline — +10 points — and unlike a summary, the graph is queryable, editable, and grows incrementally instead of being re-summarized every turn. See Benchmarks.
Why not Mem0 or Zep? Mem0 and Zep store facts ("user prefers Python"). TokenMizer stores decisions with rationale — the full causal chain: what was decided, what replaced it, why, what evidence triggered the change. If you need "remember my name across sessions," use Mem0. If you need "remember that we switched from PostgreSQL to SQLite because of cost, and here's the evidence," use TokenMizer.
Why not just a longer context window? Longer context means higher cost, slower inference, and attention dilution on long histories. TokenMizer compresses a session into a resume block averaging 161 tokens (measured, n=3 — see Benchmarks) by extracting what actually matters, not by summarizing.
Two settings are accepted by the config and do nothing. They are listed here rather than left to be discovered:
Setting | Status |
| No implementation. |
| Accepted and unused. |
| Accepted (the request body isn't validated against a strict schema, so a standard OpenAI client sending them never gets a 422) but not forwarded to any provider. The model responds with no knowledge of the tools it was given. Logs a warning server-side per request. |
Request pipeline, graph data model, decision lifecycle, file intelligence | |
Every setting, environment variables, precedence, providers | |
Endpoints, commands, MCP tools, Claude Code integration | |
Docker, multiple workers, durability, session isolation, security | |
Extraction quality, memory quality, storage, running your own | |
Mem0, Zep, longer context windows, running alongside other token tools, and the roadmap | |
Setup, layer rules, and how to improve extraction | |
How to run the suite, the coverage floor, and known limits of the local audit scripts | |
Release history and how to report a vulnerability |
git clone https://github.com/Shweta-Mishra-ai/tokenmizer
cd tokenmizer
pip install -e ".[dev]"
pytest tests/ -q && ruff check tokenmizer/ # 664 tests, must stay greenThe most valuable contribution is a session where extraction got it
wrong. The eval corpus is 14 sessions and the same person wrote every
label in it — that is the honest ceiling on what the numbers above can
tell you about your workload, and the only way past it is transcripts
nobody here wrote. Label a few of your own in the format documented in
benchmarks/eval/corpus.py and open a PR,
or open an issue
with the turn that was missed. Redact freely — the shape of the prose is
what matters, not its content.
CONTRIBUTING.md covers setup, the layer rules, and how to run the eval harness.
Thanks to everyone who has sent a fix upstream:
@0xfroOty — negated-decision handling in the decision tracker (#22), OutputTrimmer level alignment (#25), streaming cache-hit analytics (#31)
@pollychen-lab — graph node IDs derived from stored (truncated) labels (#21), semantic-opposite decision detection (#26)
@floze-the-genius — dashboard stats authentication fix (#35)
If TokenMizer is useful to you, please give it a ⭐ star. It takes a second and it genuinely helps.
Sponsorship is open too, if you would like to support the work. Entirely optional.
MIT © Shweta Mishra
Analyze a large file (CSV, Excel, PDF, JSON) and return a token-efficient summary. Instead of pasting thousands of rows into the chat, use this to get schema, statistics, and sample data in ~300-500 tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | What you want to know about the file (improves relevance) | |
| file_path | Yes | Absolute path to the file to analyze | |
| token_budget | No | Max tokens for the summary (default: 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the tool's token efficiency (~300-500 tokens) and what the summary includes (schema, statistics, sample data). No contradiction detected.
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 purpose and benefit, no redundancy. Every sentence 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?
For a tool with 3 parameters and no output schema, the description adequately explains the return format (schema, statistics, sample data) and token efficiency. Minor gap: no mention of error handling or prerequisites.
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%, but the description adds value by explaining the 'query' parameter improves relevance and the 'token_budget' parameter is for max tokens. This goes beyond the schema's bare descriptions.
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 a specific verb 'analyze' with a resource 'large file' and lists supported file types (CSV, Excel, PDF, JSON). The sibling tools are unrelated, so differentiation is clear.
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 explicitly states a use case: 'Instead of pasting thousands of rows into the chat, use this...' It implies when to use but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current AI session to TokenMizer's graph memory. Creates a checkpoint that can be resumed later with full context. Use this when: finishing a work session, before switching tasks, or when the conversation is getting long.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Unique identifier for this session (e.g. 'my-project-auth') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the destination ('graph memory') and the checkpoint nature, but does not mention side effects, permissions, or response behavior. Adds some context but lacks depth.
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?
Three sentences with zero redundancy. Each sentence serves a purpose: action, benefit, and usage scenarios. Well-structured and front-loaded.
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 simple one-parameter tool without output schema, the description covers what it does and when to use it. It could mention return/confirmation behavior, but overall it is complete enough for the tool's 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?
Schema coverage is 100% with a clear example ('my-project-auth'), so the description need not add parameter details. It does not, and the baseline of 3 is appropriate since the schema already documents the parameter.
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 specific verbs 'Save' and 'Creates a checkpoint', clearly identifies the resource ('current AI session to TokenMizer's graph memory'), and distinguishes itself from the sibling resume_session by focusing on saving vs resuming.
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?
Explicitly lists three use cases ('finishing a work session, before switching tasks, or when the conversation is getting long'), providing clear context. However, it does not mention alternatives or when-not-to-use, though the sibling resume_session implies complementarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See the knowledge graph stats for a session: how many tasks, decisions, files, and errors are tracked.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the tool reads stats (non-destructive) and lists the types of stats. However, it does not mention any behavioral traits like required permissions, response format, or potential side effects, which are minimal for a read operation.
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 efficiently conveys the tool's action and output. Every word adds value, and there is no wasted content.
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 simplicity (one parameter, no output schema), the description is reasonably complete. It explains what stats are tracked, though it could elaborate on whether stats are cumulative or per-session. Overall, it provides sufficient context for an agent to understand usage.
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 description adds no extra meaning beyond the input schema. The schema already describes the session_id parameter with full coverage (100%), so the description's mention of 'session' is redundant. Baseline score 3 applies.
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 purpose: to see knowledge graph stats for a session. It specifies what stats are included (tasks, decisions, files, errors), making the tool's function precise and distinct from sibling tools like analyze_file or get_savings_stats.
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 implicitly indicates when to use (when needing graph stats for a session) but does not explicitly state when not to use or mention alternatives. However, the standalone purpose is clear enough for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get token savings analytics — how many tokens were saved today/this week.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description implies a read-only operation via 'Get'. However, it does not explicitly disclose behavioral traits like side effects, rate limits, or authorization needs.
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?
Single sentence, no wasted words. All information is front-loaded and efficient.
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 no parameters and no output schema, the description covers the basic functionality but lacks details on return format or units of savings. Could be more specific about the analytics provided.
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?
There are no parameters (0, so baseline 4). The description adds value by specifying the type of analytics (token savings) and time periods, which goes beyond the empty 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?
The description clearly states the verb 'Get' and the resource 'token savings analytics', with specific time frames 'today/this week'. It distinguishes from siblings like get_graph_stats by focusing on token savings.
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?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the resume context for a previous session. Returns a compact summary of what was done, decided, and what's pending. Inject this into the system prompt when starting a new session on the same project.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | critical=~100 tokens, standard=~300 tokens, full=~600 tokens | standard |
| session_id | Yes | Session ID to resume |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It describes the output ('compact summary of what was done, decided, and what's pending') and usage recommendation, which is transparent for a read-only retrieval 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?
Two concise sentences cover purpose, content, and usage without waste. Essential information is front-loaded.
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 tool with 2 parameters and no output schema, the description fully explains its purpose, output nature, and intended usage. No gaps are apparent.
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%, so baseline is 3. The description adds no parameter-specific details beyond what the schema already provides (e.g., level token sizes). The 'inject into system prompt' advice is helpful but not parameter-focused.
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: 'Get the resume context for a previous session' and specifies it returns a compact summary. It distinguishes itself from sibling tools like analyze_file or checkpoint_session by focusing on session resumption.
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 explicit context on when to use: 'Inject this into the system prompt when starting a new session on the same project.' It lacks explicit exclusions or alternatives, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reason over the session's decision history: why is something the current choice? Traces the supersession chain (old → new with trigger, reason, and evidence per hop) for decisions matching the query, and reports the currently active choice. Use when the user asks 'why did we pick X', 'what happened to Y', or 'what was the previous approach'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Substring of the decision to explain (e.g. 'react', 'postgres') | |
| session_id | Yes | Session whose decision history to query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses internal mechanics (tracing supersession chain with trigger/reason/evidence per hop) and output (active choice). However, it does not explicitly declare the tool as read-only or mention any side effects, auth needs, or rate limits. Basic transparency but lacks safety disclosure.
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, zero wasted words. Front-loaded with primary purpose, followed by clear usage examples. Efficient communication of key information.
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 moderate complexity and no output schema, the description adequately covers what the tool does and what it returns (traced chain with details, active choice). It provides usage examples. Minor gap: lacks details on return format or pagination, but overall sufficient for agent decision-making.
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% for both parameters. Description rephrases the query parameter as 'substring of the decision to explain', which adds little beyond the schema's description. Session_id is not elaborated. Baseline score of 3 is appropriate as description does not significantly enhance parameter understanding.
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?
Description clearly defines the tool as reasoning over decision history with specific verb 'reason' and resource 'decision history'. It explains the supersession chain tracing and active choice reporting, distinguishing it from sibling tools like analyze_file or checkpoint_session which serve different purposes.
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 explicit when-to-use guidance with example user queries ('why did we pick X', 'what happened to Y', 'what was the previous approach'). Does not mention alternatives or when not to use, but the context is clear and sufficient for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: file analysis, session saving, graph stats, savings stats, and session resuming. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (analyze_file, checkpoint_session, get_graph_stats, get_savings_stats, resume_session).
Five tools is well-scoped for a session and token management server, covering core operations without bloat or deficiency.
The tool set covers essential operations: file analysis, session saving, stats, and resuming. Missing a tool to list or delete saved sessions, but no critical gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Cloud-hosted MCP server for durable AI memory
Persistent memory for AI agents — log and recall conversation context over MCP.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Shweta-Mishra-ai/tokenmizer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
