How do I use schema-engram-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@schema-engram-mcp retrieve the latest schema for the production database" 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.

schema-engram-mcp

by wabox32

Overview Schema Related Servers Score Discussions

Python

Local

schema-engram-mcp

Servidor MCP (Model Context Protocol) que guarda la estructura de bases de datos (esquema: tablas, columnas, claves, índices, etc.) en un fichero SQLite local. Está pensado como memoria persistente similar en espíritu a Engrams (contexto estructurado para el asistente), pero específico para esquemas de BD.

Herramientas MCP

Herramienta	Descripción
`db_schema_save`	Guarda una instantánea JSON del esquema (`workspace_id`, `connection_name`, …).
`db_schema_get`	Recupera la última instantánea o una por `snapshot_id`.
`db_schema_list`	Lista metadatos de instantáneas (sin volcar todo el JSON).
`db_schema_update`	Actualiza por `snapshot_id` (esquema, metadatos o renombre de workspace/conexión).
`db_schema_delete`	Borra una instantánea por id.

Forma sugerida de `schema` (JSON)

No hay un esquema obligatorio: puedes guardar lo que saques de information_schema, Prisma, SQLAlchemy, etc. Un ejemplo razonable:

{
  "tables": [
    {
      "name": "users",
      "columns": [
        {"name": "id", "type": "uuid", "nullable": false, "primary_key": true},
        {"name": "email", "type": "text", "nullable": false}
      ],
      "foreign_keys": [],
      "indexes": [{"name": "users_email_key", "columns": ["email"], "unique": true}]
    }
  ]
}

Related MCP server: instant-db

Instalación

cd /ruta/al/proyecto
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

Configurar en Cursor

El servidor MCP no usa puerto: Cursor arranca un proceso y habla por stdin/stdout.

1. Dónde pones la configuración

Ámbito	Fichero	Cuándo usarlo
Todo Cursor	`~/.cursor/mcp.json`	Quieres el mismo MCP en todos los proyectos.
Solo este repo	`.cursor/mcp.json` en la raíz del proyecto que abres en Cursor	Quieres dejar la config versionada o por proyecto.

Si ya existe mcpServers con otros servidores, añade la clave "schema-engram" dentro de ese mismo objeto; no borres los demás.

2. Desde la interfaz

Cursor → Settings (⚙️) → busca MCP o Model Context Protocol.
Ahí suele haber un enlace para editar el JSON o añadir servidores.
Tras guardar, reinicia el MCP o Cursor si no aparece el servidor.

(El menú exacto puede variar según la versión; el fichero JSON es lo importante.)

3. Opción A — Python local (sin Docker)

En la máquina donde está clonado este repo:

cd /ruta/al/schema-engram-mcp
python3 -m venv .venv && source .venv/bin/activate && pip install -e .

En mcp.json (rutas absolutas):

{
  "mcpServers": {
    "schema-engram": {
      "command": "/ruta/absoluta/schema-engram-mcp/.venv/bin/python",
      "args": [
        "-m",
        "schema_engram_mcp",
        "--sqlite",
        "/ruta/absoluta/schema-engram-mcp/data/schemas.sqlite"
      ]
    }
  }
}

Si no pasas --sqlite, el valor por defecto del programa es
~/.local/share/schema-engram-mcp/schemas.sqlite (fuera de ./data).

4. Opción B — Docker Compose (recomendado si ya usas Docker)

Antes: docker compose build en la carpeta del repo.
En mcp.json, la ruta del -f debe ser la del docker-compose.yml de este repo (absoluta):

{
  "mcpServers": {
    "schema-engram": {
      "command": "docker",
      "args": [
        "compose",
        "-f",
        "/ruta/absoluta/schema-engram-mcp/docker-compose.yml",
        "run",
        "--rm",
        "-i",
        "mcp"
      ]
    }
  }
}

Hay una plantilla en .cursor/mcp.json.example: cópiala a .cursor/mcp.json (en el proyecto que quieras) y sustituye la ruta.

5. Otro proyecto distinto al del MCP

Si tu app está en /proyecto/mi-api pero el MCP vive en /herramientas/schema-engram-mcp, abres mi-api en Cursor y en mi-api/.cursor/mcp.json pones las rutas absolutas al clon schema-engram-mcp (Python o Docker como arriba). El SQLite puede quedarse en schema-engram-mcp/data/schemas.sqlite.

Variables de entorno

Variable	Significado
`SCHEMA_ENGRAM_SQLITE`	Ruta al fichero SQLite (tiene prioridad si no pasas `--sqlite`).

Docker Compose (recomendado)

Desde la raíz del proyecto:

docker compose build
docker compose run --rm -i mcp

El SQLite se guarda en ./data/schemas.sqlite en tu máquina (carpeta montada en el contenedor).

La parte de Cursor + Docker detallada está en Configurar en Cursor. No uses docker compose up para MCP: hace falta run ... -i.

Solo Docker (sin Compose)

docker build -t schema-engram-mcp:local .
docker run -i --rm -v "$(pwd)/data:/data" schema-engram-mcp:local

Limitación

Este paquete no conecta solo a tu PostgreSQL/MySQL: el cliente MCP (o tú) debe obtener el esquema con las herramientas que ya uses y llamar a db_schema_save con ese objeto JSON.

Available Tools

5 tools

db_schema_deleteB

Elimina una instantánea por id.

ParametersJSON Schema

Name	Required	Description	Default
`snapshot_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but provides minimal behavioral insight. It implies a destructive operation ('Elimina'), but doesn't disclose critical details like whether deletion is permanent, requires specific permissions, has side effects on related data, or what happens on success/failure. This is inadequate 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's destructive nature, lack of annotations, and presence of an output schema (which might cover return values), the description is minimally complete but lacks depth. It states what the tool does but omits important behavioral and usage context needed for safe operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaningful context for the single parameter by specifying that 'snapshot_id' refers to a snapshot to be deleted. With 0% schema description coverage and only one parameter, this adequately compensates, though it could elaborate on ID format or sourcing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Elimina' - deletes/destroys) and the resource ('una instantánea' - a snapshot) by ID, making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like db_schema_update or db_schema_save, which might also modify schema-related data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The description doesn't mention prerequisites, such as needing an existing snapshot ID, or contrast it with siblings like db_schema_list for viewing snapshots or db_schema_save for creating them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_schema_getB

Obtiene un esquema guardado. Si snapshot_id es None, devuelve el más reciente para workspace_id + connection_name.

ParametersJSON Schema

Name	Required	Description	Default
`workspace_id`	Yes
`connection_name`	Yes
`snapshot_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that it returns the most recent schema when snapshot_id is None, which adds some context. However, it lacks details on permissions, error handling, rate limits, or what the output contains (though an output schema exists). For a tool with no annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded: it states the main purpose in the first phrase, followed by a conditional behavior. Both sentences earn their place by providing essential information without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, no annotations, but with an output schema), the description is minimally adequate. It explains the core functionality and one parameter's behavior, but lacks details on permissions, errors, or full parameter semantics. The output schema reduces the need to describe return values, but more context is still needed for a higher score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the behavior of snapshot_id (if None, returns the most recent), which adds meaning for one parameter. However, it doesn't clarify workspace_id or connection_name, leaving two parameters undocumented. This partial coverage is inadequate given the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Obtiene un esquema guardado' (Gets a saved schema). It specifies the verb (obtiene/gets) and resource (esquema guardado/saved schema), making the action clear. However, it doesn't explicitly differentiate from siblings like db_schema_list or db_schema_update, which would require a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use it: 'Si `snapshot_id` es None, devuelve el más reciente para workspace_id + connection_name' (If snapshot_id is None, returns the most recent for workspace_id + connection_name). This gives guidance on parameter behavior but doesn't explicitly mention when to use this tool versus alternatives like db_schema_list or db_schema_update, which would be needed for a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_schema_listC

Lista instantáneas guardadas (sin el cuerpo completo del esquema).

ParametersJSON Schema

Name	Required	Description	Default
`workspace_id`	Yes
`connection_name`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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 lists saved snapshots without full schema bodies, which hints at a read-only operation, but doesn't clarify permissions, rate limits, pagination (implied by 'limit' parameter), or what 'instantáneas' entails. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. It wastes no words and directly communicates the tool's function, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (which should cover return values) and no annotations, the description is minimally adequate for a listing tool. However, with 3 parameters at 0% schema coverage and no behavioral details, it lacks completeness for effective use, especially compared to siblings like db_schema_get. The presence of an output schema slightly mitigates the need to describe returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'instantáneas guardadas' but doesn't explain parameters like workspace_id, connection_name, or limit. The description adds minimal semantic value beyond the schema, failing to clarify what these inputs mean or how they affect the listing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Lista') and resource ('instantáneas guardadas'), specifying it lists saved snapshots without full schema bodies. It distinguishes from siblings like db_schema_get (which likely retrieves full schema) by noting the exclusion of complete schema content. However, it doesn't explicitly name alternatives, keeping it from a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like db_schema_get or db_schema_save. The description implies it's for listing snapshots, but it doesn't specify contexts, prerequisites, or exclusions, leaving the agent to infer usage from sibling names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_schema_saveA

Guarda una instantánea del esquema de una base de datos.

schema debe ser un objeto JSON con la estructura que quieras persistir (por ejemplo tablas con columnas, tipos, nullability, PK/FK e índices).

Args: workspace_id: Identificador del proyecto o carpeta (p. ej. nombre del repo). connection_name: Nombre lógico de la BD (p. ej. local, staging, prod). schema: Objeto o texto JSON con el esquema. dialect: Opcional: postgresql, mysql, sqlite, etc. label: Etiqueta opcional (p. ej. versión de migración). summary: Nota corta opcional.

ParametersJSON Schema

Name	Required	Description	Default
`workspace_id`	Yes
`connection_name`	Yes
`schema`	Yes
`dialect`	No
`label`	No
`summary`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a save/persist operation, it doesn't describe important behavioral traits like whether this creates new records or overwrites existing ones, authentication requirements, error conditions, or rate limits. The description provides basic functional context but lacks critical operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and well-structured with a clear purpose statement followed by parameter explanations. The Args section is organized, though the Spanish/English mix slightly affects coherence. Every sentence adds value with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, mutation operation) and the presence of an output schema (which handles return values), the description provides good contextual coverage. It explains all parameters meaningfully and states the tool's core purpose. The main gap is lack of behavioral transparency details that would be important for a write operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description provides substantial semantic value for all 6 parameters. It explains workspace_id as 'proyecto o carpeta (p. ej. nombre del repo)', connection_name as 'nombre lógico de la BD', schema structure expectations, dialect options, and label/summary purposes. This compensates well for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verb ('Guarda una instantánea') and resource ('esquema de una base de datos'), distinguishing it from siblings like delete, get, list, and update. It precisely communicates this is a save/persist operation for database schema snapshots.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through the parameter explanations (e.g., workspace_id as 'proyecto o carpeta', connection_name as 'nombre lógico de la BD'), but doesn't explicitly state when to use this tool versus alternatives like db_schema_update or db_schema_delete. No explicit 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.

db_schema_updateA

Actualiza una instantánea existente. Debes indicar el mismo workspace_id y connection_name que tenía el registro (sirven como comprobación).

Los argumentos opcionales con valor por defecto en el cliente no aplican cambios salvo que los envíes: schema sustituye el JSON completo; dialect, label y summary solo se escriben si los pasas (cadena vacía → NULL en BD).

new_workspace_id / new_connection_name renombran la instantánea si se indican. Con bump_captured_at=true (por defecto) se actualiza la fecha de la fila.

ParametersJSON Schema

Name	Required	Description	Default
`snapshot_id`	Yes
`workspace_id`	Yes
`connection_name`	Yes
`schema`	No
`dialect`	No
`label`	No
`summary`	No
`new_workspace_id`	No
`new_connection_name`	No
`bump_captured_at`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the update requires matching workspace_id and connection_name for verification, optional parameters only apply changes if sent, schema replaces the entire JSON, empty strings become NULL in the database, new_workspace_id/new_connection_name rename the snapshot, and bump_captured_at updates the row date by default. This covers mutation effects, data handling, and default behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core purpose. Each sentence adds value: verification requirements, optional parameter behavior, renaming functionality, and date update default. While slightly dense, there's minimal waste, and the structure guides the reader through key aspects efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, mutation tool, no annotations) and the presence of an output schema (which handles return values), the description is largely complete. It explains verification needs, parameter behaviors, renaming, and date updates. The main gap is lack of explicit error cases or permissions, but it covers most operational context well for an update tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates excellently by explaining the semantics of most parameters: workspace_id and connection_name serve as verification, schema replaces the entire JSON, dialect/label/summary only write if passed, new_workspace_id/new_connection_name rename the snapshot, and bump_captured_at updates the date. It adds crucial meaning beyond the bare schema, covering 9 of 10 parameters effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Actualiza una instantánea existente' (Updates an existing snapshot), providing a specific verb (update) and resource (snapshot). It distinguishes from sibling tools like db_schema_delete, db_schema_get, db_schema_list, and db_schema_save by focusing on modification rather than creation, retrieval, listing, or deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when updating an existing snapshot, mentioning that workspace_id and connection_name serve as verification. However, it doesn't explicitly state when to use this tool versus alternatives like db_schema_save (for creation) or provide clear exclusions. The guidance is contextual but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Mar 20, 2026
- First observeddb_schema_delete
- First observeddb_schema_get
- First observeddb_schema_list
- First observeddb_schema_save
- First observeddb_schema_update

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: delete removes a snapshot, get retrieves one, list shows metadata without full schema, save creates a new snapshot, and update modifies an existing one. The operations map cleanly to CRUD lifecycle stages with no overlap or ambiguity.

Naming Consistency5/5

All tools follow a perfect 'db_schema_' prefix with consistent verb suffixes (delete, get, list, save, update). The naming pattern is uniform across all five tools, making them easily predictable and readable.

Tool Count5/5

With 5 tools, this server is well-scoped for managing database schema snapshots. Each tool serves a clear function in the lifecycle (list, get, save, update, delete), and no tool feels redundant or missing for the domain.

Completeness5/5

The tool set provides complete CRUD coverage for schema snapshots: list for discovery, get for retrieval, save for creation, update for modification, and delete for removal. There are no obvious gaps, and the descriptions support full lifecycle management.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Motecloud MemoryOAuth
io.github.motecloud
Cloud-hosted MCP server for durable AI memory
Knowledge & Memory Cloud Platforms
2
InstantOAuth
com.instantdb.mcp
The Instant MCP server is a wrapper around the Instant Platform SDK that enables creating, managing, and updating InstantDB applications directly within an editor. It provides tools for fetching rules files for LLMs, retrieving and pushing app schemas, managing permission rules, and executing database queries. Key capabilities include schema management (get-schema, push-schema), permission management (get-perms, push-perms), query execution, and listing recent query history.
Databases Developer Tools App Automation
2
Synap Memory A
ai.maximem
Persistent memory for AI agents — log and recall conversation context over MCP.
Knowledge & Memory AI & Machine Learning
4248
Living MemoryOAuth
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
22

Related MCP Servers

Memento
Knowledge & Memory Databases Vector Databases
iAchilles
A
license
A
quality
C
maintenance
A local, fully-offline MCP memory server that enables persistent storage and retrieval of information using SQLite with both keyword and semantic vector search capabilities.
Updated 3 months ago (2026-06-12 22:05 UTC)
10
23
12
MIT
instant-db
Databases Developer Tools App Automation
urbushey
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI assistants to create and manage persistent SQLite databases through natural language without requiring SQL knowledge. It allows users to propose schemas, store records, and perform complex queries across multiple databases for structured data tracking.
Updated 2 months ago (2026-07-07 23:15 UTC)
MIT
memory-engine-mcp
Knowledge & Memory Autonomous Agents
kagioneko
F
license
Not graded
quality
D
maintenance
An MCP server that provides persistent memory for AI agents by storing session snapshots, factual memories, and conversation summaries. It enables seamless continuity between interactions by allowing agents to restore previous emotional states and recall relevant past experiences.
Updated 6 months ago (2026-03-16 02:27 UTC)
-
Context Portal MCP (ConPort)
Knowledge & Memory RAG Systems
fastmcp-me
A
license
Not graded
quality
D
maintenance
A database-backed MCP server that acts as a project memory bank, enabling AI assistants to store, retrieve, and search structured context like decisions, tasks, and architecture using SQLite and vector embeddings.
Updated a year ago (2025-10-19 16:34 UTC)
Apache 2.0

Appeared in Searches

A server for automatically scanning and loading database table structures into AI agent context

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wabox32/schema-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

schema-engram-mcp

Herramientas MCP

Forma sugerida de schema (JSON)

Instalación

Configurar en Cursor

1. Dónde pones la configuración

2. Desde la interfaz

3. Opción A — Python local (sin Docker)

4. Opción B — Docker Compose (recomendado si ya usas Docker)

5. Otro proyecto distinto al del MCP

Variables de entorno

Docker Compose (recomendado)

Solo Docker (sin Compose)

Limitación

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

Forma sugerida de `schema` (JSON)