언어 모델 상호작용 간에 데이터를 효율적으로 캐싱하여 토큰 소비를 줄이는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 모든 MCP 클라이언트 및 토큰을 사용하는 모든 언어 모델과 호환됩니다.
Smithery 를 통해 Claude Desktop용 메모리 캐시 서버를 자동으로 설치하려면:
지엑스피1
저장소를 복제합니다.
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
서버가 정상적으로 실행되면 다음이 표시됩니다.
터미널에 "Stdio에서 실행 중인 메모리 캐시 MCP 서버"라는 메시지가 표시됩니다.
동일한 데이터에 여러 번 액세스할 때 성능이 향상되었습니다.
귀하에게는 아무런 조치가 필요하지 않습니다. 캐싱은 자동으로 수행됩니다.
서버가 실행 중인지 확인하려면 다음을 수행하세요.
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)
캐시에 저장할 수 있는 최대 항목 수
캐시가 무한정 커지는 것을 방지합니다.
초과 시 가장 오래된 미사용 항목부터 제거됩니다.
maxMemory (기본값: 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.