Spec Driven Development
by formulahendry
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Runs on your computer★ 440MITUpdated 14 months ago
Install
Token Optimizer MCP
Overview
Description from the maker (original English)
Context-window optimization: caching, compression & smart file tools that cut tokens 60-90%.
PopNx MCP’s three pillars
These three are never merged into one score: opinions, measurements and popularity are different things.
- User voiceiNo reviews yetReviews open together with accounts in a later step
- Our basic checksi1 of 1 passedChecked from public information; code not scanned yet
- UsageiNot measured yet★ –
What you can do with it
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
- Connection: Runs on your computer
- Transport: stdio
- Category: Other
Install
Pick the AI app you use, then copy the settings.
Before you install
- Basic checks: 1 of 1 passed
- Runs on your computer with your user’s permissions (files, network, apps).
- You fill in yourself:
TOKEN_OPTIMIZER_CACHE_DIR
You need
- npmNode.js installed (for the npx command)
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"token-optimizer": {
"command": "npx",
"args": [
"-y",
"@ooples/token-optimizer-mcp"
],
"env": {
"TOKEN_OPTIMIZER_CACHE_DIR": "your-value"
}
}
}
}Run this in your terminal
claude mcp add token-optimizer --env TOKEN_OPTIMIZER_CACHE_DIR=your-value -- npx -y @ooples/token-optimizer-mcpFill in the empty values before running it.
Or copy the settings yourself
Paste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"token-optimizer": {
"command": "npx",
"args": [
"-y",
"@ooples/token-optimizer-mcp"
],
"env": {
"TOKEN_OPTIMIZER_CACHE_DIR": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Or copy the settings yourself
Paste into .vscode/mcp.json in your project
{
"servers": {
"token-optimizer": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@ooples/token-optimizer-mcp"
],
"env": {
"TOKEN_OPTIMIZER_CACHE_DIR": "your-value"
}
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
Values you fill in
TOKEN_OPTIMIZER_CACHE_DIRenvDirectory path for cache storage (optional, defaults to ~/.token-optimizer-cache)
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
What it can do
Runs on your computer; the tool list appears in your AI app after you install it.
Basic checksi
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
- ✓ Pass
Maker matches the repo
The registry name was verified with the GitHub account ooples, which owns the repo
- … Not checked yet
Still maintained
We have not read this repo from GitHub yet
- … Not checked yet
Has a licence
We have not read this repo from GitHub yet
- – Not applicable
Endpoint responds
This one runs on your computer; there is no internet endpoint
- – Not applicable
Sign-in with OAuth
Runs on your computer and uses local settings instead
- … Not checked yet
No hidden instructions in tool descriptions
Runs on your computer; we can only read tool lists from internet endpoints
Compared with others in Otheri
- More stars than 0% of the other 32464 servers in this category
- Published to the registry more recently than 94% of the other 32464 servers in this category
- Basic checks equal to or better than 100% of the other 32464 servers in this category
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
Common questions
Is Token Optimizer MCP safe?
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
What keys or codes does it need?
The registry does not list a required key, though some servers ask you to sign in on first use.
Does it run on my computer or in the cloud?
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
Is it still maintained?
The GitHub repo last changed –, and the latest version (7.9.0) reached the registry 2 days ago.
Which apps can use it?
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need Node.js on your computer.
What can I use instead?
In the same category: Spec Driven Development, Remote Desktop Commander, yontu
Alternatives
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
Remote Desktop Commander
by desktop-commander
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Runs in the cloud★ 211Updated yesterday
Install
yontu
by senrecep
Türkçe yazı denetimi: TDK kuralları, yapay zekâ izleri, metin türüne göre üslup.
Runs on your computerUpdated today
Install
README from the maker
Open the README
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
Token Optimizer MCP
Compression that optimises your bill, not your byte count — and ships the benchmark so you can check it.
One local ledger for optimizer tools, live-graph substitutions, every agent, and the graph's own cost.
How it compares to Alternative A
Providers cache the prompt prefix: cached tokens re-read at 0.1x, rewritten ones bill at 1.25x. Most compressors optimise bytes removed and ignore that multiplier. This one optimises the bill.
Measured against their real implementation, on their own fixtures. Not a reimplementation and not our fixtures: their harness compresses the payload, dumps it, their resolver redeems their own markers, and ours is handed the identical bytes. Their column is the best of the nine configurations that capture holds, row by row.
Two of our arms are in the table, and they answer different questions. `ours` is the block engine with nowhere to move a block, which is how the MCP tools and the hooks run: everything it removes, it removes by compressing, and nothing leaves the request. `ours, proxy` is the proxy a Claude Code session runs through, which also moves a block it could not compress out to a file and leaves a marker naming the path -- the same kind of trade their content-cache reference makes. ours, preset is the block engine with that move switched on at spillWholeBlockBelow: 0.9.
| workload | payload | theirs | ours | ours, proxy | ours, preset | zero-turn ids |
|---|---|---|---|---|---|---|
| agentic-conversation | 244,908 | 37.3% / 33.4% | 42.9% / 30.8% | 52.4% / 49.0% | 100.0% / 100.0% | 2099 / 2099 / 0 |
| agent-loop | 170,938 | 42.2% / 54.3% | 69.3% / 59.1% | 92.0% / 94.1% | 93.6% / 94.3% | 185 / 185 / 52 |
| agent-loop-logs | 327,500 | 51.5% / 53.0% | 61.9% / 58.1% | 88.7% / 91.5% | 96.2% / 97.0% | 2034 / 2034 / 81 |
| api-responses | 49,127 | 88.2% / 89.3% | 66.6% / 59.1% | 96.4% / 96.8% | 96.6% / 96.8% | 699 / 98 / 23 |
| browser-session | 781,774 | 21.7% / 13.1% | 93.7% / 26.5% | 55.5% / 90.2% | 100.0% / 99.9% | 334 / 334 / 0 |
| code-search | 131,264 | 47.4% / 59.7% | 81.8% / 70.8% | 97.7% / 97.9% | 95.7% / 96.1% | 201 / 201 / 43 |
| database-rows | 45,929 | 88.6% / 89.2% | 65.6% / 56.5% | 92.4% / 93.1% | 92.6% / 93.4% | 590 / 78 / 49 |
| codebase-exploration | 137,961 | 99.7% / 99.7% | 16.0% / 12.7% | 99.6% / 99.6% | 100.0% / 99.9% | 540 / 3 / 0 |
| grep-output | 75,219 | 99.6% / 99.6% | 56.1% / 51.9% | 99.5% / 99.6% | 99.9% / 99.9% | 1005 / 3 / 0 |
| log-entries | 91,385 | 80.8% / 83.2% | 63.5% / 52.0% | 95.4% / 95.7% | 95.5% / 96.0% | 1180 / 237 / 46 |
| human-authored-json | 37,425 | 30.6% / 30.0% | 66.6% / 66.0% | 81.6% / 83.7% | 96.7% / 96.9% | 154 / 154 / 11 |
| issue-triage | 109,354 | 53.1% / 55.2% | 88.1% / 85.7% | 97.2% / 97.6% | 95.1% / 95.7% | 59 / 59 / 21 |
| rag-conversation | 171,913 | 0.0% / 0.1% | 84.6% / 83.2% | 99.1% / 99.4% | 100.0% / 100.0% | 42 / 42 / 0 |
| raw-build-log | 158,057 | 99.8% / 99.8% | 70.6% / 48.2% | 99.7% / 99.8% | 100.0% / 100.0% | 430 / 3 / 0 |
| relevance-probe | 49,157 | 64.1% / 71.0% | 82.4% / 77.2% | 97.1% / 97.8% | 95.8% / 96.6% | 225 / 225 / 13 |
| search-results | 96,647 | 95.0% / 95.4% | 74.3% / 59.4% | 96.5% / 96.5% | 96.6% / 96.6% | 505 / 62 / 34 |
| repeated-reads | 158,285 | 37.4% / 30.4% | 71.7% / 68.5% | 99.5% / 99.6% | 100.0% / 100.0% | 394 / 388 / 0 |
| sre-debugging | 312,276 | 88.4% / 89.9% | 67.4% / 62.4% | 98.5% / 98.7% | 97.1% / 97.5% | 3116 / 506 / 82 |
Recorded 2026-10-17 at b1231a8c, by the command in the record's regenerate field, over Alternative A's own fixtures and harness. That arm runs Alternative A itself, so CI does not re-derive it -- it checks these figures and this provenance against the record instead.
Over the corpus the proxy removes 82.5% of the characters and 91.5% of the tokens; their best configuration removes 51.5% and 61.4%. It is cheaper than their best arm on 18 of 18 rows when nothing is ever fetched back, which is the end of the range their markers are built for, and on 17 of 18 when every moved block is fetched back. The block engine alone removes 72.0% and 55.9%: more of the characters than theirs, fewer of the tokens.
Where they still win, and why. On codebase-exploration, grep-output, raw-build-log, sre-debugging and the four raw-data rows their best arm takes 83.2-99.8% off the tokens and the block engine 12.7-62.4%. Their number there is a content-cache reference: the block is not made smaller, it is taken out of the request, put in a store, and replaced by a < > marker. An engine with nowhere to put a block cannot match that, so on those rows the ours column loses on reduction, and on cost when nothing is fetched back. The proxy makes the same move: it is ahead of them on five of those eight rows, level on grep-output and raw-build-log, and a tenth of a point behind on codebase-exploration. The one row where the proxy costs more than they do is agentic-conversation, and only when every block it moved is fetched back: they move none of that conversation out, so they cost the same at either end, while the proxy moves part of it and pays a retrieval for each part it wants back.
The other column is a turn. A marker is not the content: to read what it stands for, the agent spends a request. Of the 13,792 retention units planted in the corpus, the block engine keeps 5,223 in the text and 8,569 more rebuildable from the text alone, so every one of them is there with no extra turn; theirs keeps 6,711 in the text and 7,075 behind its store, one retrieval call away. 0 are unrecoverable on our side and 6 on theirs. Their best arms force 17 round trips across the corpus to get their content back; the block engine forces 0. The proxy, like theirs, trades a turn for every block it moves, and that turn is what the fetch-rate end of the cost model prices.
What their marker costs is priced, not just its size. Their marker is only redeemable because their proxy also sends a alternative_a_retrieve tool with the request -- on by default (ccr_inject_tool), and on every later request once a session has used it -- so every row where their best arm leaves a marker is charged for that tool's definition as well, recorded from their own package by bench/compression/alt-a/ccr-tool.py. The turn that first adds the tool also rewrites the whole cached prefix behind it; that is not charged, which errs in their favour. Ours needs no tool: our marker names a path the agent opens with the Read it already has, and the path is priced at the length the proxy really writes ( /.tok/ /<15 digits>, src/compress/spill-path.ts) rather than a shorter invented one.
`browser-session` is mostly the fixture. This payload holds four images, two of them distinct, and the base64 in them is generated rather than photographic: one distinct image alone folds from 160,032 characters to 5,572, which no real PNG would do. What carries over to a real session is the duplication -- half the image bytes are a second copy of an image already in the request, which is 44.3% of the whole payload. The run the marker names is still in the output above it, so the reader rebuilds it without asking for anything, which is why the characters fall much further than the tokens: the image tokens are counted from pixels on both arms either way.
Reproduce the whole table:
python bench/compression/alt-a/run-theirs.py <alt-a-clone> <out-dir>python bench/compression/alt-a/resolve-theirs.py node bench/compression/head-to-head.mjs
Against their published design
A second arm reimplements their published design from their own benchmark generator's definitions — opaque hash markers, history compressed, a retrieval tool and system message injected — so the four workloads with a published comparator can be checked without their clone. node bench/compression/proof.mjs:
| workload | payload | theirs | ours | verdict |
|---|---|---|---|---|
| code-search | 17765 | 92.1% | 97.8% | ours |
| sre-debugging | 65694 | 92.2% | 98.6% | ours |
| issue-triage | 54174 | 72.8% | 97.5% | ours |
| codebase-exploration | 78502 | 47.4% | 54.7% | ours |
Four workloads, because those are the four this arm has a published comparator for. The head-to-head harness scores eighteen; the other fourteen are not in this arm, and are scored against their real implementation in the table above.
**`codebase
Only the beginning is shown; read the rest in the repo