Servidores MCP de la comunidad: cuáles merecen la pena

Probado con MCP Inspector 2.7.0 · server-filesystem 2026.8.31 · mcp-server-git 2026.8.18 · DBHub 1.2.5 · PostgreSQL 18.6 · verificado 2026-09-16

Actualizado: 2026-09-16

Publiqué esta guía en junio de 2025 y la he revisado el 16 de septiembre de 2026, cuando el registro oficial del Model Context Protocol (MCP) devolvía 32.514 servidores. El problema ya no es encontrar un servidor MCP para una tarea concreta, es decidir cuál de los que aparecen en la primera página de resultados merece confianza. Aquí están los servidores que uso a diario con Claude Desktop y Claude Code, los que instalé y acabé quitando y los criterios con los que separo el trigo de la paja. Para esta revisión he vuelto a arrancar los cinco que recomiendo, con la versión fijada.

Puntos clave

• Cuatro de los cinco servidores que uso a diario siguen siendo servidores de referencia del proyecto MCP: filesystem, git, fetch y memory.

• El servidor de referencia de Postgres está archivado y su modo de solo lectura se saltaba con un COMMIT. Lo he cambiado por DBHub con un rol de solo lectura.

• El registro oficial de MCP verifica quién publica, no qué publica.

• Los servidores de Slack, correo y APIs SaaS de amplio alcance presentan superficies de ataque demasiado grandes para el beneficio real que aportan.

• El riesgo de cadena de herramientas (un servidor malicioso que usa a otro legítimo para filtrar información) sigue sin resolver en los clientes MCP que uso.

• Cinco criterios antes de instalar cualquier servidor nuevo: procedencia, alcance, trazabilidad, revocabilidad y modelo de actualización. Y no mezclar en una sesión servidores de confianza con comunitarios que no conozcas a fondo.

Lo que ha cambiado desde noviembre de 2024

Cuando Anthropic anunció MCP el 25 de noviembre de 2024^[1], lo acompañó de servidores preconstruidos para Google Drive, Slack, GitHub, Git, Postgres y Puppeteer. De esos seis, solo Git sigue en el repositorio de referencia^[2], que conserva siete servidores mantenidos por el grupo directivo de MCP y ha archivado trece. Su README advierte de que son implementaciones para aprender el protocolo, no piezas pensadas para producción.

La adopción ya no está en duda. El 9 de diciembre de 2025, Anthropic donó MCP a la Agentic AI Foundation^[3], un fondo de la Linux Foundation. En ese momento el proyecto declaraba más de 97 millones de descargas mensuales de sus kits de desarrollo (SDK) y 10.000 servidores activos.

La parte que no ha envejecido bien es el gobierno del catálogo. Los servidores siguen viviendo en repositorios individuales, se instalan con órdenes que descargan paquetes de terceros desde npm, PyPI o Docker Hub, y la garantía principal sigue siendo la reputación del mantenedor. Ese modelo funciona para proyectos maduros y no funciona para novedades con tres días de vida.

¿Qué garantiza el registro oficial de MCP?

El registro oficial garantiza la procedencia del nombre, no la calidad ni la seguridad del servidor. Se lanzó en vista previa el 8 de septiembre de 2025^[4] en registry.modelcontextprotocol.io, y su documentación aún lo presenta así. Guarda metadatos que apuntan a paquetes de npm, PyPI o Docker Hub. Para publicar como io.github.usuario/servidor hay que iniciar sesión con esa cuenta de GitHub, y un nombre con dominio invertido exige demostrar el control del dominio.

Lo que falta es la revisión del contenido. Su política de moderación^[5] pide asumir una moderación mínima o nula y excluye expresamente retirar servidores con vulnerabilidades. El 16 de septiembre de 2026 su API devolvía 32.514 servidores, tres cuentas de GitHub sumaban el 14 % de ellos y no encontré ninguno de los siete de referencia. Estar en el registro no avala nada; úsalo como punto de partida para aplicar los criterios de más abajo.

Los cinco que uso todos los días

Cuatro de los cinco siguen siendo servidores de referencia y el quinto ha cambiado de proyecto. La tabla recoge la versión que probé, cuándo se publicó y si aceptó la revisión 2026-07-28 del protocolo en mis pruebas:

• Servidor MCP de filesystem: da al agente acceso acotado a directorios concretos del disco local. Lo uso para que Claude lea y escriba archivos en un proyecto sin dejarle navegar por el resto del sistema. Dos fallos publicados en julio de 2025 permitían salir de esos directorios (CVE-2025-53109 y CVE-2025-53110): usa la 2025.7.1 o posterior. Pasa los directorios como argumentos: el README aún recomienda Roots, pero la especificación MCP 2026-07-28 depreca esa función.

• Servidor MCP de git: permite al agente leer el estado del repositorio, ver diferencias y consultar el historial cuando lo necesita, sin copiar y pegar salidas de terminal en la conversación. Recibió cuatro avisos de seguridad entre diciembre de 2025 y febrero de 2026, y la 2025.9.25 eliminó la herramienta git_init. Arráncalo siempre con --repository, que desde la 2025.12.18 rechaza rutas fuera de ese repositorio, y usa la 2026.1.14 o posterior.

• DBHub en lugar del servidor MCP de Postgres: conecta Claude con una base de datos de desarrollo y permite explorar el esquema sin escribir SQL de cabeza. Lo configuro en modo de solo lectura y no lo conectaría a una base de datos de producción.

• Servidor MCP de fetch: descarga páginas web y las devuelve en Markdown, recortadas a 5.000 caracteres por defecto. Su README^[6] indica que obedece robots.txt cuando la petición parte del modelo y advierte de que puede alcanzar direcciones IP internas, así que no lo dejo activo junto a servicios internos sin autenticación.

• Servidor MCP de memory: guarda un grafo de conocimiento en un archivo JSON Lines local que el agente consulta y actualiza entre conversaciones^[7]. Es el único servidor donde tengo cuidado con la privacidad: lo guardado persiste de un chat a otro y puede salir por fuentes no previstas si se mezcla con otros servidores. Este servidor también es la capa de persistencia que alimenta los knowledge graphs para LLM.

El cambio de Postgres tiene una causa concreta. Datadog Security Labs demostró el 21 de agosto de 2025^[8] que el modo de solo lectura del servidor de referencia se saltaba enviando COMMIT; antes de la orden de escritura. El paquete está obsoleto desde el 10 de julio de 2025 y aun así sumó 78.432 descargas^[9] entre el 5 y el 11 de septiembre de 2026. Lo reproduje con la 0.6.2 contra una base de pruebas y la tabla desapareció.

DBHub^[10], de Bytebase, es el servidor del ejemplo de PostgreSQL en la documentación de Claude Code^[11]. Con readonly = true filtra las órdenes por palabras clave y las ejecuta en una transacción de solo lectura, pero su documentación^[12] pide igualmente un usuario sin permisos de escritura.

¿Cómo compruebo un servidor MCP antes de conectarlo?

Antes de dárselo a un agente, listo las herramientas del servidor con la interfaz de línea de comandos (CLI) del MCP Inspector^[13] y leo las descripciones que el modelo tratará como instrucciones. Lo hice el 16 de septiembre de 2026 con el Inspector 2.7.0 en un contenedor linux/arm64 con Node.js 24.21.0 y uv 0.12.15. En la versión 2, lo que va antes de -- es el servidor y lo que va después, las opciones del Inspector.

I="npx -y @modelcontextprotocol/inspector@2.7.0 --cli"
FS="npx -y @modelcontextprotocol/server-filesystem@2026.8.31 /work/demo"
T='.result.content[0].text'
$I $FS -- --method tools/list --format json \
  | jq -r '.result.tools[] | "\(.name) ro=\(.annotations.readOnlyHint)"'
$I $FS -- --method tools/call --tool-name read_text_file \
  --tool-arg path=/etc/passwd --format json | jq -r "$T"

La salida marca con ro=true las herramientas que el servidor anota como de solo lectura, y la lectura fuera del directorio permitido falla:

read_file ro=true
read_text_file ro=true
read_media_file ro=true
read_multiple_files ro=true
write_file ro=false
edit_file ro=false
create_directory ro=false
list_directory ro=true
list_directory_with_sizes ro=true
directory_tree ro=true
move_file ro=false
search_files ro=true
get_file_info ro=true
list_allowed_directories ro=true
Access denied - path outside allowed directories: /etc/passwd not in /work/demo

Las anotaciones solo informan al cliente; no impiden ninguna escritura. Con la carpeta montada en solo lectura, write_file falló con EROFS: read-only file system. El servidor de git, arrancado con --repository /work/demo, rechazó las dos pruebas de escape que le hice. Pedir el estado de /work/otro devolvió is outside the allowed repository '/work/demo', y un target que empezaba por guion se rechazó sin crear ningún archivo.

Para DBHub preparé en PostgreSQL 18.6 una tabla clientes de dos filas y una función vaciar_clientes(), creada por su propietario, que vacía la tabla desde dentro de un SELECT. El rol que usa DBHub solo puede leer:

CREATE ROLE lector LOGIN PASSWORD 'clave_del_lector';
GRANT CONNECT ON DATABASE tienda TO lector;
GRANT USAGE ON SCHEMA public TO lector;
GRANT SELECT ON clientes TO lector;
-- como propietario de la tabla:
CREATE FUNCTION vaciar_clientes() RETURNS bigint LANGUAGE sql AS
$$ WITH d AS (DELETE FROM clientes RETURNING 1) SELECT count(*) FROM d $$;

La configuración activa el modo de solo lectura y toma la contraseña del entorno:

[[sources]]
id = "tienda"
dsn = "postgres://lector:${DB_PASSWORD}@db:5432/tienda?sslmode=disable"

[[tools]]
name = "execute_sql"
source = "tienda"
readonly = true
max_rows = 100

[[tools]]
name = "search_objects"
source = "tienda"

Con DB_PASSWORD exportada y las variables del bloque anterior, estas llamadas prueban la inyección de Datadog, la función trampa y el estado final:

DB="npx -y @bytebase/dbhub@1.2.5 --config /work/dbhub.toml"
sql() {
  $I $DB -- -e DB_PASSWORD="$DB_PASSWORD" --method tools/call \
    --tool-name execute_sql --tool-args-json "{\"sql\": \"$1\"}" \
    --format json | jq -r "$T" | jq -c '.code // .data.statements[0].rows'
}
sql "COMMIT; DROP TABLE clientes"
sql "SELECT vaciar_clientes()"
sql "SELECT count(*) AS n FROM clientes"

"READONLY_VIOLATION"
"EXECUTION_ERROR"
[{"n":"2"}]

El primer rechazo viene del filtro de palabras clave (Read-only mode is enabled) y el segundo, de PostgreSQL (cannot execute SELECT in a read-only transaction). La tabla conserva sus dos filas. Esa transacción no frena funciones como pg_read_file en roles privilegiados, así que el rol importa tanto como la opción.

Con la negociación automática, los cinco servidores acordaron la revisión 2025-11-25 del protocolo. Al fijar la 2026-07-28 con --protocol-era modern, los cuatro de referencia fallaron con did not offer pinned protocol version y solo DBHub la aceptó. Los README de git y fetch explican que siguen en la versión 1 del SDK de Python y que el paso a la 2 está en marcha.

No probé el servidor oficial de Slack, que exige un espacio de trabajo y una app registrada, y de fetch y memory solo listé las herramientas. Todo salió del Inspector, no de Claude Desktop ni de Claude Code. La máquina, compartida, tenía una carga media de 22 sobre 18 núcleos, así que no publico tiempos.

Lo que probé y acabé quitando

Probé el servidor MCP de Slack comunitario y lo quité a los pocos días. La funcionalidad era correcta pero el modelo de permisos estaba mal diseñado: una vez conectado, el agente podía leer cualquier canal al que el usuario tuviera acceso, incluidos privados con información sensible. El riesgo de exfiltración accidental por prompt injection indirecta era demasiado alto.

Ese servidor de referencia está archivado, y la bifurcación de Zencoder a la que remite no recibe commits desde el 16 de julio de 2025. Slack publica ahora su propio servidor MCP remoto^[14], solo por Streamable HTTP, y exige que cada cliente sea una app registrada que el administrador del espacio de trabajo puede aprobar. Ese control ataca el problema de permisos que me hizo quitarlo.

Los servidores de correo electrónico que probé los retiré todos. El patrón es parecido: la superficie de ataque de un servidor que lee correo y actúa sobre él es enorme, y los servidores comunitarios no tenían revisiones de seguridad que justificaran el riesgo.

El otro grupo que acabé quitando es el de servidores para APIs SaaS con gran alcance. Un servidor que da al agente acceso completo a la API de Stripe o AWS suena útil hasta que revisas el código. Las credenciales se pasan como variable de entorno sin rotación, sin control fino de permisos y sin registro de auditoría.

La alternativa que ha ganado terreno es el servidor del propio fabricante. El README de referencia remite Brave Search al suyo y GitHub mantiene github-mcp-server^[15], con la 1.12.2 del 16 de septiembre de 2026. Esos servidores resuelven la procedencia; el alcance que les concedes sigue siendo decisión tuya.

Criterios para decidir qué instalar

Con el tiempo he acabado aplicando cinco criterios antes de instalar cualquier servidor MCP nuevo:

• Procedencia. Servidores de referencia del proyecto MCP, servidores que publica el fabricante del servicio, o repositorios con mantenedor identificable y actividad sostenida. El nombre verificado del registro oficial confirma la cuenta o el dominio que publica, y nada más. Los repositorios anónimos con poca actividad se descartan directamente.

• Alcance. Qué hace el servidor y sobre qué. Un servidor que lee un directorio local concreto es distinto de uno con permiso de red arbitrario. Aplicar principio de mínimo privilegio aquí ahorra problemas futuros.

• Trazabilidad. Qué registra el servidor cuando actúa. Un servidor MCP bien hecho registra cada herramienta invocada con argumentos, lo que permite auditar comportamiento después si algo va mal.

• Revocabilidad. Cómo se quita si decides que no lo quieres. Verificar que la desinstalación es limpia es parte de la evaluación.

• Modelo de actualización. Cómo te enteras de que hay una actualización de seguridad. Sigue los repositorios con versiones puntuales y avisos de seguridad publicados^[16], como los seis que acumulan filesystem y git, y desconfía de los que no los publican. Fija la versión en la configuración del cliente en lugar de lanzar npx sin ella.

El riesgo que nadie está mirando

Hay un riesgo transversal que se discute menos de lo que debería. Simon Willison documentó el 9 de abril de 2025 que MCP tiene problemas de inyección de prompts^[17] precisamente por esta vía. Cuando un cliente MCP tiene más de un servidor activo en la misma conversación, los servidores comparten contexto implícitamente a través del agente. Un servidor malicioso puede insertar instrucciones en sus respuestas que dirijan al agente a invocar otro servidor legítimo con argumentos que filtran información.

El propio catálogo OWASP MCP Top 10 clasifica esta variante como «tool poisoning»^[18], así que el riesgo está identificado. Su ficha enumera indicadores que puedes revisar antes de instalar: órdenes dirigidas al modelo, rutas de credenciales o caracteres invisibles en las descripciones de las herramientas. El listado del Inspector de la sección anterior sirve para eso.

Este ataque de cadena de herramientas es difícil de detectar porque cada servidor individual se comporta correctamente. Lo que falla es la composición. Mitigarlo requiere aislar contextos entre servidores no confiables, algo que los clientes MCP que uso no hacen por defecto.

Mi recomendación mientras esto no esté resuelto: no mezclar en la misma sesión servidores de confianza con servidores comunitarios que no conozcas a fondo.

Mi lectura

El protocolo MCP ha ganado la apuesta de adopción. Ha conseguido algo similar a lo que OAuth logró en su momento: establecerse como el mecanismo por defecto para integrar agentes con servicios externos. Desde diciembre de 2025, además, pertenece a una fundación y no a una sola empresa.

El problema que queda sin resolver es el modelo de confianza del catálogo comunitario. Npm aprendió por las malas que un registro sin revisión mínima es un vector de ataque de cadena de suministro. Sonatype contabilizó más de 778.500 paquetes maliciosos desde que empezó a rastrearlos en 2019, con un aumento del 156 % solo en 2024^[19]. MCP está recorriendo el mismo camino acelerado, y su registro formal comprueba quién publica pero deja fuera, por decisión propia, la revisión de seguridad.

Mi recomendación práctica a cualquier equipo que esté adoptando MCP: empezar por los servidores de referencia y por los que publica el propio fabricante del servicio, con la versión fijada. Añadir servidores comunitarios uno a uno, con auditoría manual del código, y desinstalarlos si en un mes no aportan valor medible. El catálogo es amplio y tentador, pero la superficie de ataque crece con cada instalación.

Lee también la versión en inglés: Community MCP servers: which ones are worth it.

Preguntas frecuentes

¿Es seguro conectar el servidor MCP de Postgres a mi base de datos de producción?

No es recomendable. El servidor de referencia de Postgres está archivado desde julio de 2025, y su modo de solo lectura se saltaba enviando un COMMIT antes de la orden de escritura. Si un agente debe consultar Postgres, usa DBHub con readonly = true y un rol que solo tenga permiso de SELECT, y apúntalo a desarrollo, no a producción. La misma lógica de mínimo privilegio se aplica al servidor de filesystem: dar acceso acotado a directorios concretos del proyecto, no dejar al agente navegar por el resto del sistema.

¿Puedo mezclar servidores MCP oficiales y comunitarios en la misma sesión?

Mejor no, mientras no conozcas a fondo el servidor comunitario. Cuando hay más de un servidor activo en la misma conversación, comparten contexto implícitamente a través del agente. Un servidor malicioso puede insertar en sus respuestas instrucciones que lleven al agente a invocar otro servidor legítimo con argumentos que filtran información. Cada servidor individual se comporta bien; lo que falla es la composición, y los clientes MCP que uso no aíslan contextos por defecto.

¿Qué debo comprobar antes de instalar un servidor MCP de la comunidad?

Cinco criterios, empezando por la procedencia: servidor de referencia, servidor del propio fabricante, organización reconocida o mantenedor identificable con actividad sostenida; los repositorios anónimos se descartan. Alcance: leer un directorio local no es lo mismo que tener permiso de red arbitrario. Trazabilidad (que registre cada herramienta invocada con sus argumentos), revocabilidad (que la desinstalación sea limpia) y modelo de actualización (versiones puntuales y avisos de seguridad publicados). Antes de conectarlo, lista sus herramientas con el MCP Inspector y lee sus descripciones; después, añádelos uno a uno y quítalos si en un mes no aportan valor medible.

¿Estar en el registro oficial de MCP garantiza que un servidor es seguro?

No: el registro oficial comprueba que quien publica controla la cuenta de GitHub o el dominio del nombre, y nada más. Su política de moderación pide asumir una moderación mínima o nula y no retira servidores por tener vulnerabilidades. Guarda solo metadatos que apuntan a npm, PyPI o Docker Hub, y el 16 de septiembre de 2026 listaba 32.514 servidores sin ninguno de los siete de referencia. Aplica a todo lo que encuentres en él los mismos criterios de procedencia, alcance y actualización.

Fuentes

1. Anthropic anunció MCP el 25 de noviembre de 2024
2. repositorio de referencia
3. Anthropic donó MCP a la Agentic AI Foundation
4. Se lanzó en vista previa el 8 de septiembre de 2025
5. política de moderación
6. Su README
7. entre conversaciones
8. Datadog Security Labs demostró el 21 de agosto de 2025
9. 78.432 descargas
10. DBHub
11. documentación de Claude Code
12. su documentación
13. MCP Inspector
14. Slack publica ahora su propio servidor MCP remoto
15. github-mcp-server
16. avisos de seguridad publicados
17. Simon Willison documentó el 9 de abril de 2025 que MCP tiene problemas de inyección de prompts
18. OWASP MCP Top 10 clasifica esta variante como «tool poisoning»
19. Sonatype contabilizó más de 778.500 paquetes maliciosos desde que empezó a rastrearlos en 2019, con un aumento del 156 % solo en 2024