Un servidor de Protocolo de Contexto de Modelo (MCP) que reduce el consumo de tokens mediante el almacenamiento eficiente de datos en caché entre interacciones del modelo de lenguaje. Funciona con cualquier cliente MCP y cualquier modelo de lenguaje que utilice tokens.
Para instalar Memory Cache Server para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @tosin2013/mcp-memory-cache-server --client claudeClonar el repositorio:
git clone https://github.com/tosin2013/mcp-memory-cache-server.git
cd mcp-memory-cache-serverInstalar dependencias:
npm installConstruir el proyecto:
npm run buildAñade a la configuración de tu cliente MCP:
{
"mcpServers": {
"memory-cache": {
"command": "node",
"args": ["/path/to/ib-mcp-cache-server/build/index.js"]
}
}
}El servidor se iniciará automáticamente cuando utilice su cliente MCP
Related MCP server: Claude Continuity MCP Server
Cuando el servidor esté funcionando correctamente, verás:
Un mensaje en la terminal: "El servidor MCP de memoria caché se está ejecutando en stdio"
Rendimiento mejorado al acceder a los mismos datos varias veces
No se requiere ninguna acción por su parte: el almacenamiento en caché se realiza automáticamente
Puede verificar que el servidor esté funcionando mediante:
Abrir su cliente MCP
Buscando cualquier mensaje de error en la terminal donde iniciaste el servidor
Realizar operaciones que se beneficiarían del almacenamiento en caché (como leer el mismo archivo varias veces)
El servidor se puede configurar a través de config.json o variables de entorno:
{
"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 (predeterminado: 1000)
Número máximo de elementos que se pueden almacenar en la caché
Evita que la caché crezca indefinidamente
Cuando se excede, los elementos no utilizados más antiguos se eliminan primero
maxMemory (predeterminado: 100 MB)
Uso máximo de memoria en bytes
Previene el consumo excesivo de memoria
Cuando se excede, se eliminan los elementos utilizados menos recientemente
defaultTTL (predeterminado: 1 hora)
Cuánto tiempo permanecen los elementos en la caché de forma predeterminada
Los artículos se eliminan automáticamente después de este tiempo.
Evita que los datos obsoletos consuman memoria
checkInterval (predeterminado: 1 minuto)
Con qué frecuencia el servidor comprueba si hay elementos caducados
Los valores más bajos mantienen el uso de la memoria más preciso
Los valores más altos reducen el uso de la CPU
statsInterval (predeterminado: 30 segundos)
Con qué frecuencia se actualizan las estadísticas de caché
Afecta la precisión de las tasas de aciertos y errores
Ayuda a monitorear la efectividad del caché
El servidor de caché de memoria reduce el consumo de tokens al almacenar automáticamente datos que, de otro modo, tendrían que reenviarse entre usted y el modelo de lenguaje. No necesita hacer nada especial: el almacenamiento en caché se realiza automáticamente al interactuar con cualquier modelo de lenguaje a través de su cliente MCP.
A continuación se muestran algunos ejemplos de lo que se almacena en caché:
Al leer un archivo varias veces:
Primera vez: se lee y almacena en caché el contenido completo del archivo
Veces posteriores: el contenido se recupera de la caché en lugar de volver a leer el archivo
Resultado: Se utilizan menos tokens para operaciones de archivos repetidas
Al realizar cálculos o análisis:
Primera vez: se realiza el cálculo completo y los resultados se almacenan en caché
Veces posteriores: los resultados se recuperan de la caché si la entrada es la misma
Resultado: Se utilizan menos tokens para cálculos repetidos
Cuando se necesitan los mismos datos varias veces:
Primera vez: los datos se procesan y almacenan en caché
Veces posteriores: los datos se recuperan de la caché hasta que expira el TTL
Resultado: Se utilizan menos tokens para acceder a la misma información
El servidor gestiona automáticamente el proceso de almacenamiento en caché mediante:
Almacenamiento de datos cuando se encuentran por primera vez
Entrega de datos en caché cuando estén disponibles
Eliminar datos antiguos o no utilizados según la configuración
Seguimiento de la eficacia mediante estadísticas
Más corto para datos que cambian con frecuencia
Más largo para contenido estático
Más alto para mayor almacenamiento en caché (más ahorro de tokens)
Más bajo si el uso de memoria es una preocupación
Alta tasa de aciertos = buen ahorro de tokens
Tasa de aciertos baja = ajustar TTL o límites
Puede anular la configuración de config.json utilizando variables de entorno en la configuración de MCP:
{
"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
}
}
}
}También puede especificar una ubicación de archivo de configuración personalizada:
{
"env": {
"CONFIG_PATH": "/path/to/your/config.json"
}
}El servidor hará lo siguiente:
Busque config.json en su directorio
Aplicar cualquier modificación de variable de entorno
Utilice valores predeterminados si no se especifica ninguno
Para ver el caché en acción, pruebe estos escenarios:
Prueba de lectura de archivos
Leer y analizar un archivo grande
Vuelve a hacer la misma pregunta sobre el archivo.
La segunda respuesta debería ser más rápida ya que el contenido del archivo está almacenado en caché.
Prueba de análisis de datos
Realizar análisis sobre algunos datos
Solicitar nuevamente el mismo análisis
El segundo análisis debe utilizar resultados almacenados en caché
Prueba de navegación del proyecto
Explorar la estructura de un proyecto
Consultar nuevamente los mismos archivos/directorios
Los listados de directorios y el contenido de los archivos se servirán desde la caché
El caché está funcionando cuando notas:
Respuestas más rápidas para operaciones repetidas
Respuestas consistentes sobre contenido sin cambios
No es necesario volver a leer archivos que no han cambiado
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.