Enables offloading code generation, text summarization, and other boilerplate tasks to local LLMs via Ollama, reducing API costs.
Exposes server metrics (e.g., request counts, token usage) in Prometheus format for monitoring and observability.
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., "@claude-token-saver-mcp Write a function to shuffle an array in TypeScript"
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.
English | 日本語
Beta — 個人利用向け。736 テスト / カバレッジ 97%。
Claude Code の「それ、ローカルでよくない？」を自動化する MCP サーバー。
ボイラープレート生成、テスト作成、テキスト要約 — Cloud API に投げるまでもない定型タスクを、手元の Ollama でさばきます。セキュリティ対策込み。
Claude Code の API 利用を分析してみたら、リクエストの約 40% は定型的なコード生成やテキスト処理でした。この手のタスクは 7B クラスのローカルモデルでも実用的な品質が出ます。「推論は Cloud、作業は Local」— この振り分けを MCP で自動化したのがこのツールです。
Related MCP server: Ollama MCP Server
ローカル LLM の進化は速いです。2024 年の Llama 3 から 2025 年の Qwen3 まで、わずか 1 年でコード生成ベンチマーク (HumanEval) のスコアは 60% → 85% に跳ね上がりました。
この調子なら、Agent ワークフローにローカル LLM が当たり前に組み込まれる日もそう遠くないでしょう。claude-token-saver-mcp は Cloud と Local を使い分けるための土台を提供します。
MCP (Model Context Protocol) は Claude Code が外部ツールを呼び出すための標準プロトコルです。このサーバーを登録すると、Claude Code がタスクの内容を見て、定型的な処理を自動的にローカル LLM へ回します。
Claude Code ──MCP──▶ token-saver ──HTTP──▶ Ollama (ローカル)
│ │
│ 「定型タスクだ → ローカルに振ろう」 │
│ │
└─── 高度な推論・設計判断は Cloud で継続 ───┘Ollama が落ちていたり応答が遅い場合は Cloud API にフォールバック可能です。
前提: Node.js 20+ と Ollama がインストール済みであること。
0. Ollama を起動
ollama serve1. プロジェクトルートに .mcp.json を作成
{
"mcpServers": {
"token-saver": { "command": "npx", "args": ["-y", "claude-token-saver-mcp"] }
}
}2. Claude Code を起動して、こう頼む
コーディング用にローカルLLMをセットアップしてRAM に応じた最適モデルが推奨 → ダウンロード（約 4GB）→ プリロードまで自動で走ります。
3. 動作確認
TypeScript で配列をシャッフルする関数を書いて「ローカルLLM（qwen2.5-coder:…）で生成しました」のようにローカルモデル名が表示されれば OK。
出ない場合は ollama list でモデルを確認し、トラブルシューティング を参照してください。
git clone https://github.com/BlackFoil/claude-token-saver-mcp.git
cd claude-token-saver-mcp
npm ci && npm run buildプロジェクトルートの .mcp.json に追加：
{
"mcpServers": {
"token-saver": {
"command": "node",
"args": ["/path/to/claude-token-saver-mcp/dist/server.js"]
}
}
}ローカル完結 — 定型タスクは Cloud API を使わずに処理できる
自動モデル選択 — RAM を検出して最適なモデルを推奨・DL・プリロード（auto_setup）
セキュリティ内蔵 — プロンプトインジェクション検知 + 出力サニタイズ
コスト可視化 — 節約額をリアルタイムで追跡（定型タスク比率 40% なら月 $50〜80 程度の削減が目安）
Cloud フォールバック — Ollama が落ちても Cloud に自動切り替え可能
あなた: 「ソート関数を書いて」 → offload_work がローカルで生成 💰 $0.02 節約
あなた: 「このログを要約して」 → compress_context がローカルで圧縮 💰 $0.05 節約
あなた: 「コスト節約を見せて」 → cost_dashboard: 累計 $47.89 節約
あなた: 「3つのAPIを一括実装して」 → batch_offload: 3 タスクを順次処理ローカル 7B モデルの出力は Claude に及びません。それは前提です。ただ、定型タスクに限れば十分実用的です。
タスク | ローカル品質 | 向き不向き |
ボイラープレート生成 | ★★★★☆ | ✅ 得意 |
ユニットテスト作成 | ★★★★☆ | ✅ 得意 |
テキスト要約 | ★★★★☆ | ✅ 得意 |
単純なリファクタリング | ★★★☆☆ | ✅ 実用的 |
アーキテクチャ設計 | ★★☆☆☆ | ❌ Cloud に任せるべき |
複雑なデバッグ | ★★☆☆☆ | ❌ Cloud に任せるべき |
Claude Code がタスクの複雑さを判断して自動で振り分けます。ローカルの品質が足りなければ Cloud で処理されます。
RAM | Tier | モデル | DL サイズ |
< 16 GB | Light | phi4:latest | ~2.5 GB |
16–48 GB | Standard | qwen2.5-coder:7b | ~4.7 GB |
> 48 GB | Ultra | qwen2.5-coder:32b | ~18 GB |
ツール | 説明 |
| コード生成・リファクタリングをローカルで実行 |
| 長大なテキストをローカルで要約 |
| 最適モデルの推奨 → DL → プリロードをワンステップで |
| 複数タスクを一括投入（順次 / 並列） |
| 累計節約額・モデル使用統計 |
ツール | 説明 |
| サーバーメトリクス（JSON / Prometheus） |
| タスクカテゴリ別の最適モデル推奨 |
| Ollama モデルのダウンロード |
| VRAM へのプリロード |
| ロード中モデルの一覧 |
| モデルセレクターのランタイム設定 |
ローカル LLM への入出力を自動で保護します。
プロンプトインジェクション検知 — 5 カテゴリ・20 パターンで悪意ある入力をブロック
出力サニタイズ — API キー・パスワード・JWT など 11 パターンを [REDACTED] に置換
データプライバシー — 全処理がローカル完結。外部への送信なし
5 分で始める | |
具体的な活用例 | |
全設定項目 | |
よくある質問 | |
エラー対応 |
src/
├── server.ts # MCP エントリポイント（11 ツール登録）
├── tools/ # offload_work, compress_context, auto_setup, batch_offload 等
├── ollama/ # Ollama クライアント & マルチノードロードバランサー
├── queue/ # FIFO キュー & 優先度キュー（URGENT/HIGH/NORMAL/LOW）
├── model-selector/ # モデル推奨エンジン, ベンチマーク DB, 実行トラッカー
├── validators/ # 入力バリデーション & プロンプトインジェクション検知
├── cost/ # コスト計算 & レポーター
├── metrics/ # Prometheus メトリクス収集
├── persistence/ # ExecutionTracker / BenchmarkStore のファイル永続化
├── config/ # Zod 設定スキーマ & ローダー
├── tiering/ # RAM ベースの自動ティアリング
├── logging/ # 構造化ログヘルパー
└── errors.ts # CTS-XXXX エラー体系npm ci
npm test # 736 テスト（カバレッジ 97%）
npm run typecheck # 型チェック
npm run lint # ESLint
npm run build # プロダクションビルド対応プラットフォーム: macOS / Linux / Windows（Ollama が動く環境）
コントリビューション歓迎です → CONTRIBUTING.md
Automate the full model setup flow: recommend the best model for a task category, download it if needed, and preload it into VRAM — all in one step.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Task category: coding, coding-agent, japanese-text, japanese-coding, translation, summarization, general. Default: "general" | |
| skip_pull | No | Skip downloading the model if not installed. Default: false | |
| skip_preload | No | Skip preloading the model into VRAM. Default: false | |
| prefer_quality | No | Prefer quality (true) or speed (false). Default: false |
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 three steps (recommend, download if needed, preload) but fails to mention potential side effects, prerequisites, failure modes, or resource impact. Adequate but not thorough.
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?
Description is a single clear sentence, front-loaded with the tool's purpose. While efficient, it could be slightly more concise without losing meaning.
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 sibling tools and lack of output schema, the description does not explain return values or when to prefer this combined tool over individual ones. It covers the use case but lacks context for alternatives and output format.
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?
Input schema covers all parameters with descriptions (100% coverage). The tool description relates steps to parameters but adds minimal meaning beyond the schema. Baseline 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?
Description clearly states the tool automates the full model setup flow—recommend, download, and preload. It uses specific verbs and resource, distinguishing it from sibling tools like recommend_model, pull_model, and preload_model.
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 the tool is for combining multiple steps but does not explicitly state when to use it versus alternatives, nor does it provide exclusion criteria. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit multiple coding tasks as a batch to the local LLM. Tasks are processed sequentially or in parallel. Supports partial failure.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | Array of tasks (1-10) | |
| sequential | No | Process tasks sequentially, passing previous result as context (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses sequential/parallel processing and partial failure, adding value beyond no annotations. However, lacks details on idempotency, side effects, error handling, or rate limits.
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, no wasted words, front-loaded with key purpose. Efficient and clear.
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?
Covers purpose, processing mode, and partial failure, but without output schema, more detail on result handling and error behavior would improve completeness for a batch operation tool.
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 description adds minimal meaning beyond what the schema already provides for tasks and sequential parameters.
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 states the tool submits multiple coding tasks as a batch to the local LLM, with a specific verb and resource. It distinguishes from siblings like offload_work by emphasizing batch processing.
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?
Implies usage for batch tasks but provides no explicit when-to-use, when-not-to-use, or alternatives. Missing guidance on comparison with offload_work or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compress/summarize large text content using a local LLM to reduce cloud token usage. Use for summarizing logs, large files, or verbose context before sending to Claude.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | What to focus on in the summary (optional, max 500 chars) | |
| model | No | Override the Ollama model to use (optional). | |
| content | Yes | The content to compress/summarize (required, max 200000 chars) | |
| max_length | No | Target max length of the summary in chars (optional, 100-10000, default: 2000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It mentions using a local LLM but omits important details: potential failure if model unavailable, performance implications, or whether compression is lossy. Limited 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, no redundancy, front-loaded with verb and goal. Every word adds value.
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 output schema and no annotations, the description covers purpose, use cases, and parameter constraints reasonably. Could add more on tool behavior (e.g., local dependency), but sufficient for common use.
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 has 100% parameter description coverage, so the description need not add much. It does not elaborate on parameters beyond the schema, maintaining baseline adequacy.
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 defines the tool's action (compress/summarize) and resource (large text content), and distinguishes it from sibling tools which are unrelated (e.g., metrics, model management).
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 use cases (summarizing logs, files, verbose context before sending to Claude), giving clear context. Does not include when-not-to-use or alternatives, but siblings are distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View or modify model selector settings at runtime. Manage blocked models, license filters, and custom model recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform. "add"/"remove" for blocked_models/license_filter only. | |
| values | No | Values for set/add/remove (for blocked_models and license_filter) | |
| setting | Yes | Which setting to manage | |
| custom_config | No | Custom recommendations config for "set" action on custom_recommendations. Format: { category: { tier: [modelId, ...] } } |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It indicates both viewing and modifying actions but omits side effects, permission requirements, persistence of changes, or any safety warnings. The agent learns only that it manages settings, not the consequences.
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 front-load the primary action (view or modify) and immediately list the managed settings. No extraneous information, making it quick to parse.
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 does not hint at return values or behavior of get vs. set actions. Considering the tool's complexity (nested config, multiple actions), the description lacks guidance on expected responses or operational context.
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 baseline is 3. The description adds no new parameter details beyond the schema, merely summarizing the setting types. It does not enhance understanding of parameter constraints or formats beyond what the schema already provides.
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 views or modifies model selector settings at runtime, listing specific settings like blocked models, license filters, and custom recommendations. This verb-noun-resource structure clearly distinguishes it from sibling tools like get_metrics or pull_model.
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 use for configuring the model selector but does not explicitly state when to use this tool over alternatives or when not to. No exclusions or alternatives are provided, though the sibling tools cover different functionalities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View cumulative cost savings and model usage statistics.
| 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. It only implies a read operation ('View') but fails to disclose any behavioral traits such as data aggregation, permission requirements, or refresh rate. It is insufficient for an agent to understand side effects or constraints.
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 sentence with no redundancy. It is front-loaded with the action verb and presents the resource concisely. Every part 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 simple view tool with no parameters and no output schema, the description is adequate but minimal. It could benefit from clarifying whether the statistics are real-time or historical, and how they relate to sibling tools like get_metrics.
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, and schema description coverage is 100%. The description adds meaning by specifying what is viewed (cost savings and statistics), which is sufficient. Baseline for 0 params is 4.
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 ('View') and clearly states the resource ('cumulative cost savings and model usage statistics'). It distinguishes the tool from siblings like get_metrics or list_loaded_models by focusing on cumulative savings and statistics.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives like get_metrics or recommend_model, nor does it state any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get server metrics in Prometheus text format or JSON. Includes request counts, latency, queue stats, cost savings, and health status.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format (default: json) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions the output formats and content but does not discuss idempotency, rate limits, authentication requirements, or whether the operation is read-only. For a metrics tool, the lack of 'safe to call' indication is a gap.
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 that efficiently convey purpose and content. No fluff, every word adds value.
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 tool with one optional parameter and no output schema, the description is adequate. It lists the metric categories. It could be improved by noting if metrics are real-time or cached, but overall it provides sufficient context.
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 one parameter 'format' described in the schema. The description adds the phrase 'Prometheus text format or JSON', which aligns with the enum, adding minimal extra meaning. This meets the baseline of 3.
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 gets server metrics in two formats (Prometheus text or JSON) and lists the types of metrics included (request counts, latency, queue stats, etc.). This is specific and distinguishes it from sibling tools like list_loaded_models which deal with models.
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 vs alternatives. While it is obvious for monitoring, the description does not provide context such as 'use for performance monitoring' or exclude cases like debugging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all models currently loaded in VRAM with usage details. Shows VRAM usage, expiry time, and available slots.
| 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 transparency burden. It discloses the output fields (VRAM usage, expiry, slots) but does not confirm read-only nature, authorization needs, or performance impact. Adequate but not comprehensive.
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, no redundancy, front-loaded with the main action. Every word adds value.
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 description covers the main return fields but lacks detail on output format (e.g., list vs object), error states, or ordering. Given no output schema, it's mostly complete for a simple listing tool.
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?
No parameters exist; schema coverage is 100% trivially. The description adds value by explaining what the output contains, 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 it lists models loaded in VRAM with specific details (VRAM usage, expiry time, available slots). This distinguishes it from sibling tools like pull_model (downloads) or preload_model (loads a model), providing a clear purpose.
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 explicit guidance on when to use this tool versus alternatives. The description implies it's for viewing loaded models, but doesn't mention when not to use it or recommend other tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Offload coding/text tasks to a local LLM (Ollama) to save Claude API tokens. Use for code generation, refactoring, formatting, boilerplate, and other routine tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | The task to perform (required, max 50000 chars) | |
| model | No | Override the Ollama model to use (optional). Takes precedence over category-based selection. | |
| context | No | Additional context such as file content or specifications (optional, max 100000 chars) | |
| category | No | Task category for automatic model selection (optional). Ignored if model is specified. | |
| language | No | Programming language (optional) | |
| output_format | No | Output format (optional, default: code) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It fails to disclose important behaviors such as whether Ollama must be running, error handling if the model fails, permission requirements, or cost implications beyond token savings.
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 are concise and front-loaded with the primary purpose. Every word contributes meaning, leaving 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?
With 6 parameters fully documented in schema and no output schema, the description covers core functionality well. It could mention what the output generally looks like (e.g., returned text) but is sufficient for basic understanding.
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 schema already documents all parameters. The description adds value by listing example use cases (code generation, refactoring) but does not augment parameter meaning 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?
The description explicitly states the tool offloads coding/text tasks to a local LLM to save API tokens. It distinguishes from sibling tools like get_metrics and list_loaded_models by focusing on task execution rather than system queries.
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?
It suggests using the tool for routine tasks like code generation and refactoring to save tokens, but does not specify when to avoid use (e.g., for critical tasks requiring Claude's reasoning) or mention alternatives like batch_offload for bulk operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preload a model into VRAM for warm inference. Sends an empty chat request with keep_alive to keep the model loaded during the session.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | The model name to preload (must be already installed via pull_model) | |
| keep_alive | No | Duration to keep the model loaded (optional, default: "-1" = permanent). Examples: "5m", "1h", "-1" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool sends an empty chat request with a keep_alive parameter, which is key behavioral information. It does not cover all edge cases (e.g., error if model not installed), but provides sufficient behavioral context for typical use.
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 main purpose, no superfluous words. Every sentence adds value: first states action, second explains mechanism.
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 output schema and two well-described parameters, the description is complete. It explains the tool's purpose, mechanism (empty chat request, keep_alive), and a prerequisite (model must be installed). No missing information for expected agent use.
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 context about 'warm inference' and 'session' but does not provide additional parameter details beyond what the schema already documents (e.g., model must be installed, keep_alive examples).
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 action: 'Preload a model into VRAM for warm inference.' It uses a specific verb ('preload') and resource ('model'), and distinguishes it from siblings like 'pull_model' (install) and 'list_loaded_models' (list).
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 for warm inference and session persistence, but does not explicitly state when to use this tool versus alternatives (e.g., 'offload_work'). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a model from the Ollama registry to local storage. Use this to install recommended models before preloading them into VRAM.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model name to pull (e.g. "qwen3:14b", "devstral:24b") |
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 only states the basic action of downloading without disclosing side effects, permissions, network requirements, or error conditions. More behavioral context is needed.
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 with no wasted words. The first sentence states the action, the second provides usage guidance. 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?
For a simple download tool with one parameter and no output schema, the description covers basic usage and context but omits return behavior, progress indication, and potential errors. It is minimally adequate.
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% and the schema already describes the parameter 'model' with examples. The description does not add additional meaning beyond what the schema provides, so baseline 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 'download a model from the Ollama registry to local storage' with a specific verb and resource. It distinguishes itself from siblings like recommend_model and preload_model by indicating this tool is for installation before preloading.
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 says 'use this to install recommended models before preloading them into VRAM,' providing clear context for when to use the tool. It implies the order of operations but does not mention when not to use or explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend the best local LLM model for a given task category based on system specs and installed models. Returns prioritized list with installation status and license info.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Task category: coding, coding-agent, japanese-text, japanese-coding, translation, summarization, general | |
| prefer_quality | No | Prefer quality (true) or speed (false). Default: false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions return content (prioritized list, installation status, license info) but does not explicitly state side effects or whether it modifies system state. Assumed read-only.
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 action and output. Every sentence adds value. No filler.
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 output schema or annotations, description is fairly complete: specifies inputs (implicit via system specs), return structure (prioritized list, status, license). Could clarify that it does not perform downloads.
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%, both parameters have descriptions. The description adds no additional meaning beyond what is in the schema (category enum and prefer_quality boolean). Baseline 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?
Clearly states it recommends the best local LLM model for a given task category based on system specs and installed models, returning a prioritized list. Distinguishes from sibling tools like list_loaded_models or pull_model.
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?
Implies usage for model selection but does not explicitly state when to use it versus alternatives like configure_model_selector or list_loaded_models. No when-not guidance.
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: metrics, model listing, downloading, task offloading (single and batch), context compression, cost dashboard, model recommendation, VRAM preloading, configuration, and automated setup. No two tools overlap in functionality.
All tools follow the verb_noun snake_case pattern without exception. Names like 'get_metrics', 'offload_work', 'batch_offload', and 'auto_setup' are predictable and consistent.
11 tools is appropriate for a server focused on saving tokens via local LLMs. Each tool addresses a specific aspect (model management, task offloading, monitoring, configuration) without being excessive or insufficient.
The tool set covers the full workflow: model installation, recommendation, preloading, offloading, context compression, and monitoring. Minor gaps exist: there is no tool to unload models from VRAM or delete models, but these are not critical for the primary use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BlackFoil/claude-token-saver-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
