模型上下文协议 (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 build添加到您的 MCP 客户端设置：
{
"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
应用任何环境变量覆盖
如果未指定，则使用默认值
要查看缓存的实际效果，请尝试以下场景：
文件阅读测试
读取并分析大文件
再次询问有关该文件的相同问题
由于文件内容被缓存，第二次响应应该更快
数据分析测试
对一些数据进行分析
再次请求相同的分析
第二次分析应该使用缓存的结果
项目导航测试
探索项目的结构
再次查询相同的文件/目录
目录列表和文件内容将从缓存中提供
当您注意到以下情况时，缓存正在工作：
重复操作响应更快
对于未改变的内容，给出一致的答案
无需重新读取未更改的文件
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.