Prototipo · Versión preliminar: todos los servidores del registro oficial, sincronizados cada 30 minutos. Las reseñas y las cuentas llegarán en una etapa posterior.
PopNx MCPServidores MCP para quienes usan IA · explicados con palabras sencillas

MCP Assist — Coordination Memory

de aliomraniHversión 0.4.1i★ –iSe ejecuta en la nube
Nombre en el registroio.github.aliomraniH/mcp-assist-memory

Instalar

Resumen

Descripción del creador (original en inglés)

Coordination memory with verification: reconcile-against-GitHub, verdict freshness, provenance.

Los tres pilares de PopNx MCP

Estos tres nunca se combinan en una sola puntuación: las opiniones, las mediciones y la popularidad son cosas distintas.

Qué puedes hacer con él

Todavía no escribimos un resumen sencillo para este. Abajo están los datos que leímos del registro.

  • Conexión: Se ejecuta en la nube
  • Transporte: Streamable HTTP
  • Categoría: Búsqueda y memoria de IA
  • Debes completar: Authorization

Instalación

Elige la app de IA que usas y copia la configuración.

Antes de instalar

Los valores marcados como secretos son llaves de tu cuenta. Nunca los compartas ni los pegues en un chat.

Necesitas

¿Qué app usas?

Elige tu app arriba. La recordamos, así que la próxima vez el botón dirá “Instalar en …”.

Esta dirección necesita una clave en un header de la solicitud, y el menú para agregar conectores no puede ponerla. Usa Claude Code, Cursor o VS Code.

Ejecuta esto en tu terminal

claude mcp add --transport http assist-memory https://mcp-assist-memory.replit.app/mcp --header 'Authorization: your-value'

Completa los valores vacíos antes de ejecutarlo.

Abrir en Cursor

O copia la configuración tú

Pégalo en .cursor/mcp.json de tu proyecto, o en ~/.cursor/mcp.json

{
  "mcpServers": {
    "assist-memory": {
      "url": "https://mcp-assist-memory.replit.app/mcp",
      "headers": {
        "Authorization": "your-value"
      }
    }
  }
}

Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.

Abrir en VS Code

O copia la configuración tú

Pégalo en .vscode/mcp.json de tu proyecto

{
  "servers": {
    "assist-memory": {
      "type": "http",
      "url": "https://mcp-assist-memory.replit.app/mcp",
      "headers": {
        "Authorization": "your-value"
      }
    }
  }
}

Tu navegador te pide permiso para abrir la app; luego la app muestra la configuración y te pide confirmar. Los valores de las claves quedan vacíos para que los completes tú.

Esta dirección necesita una clave en un header de la solicitud, y el menú para agregar conectores no puede ponerla. Usa Claude Code, Cursor o VS Code.

Tu elección se guarda en una cookie en este dispositivo; no necesitas cuenta.

Valores que debes completar

  • Authorization secreto obligatorio HTTP header
    Bearer — operator-issued per-surface token; all MCP access requires it

Esta configuración se genera a partir de la ficha del creador en el registro. Si el README dice otra cosa, sigue el README.

Qué puede hacer

Todavía no hemos leído la lista de herramientas de este servidor; revisamos los endpoints por turnos.

Revisiones básicasi

Revisamos información que cualquiera puede ver; no hemos leído el código. Las revisiones que no aplican no se cuentan. · Revisado el 7 nov 2026

  • ✓ Superada

    El creador coincide con el repo

    El nombre en el registro se verificó con la cuenta de GitHub aliomraniH, dueña del repo

  • … Aún sin revisar

    Sigue en mantenimiento

    Todavía no hemos leído este repo en GitHub

  • … Aún sin revisar

    Tiene licencia

    Todavía no hemos leído este repo en GitHub

  • … Aún sin revisar

    El endpoint responde

    Aún sin revisar; revisamos los endpoints por turnos

  • … Aún sin revisar

    Inicio de sesión con OAuth

    Aún sin revisar; revisamos los endpoints por turnos

  • … Aún sin revisar

    Sin instrucciones ocultas en las descripciones de herramientas

    Aún sin revisar; leemos la lista de herramientas cuando revisamos el endpoint

Comparado con otros en Búsqueda y memoria de IAi

  • Más estrellas que el 0% de los otros 5653 servidores de esta categoría
  • Publicado en el registro más recientemente que el 30% de los otros 5653 servidores de esta categoría
  • Revisiones básicas iguales o mejores que el 100% de los otros 5653 servidores de esta categoría

Comparado con todos los servidores activos de esta categoría en el registro. Las estrellas solo cuentan cuando quien lo publica es dueño del repo.

Preguntas frecuentes

¿Es seguro MCP Assist — Coordination Memory?

Superó 1 de 1 revisiones básicas aplicables. No hemos leído el código. Antes de agregar una clave o un token, revisa qué acceso pide el servidor y usa una clave que tenga solo los permisos que necesitas.

¿Qué claves o códigos necesita?

Debes completar: Authorization

¿Se ejecuta en mi computadora o en la nube?

Se ejecuta en la nube del creador. Te conectas por internet sin instalar nada, pero lo que envías pasa por los servidores del creador.

¿Sigue en mantenimiento?

El repo de GitHub cambió por última vez –, y la última versión (0.4.1) llegó al registro hace 3 meses.

¿Qué apps pueden usarlo?

Las apps compatibles con MCP, como Claude Desktop, Claude Code, Cursor y VS Code. Se conecta por URL, así que también funcionan las apps que aceptan servidores MCP remotos, como ChatGPT en modo desarrollador.

¿Qué puedo usar en su lugar?

En la misma categoría: Context7, Codebase Memory, Exa

Alternativas

Servidores de la misma categoría hechos por otros creadores, ordenados por estrellas.

Cómo leer una tarjeta:★ Estrellas de GitHubiTres pilares: reseñas · revisiones · usoiActualizado = fecha en que se publicó la última versión en el registroi

Context7

de upstash

Up-to-date docs for AI agents

Computadora o nube★ 64.224MITActualizado ayer
Instalar

Codebase Memory

de DeusData

Codebase knowledge graph for AI agents — 162 languages, sub-ms queries, 99% fewer tokens.

Se ejecuta en tu computadora★ 48.148MITActualizado hace 21 días
Instalar

Exa

de exa-labs

Connect AI agents to Exa for web search, content fetching, and multi-step research.

Se ejecuta en la nube★ 5213MITActualizado hace 2 meses
Instalar

README del creador

Abrir el README

Copiado tal cual del repo del creador. PopNx MCP no lo ha revisado ni lo respalda. Se quitaron HTML, imágenes y scripts. Los enlaces llevan fuera de este sitio.

mcp-assist-memory

A generic, project-agnostic memory / coordination / artifact server for multi-agent and multi-surface work. One FastAPI process serves a 30-tool MCP over Streamable HTTP, backed by Postgres (+ pgvector), deployed standalone on a Replit Reserved VM.

This is Tier 1 of the reusability contract: every project reuses it as-is. It carries zero domain terms — project identity lives in namespace *values*, never in tool names, tables, columns, or code.

Capabilities at a glance
  • 30-tool MCP over Streamable HTTP (memory, handoff, session, artifact, coordination, feedback, admin).
  • Trust-boundary spine (Plan v2) — actor-scoped exactly-once writes with visible dedup, read-back-verified acks (verified_persisted), standardized error payloads with remedies, write-time screening + quarantine, provenance tiers (origin, model attribution, derived_from lineage), trust decay (needs_reverification), PHI-safe tool_events telemetry, per-namespace variant profiles, and an observation_log feedback channel.
  • Namespace-scoped multi-tenancy — every per-project query filters on namespace.
  • Resilient to transient DB drops — the server transparently retries genuine connection losses (Neon scale-down / PgBouncer recycle, SQLSTATE 57P01/08xxx) on a fresh pooled connection, and validates connections at checkout, so callers no longer have to retry. Retries are idempotency-gated, so they never double-write.
  • Prompt-injection resistance layer — values are sanitized on write (forged markers are escaped one-way to [[UNTRUSTED_DATA]], never reconstructed on read), instruction-shaped writes are screened and quarantined (visible in the write ack; include_quarantined: true opts reads back in), and reads come back wrapped in << >> markers; storage.sanitize.unwrap_value recovers the raw value when a consumer needs it (e.g. to json.loads). Honest framing: these are layers, not proofs — deterministic screens and wrappers are bypassable by an adaptive attacker; adversarial evaluation is pending (see Phase 10 backlog in DECISION-PROTOCOL.md).
  • Content-addressed artifacts (sha256, global dedup), 50 MB cap, ranged reads.
  • Per-surface rotatable tokens (web vs. desktop-cli) managed from a password-gated /admin dashboard.

The 30 tools

GroupTools
memorymemory_save memory_get memory_list memory_history memory_delete memory_search
handoffhandoff_save handoff_load handoff_list
sessionsession_create session_append_event session_get session_list session_events
artifactartifact_put artifact_get artifact_list
coordinationcoord_health coord_drift_scan coord_reconcile coord_curate
gateintent_open skill_define gate_close_outcome gate_cache_status
sequencesession_bootstrap namespace_init recall
feedbackobservation_log
adminstats

Sequences are the paths an agent should take. Correct use of this server has always been a *sequence* — learn which database answered, resolve the profile, check what is stale, then act — and that ordering used to live in tool descriptions and skills, i.e. it was enforced by a model remembering advice mid-task, and a skipped step produced no signal whatsoever. The three sequence tools run their steps server-side in a fixed order and return steps_run, so the ordering is something the server did rather than something a caller got right. They are strictly additive: every primitive they are built from still works exactly as before, for surgical use.

recall and memory_search now share ONE retrieval guard (storage/retrieval.py): the same absolute floor and relative alpha the Intent Gate applies. Previously memory_search had no floor at all while intent_open had both, so the same store answered the same question differently depending on which tool the caller reached for. They still differ in what they do with the verdict — memory_search annotates every row and drops nothing, recall filters by default and reports the rejected counts — but they can no longer disagree about what counts as a match.

The Intent Gate (claude/intent-gate/INTENT_GATE_CHARTER.md) is a per-namespace opt-in (variant_profiles.profile.intent_gate: "on"): mutating tools gain a deterministic Tier-0 pre-flight (two-phase preview/confirm for supersession + delete, dependency-freshness flags, compact gate ack block), intent_open adds the Tier-1 memory-similarity critic, and Tier 2 (LLM reasoning over the direct Anthropic API — never MCP sampling) ships behind tier2: "on" (default off). Default-profile namespaces are byte-identical to the pre-gate server.

/healthz (liveness) and the /admin token dashboard are served separately (not MCP tools).

Tenancy — namespace is the project boundary

`namespace` == project == tenant. One namespace per project (e.g. acme-billing), with conventional sub-scopes by key prefix (coord/…, knowledge/…). Every per-project tool takes a required namespace and every query filters on it — there are no implicit cross-project reads. The session and session_event tables carry namespace too, so episodic memory is scoped like everything else.

Artifacts are the deliberate exception: they are content-addressed (sha256) and dedup globally, so they are not tenant-scoped — the hash is the capability.

Honest limit (and the v2 fix)

The per-surface tokens scope which client surface connects, not which project it may touch: any holder of any active token can pass any namespace, so namespace remains a soft boundary — real isolation for honest clients, not enforced against a misbehaving one.

v2 auth roadmap — per-project tokens/roles. A token scoped to

acme-billing must not be able to read or write other-project. Until then,

treat the namespace boundary as a convention enforced by client configuration,

not by the server. (See REUSABILITY.md → "namespace is the tenant boundary".)

Auth & the /admin dashboard

MCP tokens are stored in Postgres (admin_auth_tokens) and rotatable from `/admin` without a redeploy. There is one active token per surface:

surfacelabelhow the client sends it
claude.ai web connectorweb?token= in the URL (the web connector can't send headers)
Claude Desktop and the Claude Code CLIdesktop-cliAuthorization: Bearer
CursorcursorAuthorization: Bearer (via .cursor/mcp.json)

The gate accepts any active token, so each surface can be rotated or revoked independently — rotating web never disturbs desktop-cli or cursor. The /admin page shows one card per surface with a ready-to-paste URL/command and its own rotate button.

MCP_AUTH_TOKEN seeds the `web` token on initial boot (so an existing claude.ai connector keeps working); desktop-cli and cursor are auto-generated. After first boot the dashboard is the source of truth.

  • /admin is password-gated by `ADMIN_PASSWORD` (signed, HttpOnly session cookie, CSRF-protected). Without it the dashboard refuses logins.
  • The only routes not behind the bearer gate are GET /healthz, the streamed GET /artifact/{sha256}, and /admin (which self-authenticates).

Stateless transport. /mcp runs in stateless HTTP mode (http_app(stateless_http=True)): every request is self-contained, with no in-memory session affinity. Client sessions therefore survive VM restarts/redeploys, and the three surfaces share no server-side session state.

Architecture

  • One AsyncConnectionPool created in the FastAPI lifespan (app.py), injected via deps. Nothing else opens a connection. The pool is built with check=AsyncConnectionPool.check_connection, so a connection terminated server-side while idle is validated and discarded on checkout, never handed to a caller.
  • One config.py (pydantic-settings) — the only place secrets are read.
  • StorageBackend ABC (storage/base.py) implemented by PostgresBackend; the 18 tools map 1:1 onto it.
  • Transparent reconnect: reads and idempotent writes retry on a connection drop (_retry_on_disconnect), so e.g. OperationalError: terminating connection due to administrator command (SQLSTATE 57P01, Neon scale-down / PgBouncer) is retried on a fresh pooled connection instead of surfacing to the caller. Only genuine disconnects (08xxx / 57P0x / an already-closed connection) are retried — other operational errors (lock timeout, too-many-connections) surface unchanged. Writes retry only when a replay is safe: artifact_put (content-addressed) always, and memory_save/handoff_save/memory_delete only when given an event_id (exactly-once). The session_* writes also retry, with an explicit tradeoff: a drop in the narrow commit-ack window means session_create may orphan an empty, unreferenced session row, and session_append_event is at-least-once (a replay can append one duplicate event). For an append-only session log that beats failing the call outright; a save with no event_id still runs once and surfaces the error.
  • Write-path sanitize strips forged delimiters/control chars; reads wrap values in << >> markers (lethal-trifecta defense). Note: the value (and session-event payload) fields come back wrapped, so a consumer that needs the raw value — e.g. to json.loads a value that was a JSON string — must strip the markers first. Use storage.sanitize.unwrap_value (or strip_untrusted for a single string); the wrapping stays applied on every read.
  • Bounded lifespan readiness (no unbounded pool.wait()), 50 MB artifact cap, ranged blob reads, idempotent event_id writes, idempotent blob backfill.
  • Semantic recall (`memory_search`): when a VOYAGE_API_KEY is set, every memory_save embeds the entry (Voyage, voyage-3.5-lite, 1024-dim) into a nullable embedding vector(1024) column with an HNSW cosine index, and memory_search ranks live entries by meaning (embedding <=> query), then backfills keyword/substring matches up to limit. Embedding is best-effort: it runs before a connection is taken and never blocks (or fails) a write, and with no key the column stays NULL and search degrades to pure keyword — the pre-Phase-3 behavior. Every leg filters on namespace first (no cross-project recall). After enabling a key on an existing DB, embed old rows once with python scripts/backfill_embeddings.py (idempotent, only touches NULL rows).
  • Recall tuning (`hnsw.ef_search`): the HNSW index is approximate, so a larger store can miss relevant hits unless its query-time recall parameter is tuned. memory_search sets hnsw.ef_search per-statement (transaction-local, semantic leg only) from HNSW_EF_SEARCH (default 100; pgvector's own default is 40). Higher = better recall, slightly slower search; it must be >= the search limit to take effect. Small stores return the same rows regardless, so the default is safe to leave alone — raise it (e.g. 200) if a large tenant reports missing results, lower it toward 40 to shave latency. Very large tenants can also tune the index build parameters (m, ef_construction); see migrations/0002_embeddings.sql (changing those requires recreating the index).
  • Coordination reconciler (`coord_reconcile`): when GitHub access is available, a claim (with meta.repo + meta.pr/meta.branch) is resolved against live GitHub — is PR #N merged? what is branch X's head? — and stamped with an append-only verdict; without access it stays unverifiable (never a wrong current). Access is sourced in priority order: an explicit GITHUB_TOKEN (read-only repo + PRs), e

Solo se muestra el principio; lee el resto en el repo

Pregunta a PopNx