言語モデルのインタラクション間でデータを効率的にキャッシュすることでトークンの消費量を削減するモデルコンテキストプロトコル（MCP）サーバー。トークンを使用するあらゆるMCPクライアントおよび言語モデルで動作します。
Smithery経由で Claude Desktop のメモリ キャッシュ サーバーを自動的にインストールするには:
npx -y @smithery/cli install @tosin2013/mcp-memory-cache-server --client claudeリポジトリをクローンします。
git clone https://github.com/tosin2013/mcp-memory-cache-server.git
cd mcp-memory-cache-server依存関係をインストールします:
npm installプロジェクトをビルドします。
npm run buildMCP クライアント設定に追加:
{
"mcpServers": {
"memory-cache": {
"command": "node",
"args": ["/path/to/ib-mcp-cache-server/build/index.js"]
}
}
}MCPクライアントを使用するとサーバーが自動的に起動します
Related MCP server: Claude Continuity MCP Server
サーバーが正常に動作している場合は、次のように表示されます。
ターミナルにメッセージが表示される:「メモリ キャッシュ MCP サーバーが stdio で実行されています」
同じデータに複数回アクセスする際のパフォーマンスが向上
あなたによる操作は必要ありません。キャッシュは自動的に行われます。
サーバーが実行中であることは、次の方法で確認できます。
MCPクライアントを開く
サーバーを起動したターミナルでエラーメッセージを探す
キャッシュの恩恵を受ける操作を実行する（同じファイルを複数回読み取るなど）
サーバーはconfig.jsonまたは環境変数を通じて設定できます。
{
"maxEntries": 1000, // Maximum number of items in cache
"maxMemory": 104857600, // Maximum memory usage in bytes (100MB)
"defaultTTL": 3600, // Default time-to-live in seconds (1 hour)
"checkInterval": 60000, // Cleanup interval in milliseconds (1 minute)
"statsInterval": 30000 // Stats update interval in milliseconds (30 seconds)
}maxEntries （デフォルト: 1000）
キャッシュに保存できるアイテムの最大数
キャッシュが無制限に大きくなるのを防ぐ
超過すると、最も古い未使用のアイテムが最初に削除されます
最大メモリ（デフォルト：100MB）
最大メモリ使用量（バイト単位）
過剰なメモリ消費を防ぐ
超過すると、最も最近使用されていないアイテムが削除されます
defaultTTL (デフォルト: 1時間)
デフォルトでアイテムがキャッシュに保持される期間
この時間が過ぎるとアイテムは自動的に削除されます
古いデータがメモリを消費するのを防ぐ
checkInterval （デフォルト：1分）
サーバーが期限切れのアイテムをチェックする頻度
値を低くすると、メモリ使用量がより正確になります
値を大きくするとCPU使用量が減ります
statsInterval （デフォルト：30秒）
キャッシュ統計の更新頻度
ヒット/ミス率の精度に影響します
キャッシュの有効性を監視するのに役立ちます
メモリキャッシュサーバーは、ユーザーと言語モデル間で再送信が必要となるデータを自動的に保存することで、トークンの消費量を削減します。特別な操作は必要ありません。MCPクライアントを介して言語モデルとやり取りすると、キャッシュは自動的に実行されます。
キャッシュされるものの例をいくつか示します。
ファイルを複数回読み取る場合:
初回: ファイルの全コンテンツが読み込まれ、キャッシュされます
次回以降: ファイルを再度読み込む代わりに、キャッシュからコンテンツが取得されます。
結果: 繰り返しファイル操作に使用されるトークンが少なくなる
計算や分析を実行する場合:
初回: 完全な計算が実行され、結果がキャッシュされます
次回以降: 入力が同じであれば、結果はキャッシュから取得されます
結果: 繰り返し計算に使用されるトークンが少なくなる
同じデータが複数回必要な場合:
初回: データが処理され、キャッシュされる
それ以降: TTLが期限切れになるまで、データはキャッシュから取得されます。
結果：同じ情報にアクセスするために使用するトークンが少なくなる
サーバーは、次の方法でキャッシュ プロセスを自動的に管理します。
最初に遭遇したときにデータを保存する
利用可能な場合はキャッシュされたデータを提供する
設定に基づいて古いデータや未使用データを削除する
統計による効果の追跡
頻繁に変更されるデータの場合は短くなります
静的コンテンツの場合は長め
高いほどキャッシュが増えます（トークンの節約が増えます）
メモリ使用量が気になる場合は低くする
高いヒット率 = トークンの節約
ヒット率が低い = TTLまたは制限を調整する
MCP 設定の環境変数を使用して config.json 設定を上書きできます。
{
"mcpServers": {
"memory-cache": {
"command": "node",
"args": ["/path/to/build/index.js"],
"env": {
"MAX_ENTRIES": "5000",
"MAX_MEMORY": "209715200", // 200MB
"DEFAULT_TTL": "7200", // 2 hours
"CHECK_INTERVAL": "120000", // 2 minutes
"STATS_INTERVAL": "60000" // 1 minute
}
}
}
}カスタム構成ファイルの場所を指定することもできます。
{
"env": {
"CONFIG_PATH": "/path/to/your/config.json"
}
}サーバーは次のことを行います。
ディレクトリ内のconfig.jsonを探します
環境変数のオーバーライドを適用する
どちらも指定されていない場合はデフォルト値を使用する
キャッシュの動作を確認するには、次のシナリオを試してください。
ファイル読み取りテスト
大きなファイルを読み取って分析する
ファイルについて同じ質問をもう一度する
ファイルの内容がキャッシュされるため、2回目の応答は速くなるはずです。
データ分析テスト
いくつかのデータの分析を実行する
同じ分析を再度依頼する
2回目の分析ではキャッシュされた結果を使用する必要があります
プロジェクトナビゲーションテスト
プロジェクトの構造を調べる
同じファイル/ディレクトリを再度クエリする
ディレクトリリストとファイルの内容はキャッシュから提供されます
次のことに気づけば、キャッシュは動作しています。
繰り返し操作に対する応答が高速化
変更されていないコンテンツに関する一貫した回答
変更されていないファイルを再度読み込む必要はありません
Clear specific or all cache entries
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Specific key to clear (optional - clears all if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Clear' implies a destructive operation, but it doesn't disclose behavioral traits like whether this requires admin permissions, if it's reversible, potential performance impact, or rate limits. The description states what it does but lacks critical context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and scope, making it easy to parse. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral risks, return values, or error conditions. Given the complexity of cache clearing (which can affect system performance), more context is needed beyond the minimal purpose statement.
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%, with the parameter 'key' documented as optional for clearing specific entries (or all if omitted). The description adds marginal value by mentioning 'specific or all', which aligns with the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
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 'Clear specific or all cache entries' clearly states the verb (clear) and resource (cache entries) with scope options (specific/all). It distinguishes from siblings like get_cache_stats (read-only) and retrieve_data/store_data (data operations), though not explicitly named. The purpose is specific but could be more explicit about sibling differentiation.
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 no guidance on when to use this tool versus alternatives like get_cache_stats or store_data. It mentions 'specific or all' but doesn't explain scenarios for each option or prerequisites. Without explicit when/when-not instructions, usage is implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cache statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description implies a read-only operation but does not explicitly state it. No details on side effects or prerequisites.
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?
Extremely concise (two words), but lacks detail on return value and usage context. Could be slightly expanded without losing conciseness.
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?
No output schema and no description of what statistics are returned. Incomplete for a tool that produces output.
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 (100% schema coverage), so the description adds no parameter information but is not required to.
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 retrieves cache statistics, distinguishing it from sibling tools like cached_commands and clear_command_cache. However, it does not specify what type of statistics (e.g., hit rate, size).
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. The description gives no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve data from the cache
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key of the cached data to retrieve |
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 states the action ('retrieve') but doesn't disclose behavioral traits such as error handling (e.g., what happens if the key doesn't exist), performance characteristics, or side effects. This leaves significant gaps for a tool that interacts with a cache.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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 complexity (a cache retrieval tool with no annotations and no output schema), the description is incomplete. It doesn't explain what the return value looks like, error conditions, or how it differs from siblings. This leaves the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'key' parameter fully documented. The description adds no additional meaning beyond what the schema provides (e.g., no examples or constraints). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('retrieve') and resource ('data from the cache'), which provides a basic purpose. However, it's vague about what type of data or cache is involved, and it doesn't distinguish from siblings like 'get_cache_stats' (which might also retrieve data about the cache). It's not tautological but lacks specificity.
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., data must be stored first), exclusions, or comparisons to siblings like 'store_data' or 'clear_cache'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store data in the cache with optional TTL
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Unique identifier for the cached data | |
| value | Yes | Data to cache | |
| ttl | No | Time-to-live in seconds (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool stores data in a cache with optional TTL, which implies a write operation, but doesn't cover critical aspects like whether it overwrites existing keys, requires specific permissions, has rate limits, or what happens on failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes only essential additional detail (optional TTL), making it appropriately sized and easy 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., overwrite behavior, error handling), return values, and usage context relative to siblings. Given the complexity of a write operation, more completeness is needed to guide an agent effectively.
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 input schema already documents all parameters (key, value, ttl) with clear descriptions. The description adds minimal value by mentioning 'optional TTL', which is redundant with the schema. No additional syntax, format, or constraints are provided beyond what's in the structured data.
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 action ('Store data') and target ('in the cache'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'retrieve_data' or 'clear_cache', which would require mentioning it's specifically for writing/inserting data rather than reading or deleting.
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 includes 'with optional TTL', which implies a usage scenario for time-based expiration, but provides no guidance on when to use this tool versus alternatives like 'retrieve_data' for reading or 'clear_cache' for deletion. There's no mention of prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
clear_cacheget_cache_statsretrieve_datastore_dataScored across 4 tools
Each tool has a clearly distinct purpose: clear_cache removes entries, get_cache_stats provides metrics, retrieve_data fetches data, and store_data saves data. There is no overlap or ambiguity between these operations.
Three tools use verb_noun naming (clear_cache, get_cache_stats, retrieve_data), which is consistent, but store_data uses a verb_noun pattern that slightly deviates from the others in verb choice. Overall, the naming is mostly predictable and readable.
With 4 tools, this server is well-scoped for a memory cache domain. Each tool serves a clear, essential function (store, retrieve, clear, stats), and no tool feels redundant or missing for basic cache operations.
The toolset covers core cache operations: store, retrieve, clear, and stats. A minor gap is the lack of an update or delete specific entry tool, but agents can work around this by clearing and re-storing. The surface supports basic workflows effectively.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP memory server. One memory your agents share — across models, devices and apps.
A Model Context Protocol server for Wix AI tools
MCP server for building and testing AI agents with multi-model experimentation and insights.