Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者による説明(英語の原文)
Token-bounded repository context for coding agents over MCP.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
作者はレジストリにインストール情報を載せていません。下にある作者のREADMEをご覧ください。
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月7日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント morluto で確認済みです
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
これはパソコンで動くため、インターネット上のエンドポイントはありません
パソコンで動き、代わりにローカルの設定を使います
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
レジストリには必須のキーは載っていません。ただし、最初に使うときにサインインを求めるサーバーもあります。
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
GitHubリポジトリの最終更新は–、最新バージョン(0.1.28)がレジストリに届いたのは2 か月前です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにRustも必要です。
同じカテゴリには:Spec Driven Development, Remote Desktop Commander, Zendesk
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Zendesk MCP Pack — tickets, users, organizations via OAuth.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
LeanToken
Code intelligence for agents: find the code that matters and keep your context window and tokens lean.
Language: English · 简体中文 · 日本語 · 한국어
mcp-name: io.github.morluto/leantokenInstall · Why LeanToken · Tools · CLI · How it works · Docs
Measured token savings: In a controlled 60-run study, LeanToken used
20.1% fewer model input tokens than the agent's built-in tools with limited
repository exploration, and 37.6% fewer than those tools with broad
exploration. See exactly
how it was measured in the measurement methodology.
Add LeanToken to Claude Code, Cursor, OpenCode, Codex, Gemini CLI, or Antigravity:
npx leantoken setup
Setup behavior and safety
Current releases stop setup before writing when npx resolves a stale project-local or ancestor install, and point to npx leantoken@latest setup. Older releases that predate this check can be bootstrapped directly with that versioned command.
The interactive setup wizard preselects supported clients it detects; you can change that selection before continuing. It then shows the exact configuration paths and MCP launcher and asks for a separate final confirmation. Automation never treats detection as consent. An npx-based setup pins the exact LeanToken version that ran setup, so restarting a client cannot silently move to a newer release.
Global setup never stores the repository where setup happened. OpenCode gets a workspace-relative working directory; other supported clients launch LeanToken from the workspace cwd selected by the host. If a host instead starts it from the home directory or a filesystem root, LeanToken refuses to index that broad root by default.
Restart or reload the configured clients, then verify the connection and first retrieval from a repository:
npx leantoken doctor
Try a broad task such as: *Find the code related to request cancellation before editing.* LeanToken helps the agent start with leantoken.context, while its normal tools remain available for edits, builds, and tests.
Inspect LeanToken's observed repository-local token accounting:
npx leantoken savings
Local by default
Source is indexed on your machine in a local database. LeanToken is a read-only discovery and retrieval layer.
Explicit token budgets
Every response has an explicit token limit, so large files cannot take over the request.
Built for agent workflows
Find files, search code, inspect structure, read exact ranges, trace history, query JSON, and track token usage through focused tools.
Advanced setup and version management
To skip the wizard, select clients explicitly or configure all supported clients:
npx leantoken setup --claude --codex --yes
npx leantoken setup --all --yes
For regular use, --private-runtime is the recommended launcher: it copies the exact package-native executable into an application-data directory named by version and full BLAKE3 digest, so clients launch one verified process directly, without persistent npm/Node wrappers. Different source builds of one version can coexist. setup --refresh --private-runtime pins the current exact artifact; other referenced artifacts stay usable. It remains opt-in so the zero-install path does not add an application-data write. Preview its path and digest with --dry-run.
Automation never treats detection as consent: --yes requires explicit client flags, --all, or --refresh for entries already managed by LeanToken. Preview the same resolved plan without changing files:
npx leantoken setup --codex --cursor --dry-run
Setup adds the leantoken MCP entry plus a small owned discovery skill only in the directories used by the selected hosts: Claude Code uses ~/.claude, while Codex and the other supported hosts use ~/.agents. The skill advertises routing metadata; it does not duplicate tool schemas, add rules, or install shell hooks. Setup marks new MCP launchers as managed and refuses to replace a same-name manual entry unless you review the dry-run and pass --force-unmanaged. Remove the owned integration with:
npx leantoken remove
After private-runtime upgrades, inspect retained artifacts and preview a reference-safe cleanup before applying it:
npx leantoken runtime list
npx leantoken runtime prune --dry-run npx leantoken runtime prune --yes
Refresh only existing LeanToken MCP entries after explicitly choosing a new version, or use an older version to roll back:
npx --yes leantoken@latest setup --refresh --yes
npx --yes leantoken@0.1.8 setup --refresh --yes --allow-outdated
LeanToken works best as a small evidence loop rather than a one-shot repository dump:
context and plan_only: false, then use the materialized evidence directly. Make at most one focused follow-up only when coverage identifies a concrete missing implementation or regression-test owner.receipt_id on the next context call, or pass returned fragment hashes as known_hashes. The response reports exact and overlapping omissions instead of silently charging the same evidence again.investigation workflow and provide only directly observed failure_traces, paths, symbols, or test intent in workflow_evidence. Follow with exact search, outline, or read calls for the owners the evidence identifies.review workflow with base_revision set to BASE..HEAD and strict_changed_paths: true. Request a handoff when another agent needs a compact manifest of selected hashes, changed paths, assumptions, and completed validations without copied source bodies.This one-call contract is for autonomous repository triage, not a limit on implementation agents. Human review and control-plane flows can still preview expensive or high-risk retrieval with plan_only: true before materializing. The repeated multi-agent context suite found that an iterative LeanToken profile used 50.9% more total input than thin native, while the frozen one-context-plus-optional-one-search profile saved 20.1% and had 15/20 path-set successes. Those results cover four pinned triage tasks; they do not prove a universal implementation workflow.
Explicit focus constraints are contracts. When a request supplies focus_paths, exact focus_symbols, and minimum_fragments_per_focus_path, LeanToken generates candidates within the documented per-file bounds and reports a coverage failure when distinct ranges cannot satisfy the minimum. Explain-profile plans and materialized responses also identify the bounded allocation boundary that generated, reserved, selected, or suppressed each focus candidate without changing ranking.
Most agents start by searching widely and reading whole files. LeanToken narrows that work in stages:
| Typical repository exploration | With LeanToken |
|---|---|
| Scan broad directory listings | Find relevant paths in a compact tree |
| Read whole files to find structure | See definitions and imports without loading the entire file |
| Send the same code again after each turn | Avoid repeating unchanged evidence |
| Let large files fill the request | Keep returned source within an exact source-token budget and report response overhead separately |
| Guess which files matter | Rank likely relevant code for the task |
Your coding agent still handles editing, commands, tests, and conversation. LeanToken finds and returns the code those tasks need.
LeanToken does not create one giant prompt file. It answers focused searches and reads as the agent needs them.
For a task like *fix request cancellation during shutdown*, an illustrative bounded result might look like this:
Budget: 1,200 source tokens
Selected evidence: src/services/executor.rs lines 137-147, 251-259 src/services/reconciliation.rs lines 148-175, 257-272
The agent receives these ranges instead of both full files. If the budget is too small, the response also says what was left out. Paths, scores, receipts, JSON, and MCP transport wrappers are not part of this source-token budget; see token accounting for the measured boundaries.
| Tool | Purpose |
|---|---|
leantoken.context | Default materialized first call for autonomous broad triage; optional preview for human or control-plane review. |
leantoken.search | Prefer over grep/rg for ranked search; exhaustive text/regex calls can explicitly record or reuse complete query coverage. |
leantoken.files | Prefer over find/ls/glob for compact, ignore-aware path discovery. |
leantoken.outline | Inspect definitions, signatures, imports, and ranges without whole-file reads. |
leantoken.read | Prefer over cat/head/sed for one exact symbol or inclusive line range. |
leantoken.history | Read, batch-diff, or trace parsed symbols across immutable Git revisions. |
leantoken.json | Query, summarize, or compare bounded live JSON with paged keys and typed diagnostics. |
leantoken.receipt_rebase | Explicitly carry only same-path, same-coordinate, same-hash evidence into a newer completed generation. |
leantoken.savings | Report observed response accounting, hash suppression, failures, and explicit observation limits. |
Advanced retrieval controls
Every index-backed retrieval tool, including receipt_rebase, accepts consistency: "reconcile_working_tree" when completed edits must be reconciled before the query. The default, "indexed_generation", returns the latest completed index generation without scanning or waiting for filesystem changes; it is not a Git revision boundary. leantoken.history reads immutable Git objects and leantoken.json reads exact live files, so neither accepts an index consistency mode. To constrain context to immutable history, pass BASE..HEAD as leantoken.context.base_revision with strict_changed_paths: true.
For autonomous broad triage, set plan_only: false and use the materialized evidence directly. Reserve plan_only: true for human or control-plane review before expensive or high-risk retrieval: it returns bounded ranked candidate metadata without source fragments or receipt mutation. After approval, repeat the same request with plan_only: false. Set response_profile: "compact" for the smallest
冒頭だけを表示しています。続きはリポジトリで読めます