Un servidor MCP local y uno remoto parecen idénticos una vez en marcha: la misma lista de herramientas en el cliente, la misma conversación, el mismo resultado. La diferencia está en lo que usted entregó para llegar hasta ahí. Un servidor local es un programa en su máquina que el cliente arranca y con el que habla por la entrada y la salida estándar, y lo que entrega es una línea de comandos. Un servidor remoto es el extremo HTTPS de otra persona, y lo que entrega es una credencial, junto con todo lo que esa credencial abre, durante todo el tiempo que la deje viva.
Así que la pregunta útil antes de pegar una URL en el diálogo de un conector no es «este servidor es de fiar», que nadie puede responder desde una página de catálogo. Son tres preguntas más estrechas que sí tienen respuestas consultables: a qué está limitado el token, adónde ir para retirarlo y qué comprobó de verdad el catálogo en el que encontró el servidor. Las respuestas de abajo se apoyan en la especificación MCP y en la documentación de los fabricantes tal como estaban el 16 de agosto de 2026.
La revisión actual de la especificación, 2026-07-28, trata los dos transportes como contextos de seguridad diferentes. La autorización es opcional en MCP, y dónde aplica está explícito: las implementaciones que usan un transporte HTTP deberían ajustarse a la especificación OAuth, mientras que las implementaciones stdio no deberían seguirla en absoluto y obtener las credenciales del entorno. HTTP+SSE, el transporte remoto antiguo, está obsoleto; Streamable HTTP es el que cabe esperar.
| Local (stdio) | Remoto (Streamable HTTP) | |
|---|---|---|
| Qué entrega | Un comando que su cliente ejecutará | Una URL y, normalmente, una concesión OAuth |
| Dónde se ejecuta el código | Su máquina, su cuenta de usuario | Infraestructura que opera otra persona |
| Credenciales | Tomadas del entorno | Token de acceso ligado a ese único servidor |
| Qué hace «desconectar» | Deja de lanzar un proceso | Borra la copia del token del cliente; la concesión puede sobrevivir |
| Peor caso si el autor es hostil | Código arbitrario con sus privilegios | Todo lo que alcancen los scopes aprobados |
Ninguna de las dos columnas es la segura. Un servidor local es código arbitrario ejecutándose como usted, que es justo la razón de que la especificación exija que un cliente que ofrezca configuración local en un clic muestre el comando exacto que va a ejecutar, sin truncar, y obtenga aprobación explícita antes. Un servidor remoto no pone código en su máquina, pero mueve sus datos a un operador y deja una vía de acceso que sobrevive a su atención. Los dos fallan en direcciones distintas; nuestra comparación de qué puede ver cada tipo lo desarrolla con más detalle.
El modelo de autorización es OAuth 2.1, y la parte que conviene entender como
usuario es la vinculación de audiencia. Los clientes deben implementar Resource
Indicators for OAuth 2.0 (RFC 8707): el parámetro resource tiene que enviarse
tanto en la petición de autorización como en la de token, nombrando al servidor
concreto para el que es el token. Los servidores deben validar que los tokens se
emitieron para ellos, aceptar solo tokens válidos para sus propios recursos y no
deben aceptar ni retransmitir ningún otro. Pasar el token de un cliente a una
API de más abajo —el «token passthrough»— está prohibido sin matices.
Así que un token bien implementado no sirve de nada en otro servidor. Eso cierra la reproducción, la reutilización de credenciales entre servicios y toda una clase de ataques de delegado confuso, y no dice nada sobre el operador en sí. La vinculación de audiencia dice dónde funciona el token, no qué hace la empresa del otro extremo con lo que sus herramientas recogen en su nombre. Eso lo responde su política de privacidad, no el protocolo.
Los scopes son donde se decide de verdad su exposición. La especificación empuja
a los servidores hacia el mínimo privilegio: scopes_supported debe ser el
conjunto mínimo necesario para la funcionalidad básica, y todo lo demás se pide
de forma incremental cuando se intenta por primera vez una operación
privilegiada. Los servidores que siguen esto piden poco de entrada; los que no,
muestran una única pantalla de consentimiento con todo dentro. Esa pantalla es
el último punto en el que la decisión es suya.
Hay dos superficies de revocación, y la mayoría solo usa la primera.
En el asistente. En Claude, los conectores personalizados están en Customize > Connectors, donde se añade uno pegando la URL del servidor; los usuarios de Free están limitados a uno. Esa misma página es donde se desconecta, y donde se activan o desactivan las herramientas individuales del servidor en lugar de aceptarlas todas. Anthropic expone su postura de confianza sin rodeos en su centro de ayuda: los conectores personalizados permiten conectar Claude a servicios arbitrarios que Anthropic no ha verificado. En ChatGPT, los servidores remotos llegan por el modo desarrollador —Settings → Security and login, en la web—, que acepta extremos SSE y streaming HTTP. La propia documentación de OpenAI lo llama potente pero peligroso, cita la inyección de prompts y las acciones de escritura destructivas entre los riesgos, y exige confirmación para las acciones de escritura por defecto.
En el servicio con el que autorizó. Esta es la que la gente se salta. Borrar el conector elimina la copia del token de su cliente; la concesión registrada en su cuenta de Google, GitHub, Atlassian o Notion es un objeto aparte con su propia vida, y un token de refresco asociado puede sobrevivir al conector durante mucho tiempo. La guía de Anthropic dice justo eso: revoque desconectando el conector en los ajustes de Claude o en los ajustes de seguridad del servicio de terceros. Haga las dos cosas, y localice esa página de aplicaciones conectadas antes de conectar.
El registro oficial de MCP en registry.modelcontextprotocol.io es el sitio
natural para encontrar servidores, y es fácil leer de más en lo que significa
una ficha. La carta de su grupo de trabajo es concreta. Publicación y confianza
cubren flujos de autenticación —GitHub OAuth, GitHub OIDC, verificación por DNS
y HTTP— más la propiedad de espacios de nombres, herramientas de moderación y
marcado por parte de la comunidad. Explícitamente fuera de alcance: clasificar
implementaciones de servidores MCP o elegir entre ellas en nombre de clientes o
usuarios finales, y alojar, distribuir o ejecutar código de servidor, porque el
registro es un catálogo de metadatos, no un registro de paquetes.
Así que un espacio de nombres verificado prueba que quien publicó la entrada controla la organización de GitHub o el dominio que aparece en su nombre. Es una señal real: dificulta el typosquatting y le da a alguien a quien pedir cuentas. No es una revisión de código, ni una auditoría de seguridad, ni un aval: identidad establecida, comportamiento todavía desconocido.
Un principio de la especificación merece viajar con usted en cada conexión: las descripciones del comportamiento de las herramientas, anotaciones incluidas, deben considerarse no fiables salvo que provengan de un servidor de confianza, y los anfitriones deben obtener consentimiento explícito del usuario antes de invocar cualquier herramienta. La descripción de una herramienta es texto que escribe una parte remota y lee su modelo: la definición de una entrada no fiable, y la razón de que «el servidor dijo que era de solo lectura» no sea un control de seguridad.
El precedente concreto es CVE-2025-6514, publicado el 9 de julio de 2025 contra
mcp-remote, el proxy que muchos clientes usaban para llegar a servidores
remotos. Con una puntuación de 9,6, permitía que un servidor malicioso lograra
inyección de comandos del sistema operativo en la máquina que se conectaba,
mediante un valor authorization_endpoint manipulado dentro del flujo OAuth;
afectaba a las versiones desde la 0.0.5 hasta la 0.1.16 y se corrigió en la
0.1.16. No hacía falta aprobar nada en un chat: conectarse era todo el ataque.
Todo lo que envía un servidor remoto son datos que su software analiza, y la
conexión misma forma parte de su superficie de ataque.
Todo lo anterior es el precio de alcanzar algo que vive de verdad en la nube de otra persona: su gestor de incidencias, su CRM, su calendario. Es un precio razonable para eso y un precio raro para archivos que ya están en su disco, y por eso Speak-Y incluye un servidor local en lugar de un extremo alojado.
Su servidor MCP es un proceso que su cliente arranca en su máquina. Leer no
necesita nada más en ejecución: los resultados de búsqueda, las transcripciones,
los resúmenes de reuniones y las tareas pendientes salen directamente de la
biblioteca que está en el mismo ordenador, sin token emitido y sin ningún relé
por medio. Los comandos que cambian algo —etiquetar una grabación, nombrar
interlocutores, compartir en un canal de equipo— pasan por la aplicación en
ejecución, se declaran al cliente como comandos que modifican datos para que
pregunte antes, y quedan registrados donde usted puede apagarlos. Añadir
--read-only a los argumentos del servidor significa que los comandos que
cambian cosas no se le publican a ese cliente en absoluto: una garantía más
fuerte que una descripción que promete buen comportamiento. La instalación es un
clic desde Configuración → Integraciones, gratis en todos los planes
incluido Free.
El intercambio va en las dos direcciones: un servidor local no puede servir a ChatGPT en una pestaña del navegador, y solo se ejecuta donde se ejecuta la aplicación. Si esa restricción importa, qué clientes pueden arrancar un servidor local es la comparativa que leer a continuación; y si la pregunta es qué debería poder cambiar un asistente una vez conectado, dónde está la línea en el acceso de escritura lo cubre. El resumen de MCP enumera lo que expone el servidor de Speak-Y.
Un servidor local es un programa en su propia máquina que el cliente arranca y con el que habla por la entrada y la salida estándar: lo que entrega es una línea de comandos y no se emite ningún token. Un servidor remoto es un extremo HTTPS que opera otra persona: lo que entrega es una credencial, normalmente un token de acceso OAuth 2.1, y los datos que tocan sus herramientas viajan a la infraestructura de ese operador.
Según la especificación de autorización de MCP, el token está ligado a un servidor y a un conjunto de scopes. Los clientes deben enviar un indicador de recurso RFC 8707 que nombre al servidor tanto en la petición de autorización como en la de token, y el servidor debe validar que los tokens se emitieron para él: no debe aceptar ni reenviar ningún otro. Eso impide reproducir el token en otro servicio. No dice nada sobre qué hace el operador con los datos que sus propias herramientas recogen en su nombre.
En dos sitios, y la mayoría de la gente solo usa el primero. Quitar el conector en su asistente borra la copia del token que tiene el cliente; la concesión OAuth registrada en el servicio con el que autorizó es un objeto aparte y normalmente sobrevive. La propia guía de Anthropic dice que se revocan los permisos desconectando el conector en los ajustes de Claude o en los ajustes de seguridad del servicio de terceros. Localice la página de aplicaciones conectadas del proveedor antes de conectar, no después.
No. El registro verifica la propiedad del espacio de nombres —un nombre io.github.* mediante autenticación de GitHub, un nombre basado en dominio mediante verificación por DNS o HTTP—, lo que prueba que quien publica controla ese nombre. Su carta deja explícitamente fuera de alcance clasificar implementaciones de servidores o elegir entre ellas, y afirma que el registro es un catálogo de metadatos, no un registro de paquetes: no aloja, distribuye ni ejecuta código de servidor.
Solo lo que alcancen los scopes que usted aprobó. El riesgo es que los scopes sean más amplios que la tarea: un token concedido para un buzón o un disco enteros está disponible para todas las herramientas que expone ese servidor, mientras viva la concesión. Lea la pantalla de consentimiento en lugar de la página de marketing, y use los controles por herramienta donde el cliente los tenga: los ajustes de conectores de Claude permiten activar y desactivar herramientas una a una, y el modo desarrollador de ChatGPT exige confirmación para las acciones de escritura por defecto.