Conecta cualquier servidor MCP a Claude Code y Claude Desktop

Conectar un servidor MCP tanto a Claude Code como a Claude Desktop implica algo más que copiar la misma configuración en dos sitios.

En Claude Code, los servidores MCP se pueden configurar en distintos ámbitos, como los niveles local, project y user. Una vez colocada la configuración, es posible que el servidor todavía tenga que aprobarse antes de que puedas verificar que está realmente conectado. Claude Desktop lo gestiona de otra manera: los servidores MCP locales se pueden cargar a través de Extensions o de la configuración de Developer, mientras que los servidores remotos siguen un flujo de conexión aparte. Por eso, un servidor MCP que funciona en Claude Code no pasa a estar disponible en Claude Desktop de forma automática.

Otra fuente habitual de confusión es tratar “added”, “approved”, “connected” y “able to complete the task” como si fueran lo mismo. Representan etapas distintas.

“Added” solo significa que la configuración se ha registrado. “Pending approval” significa que el servidor sigue esperando autorización. “Connected” significa que la conexión MCP se ha establecido correctamente. Pero incluso cuando todos esos pasos funcionan como se espera, el agente puede seguir sin poder completar la tarea.

Esto es especialmente relevante para los servidores MCP que interactúan con el navegador. El servidor puede estar conectado y sus herramientas disponibles, pero la tarea puede fallar igualmente si el navegador no tiene la sesión iniciada necesaria, las cookies u otro estado de ejecución. En ese punto, la propia configuración de MCP puede ser ya correcta: lo que falta es el entorno del navegador.

Esta es la capa que ego (lite) está diseñado para gestionar. El agente puede seguir trabajando dentro de un entorno de navegador real que ya tiene el estado que la tarea requiere, incluidas las sesiones iniciadas existentes y el estado actual de la página. En lugar de cambiar una y otra vez una configuración de MCP que ya funciona, el agente puede pasar a la propia tarea del navegador.

Así que, al solucionar problemas de MCP, no te quedes en si el servidor muestra “Connected”. Identifica qué capa está fallando en realidad: ¿Se ha añadido el servidor? ¿Se ha aprobado? ¿Está conectado? ¿Y tiene el navegador el estado necesario para completar la tarea?

Qué estás conectando en realidad

Hay dos partes a cada lado del cable. El cliente es la aplicación de Claude: descubre herramientas, decide cuándo llamarlas y te muestra el resultado. El servidor es un proceso aparte o un endpoint remoto que posee la capacidad real: una base de datos, un sistema de tickets, un sistema de archivos, un navegador. MCP en sí es solo el contrato entre ambos, y por eso conviene mantener el vocabulario claro: nada en esta guía depende del servidor que hayas elegido, porque la mecánica de configuración es idéntica en todos los casos.

El protocolo en sí se define en modelcontextprotocol.io, la referencia para transportes, capacidades y el contrato cliente-servidor.

La consecuencia práctica es que los problemas de conexión casi nunca están en el servidor. Están en los tres puntos donde el cliente decide si lo ejecuta o no: qué archivo de configuración leyó, si puede alcanzar el endpoint y si lo aprobaste. Si mantienes esos tres puntos separados en la cabeza, depurar se convierte en una lista corta de comprobaciones y no en una tarde perdida.

Elige un ámbito antes de escribir nada

Claude Code te da tres sitios donde poner la definición de un servidor, y elegir el incorrecto es la causa más habitual de que un servidor "desaparezca": se conectó bien, pero en un directorio en el que ya no estás.

El ámbito local es el predeterminado. Recurre a él mientras pruebas un servidor del que no estás seguro y para cualquier cosa que lleve una credencial que no quieres en un repositorio. Elige project cuando el servidor pertenezca de verdad al código, por ejemplo un servidor de gestión de proyectos para el repositorio de un equipo, porque esa entrada viaja con el clon y cada compañero recibe una única solicitud de aprobación. Elige user para servidores que tienen que ver contigo y no con el código: un servidor de notas personales, un endpoint de laboratorio doméstico, eso a lo que recurres en todas las sesiones.

Hay un comportamiento que conviene interiorizar antes de crear duplicados: cuando el mismo nombre de servidor existe en más de un sitio, Claude Code se conecta una sola vez y toma la entrada completa de la fuente con mayor precedencia. La precedencia va primero local, luego project, después user y por último los servidores que aportan los plugins. Los campos no se combinan, así que una entrada de proyecto a la que le falta una clave opcional no queda parcheada en silencio por una entrada de usuario más completa; lo que se ejecuta es la entrada de proyecto completa.

Añade un servidor a Claude Code

Claude Code incluye un solo comando con varias formas según cómo se entregue el servidor. Un servidor remoto por HTTP es el caso más sencillo, porque no hay nada que ejecutar en local:

# Remote server over HTTP (the recommended transport)
claude mcp add --transport http <name> <url>

# With an auth header
claude mcp add --transport http secure-api https://api.example.com/mcp \
  --header "Authorization: Bearer your-token"

Un servidor local se ejecuta como proceso hijo, así que el comando y sus argumentos van después de un doble guion. Ese separador no es cosmético: todo lo que va después se pasa al servidor sin tocarlo, y eso es lo que impide que Claude Code intente interpretar los flags del propio servidor como suyos.

# Local server as a child process
claude mcp add [options] <name> -- <command> [args...]

# Real shape, with an environment variable
claude mcp add --env API_KEY=your-key --transport stdio airtable \
  -- npx -y airtable-mcp-server

Cuando el proveedor del servidor te da un fragmento JSON (algo habitual, porque el mismo fragmento sirve en cualquier cliente MCP), puedes pegarlo directamente en lugar de transcribirlo a flags. Pasa el objeto que hay dentro de mcpServers, no el envoltorio que lo rodea:

claude mcp add-json weather-api \
  '{"type":"http","url":"https://api.weather.com/mcp","headers":{"Authorization":"Bearer token"}}'

Vale la pena conocer dos flags aunque ninguno sea obligatorio. El flag de ámbito decide dónde queda la entrada, y se puede escribir de las dos formas:

claude mcp add --transport http stripe --scope local https://mcp.stripe.com
claude mcp add --transport http notion -s user https://mcp.notion.com/mcp

Dos variantes del mismo comando suelen confundirse. El comando add simple reescribe la entrada con ese nombre por completo, que es lo que quieres cuando un proveedor cambió su URL. La forma add-json toma el mismo objeto y lo mantiene como una sola entrada, que es lo que quieres cuando el servidor necesita varios campos a la vez:

Comprueba que se ha conectado de verdad

Un add correcto imprime una línea Added y esa línea significa solo una cosa: la configuración se escribió en disco. No dice nada sobre si el servidor se ejecuta. El comando que responde a la pregunta real es el comando list, que informa de un estado por servidor: connected, needing authentication o failed to connect:

La referencia a nivel de comando de cada subcomando es la documentación oficial de MCP de Claude Code, que merece la pena leer junto con este recorrido.

Para el servidor de navegador que esta guía usa como ejemplo, los pasos de instalación y registro están en la guía de configuración de Playwright MCP para Claude Code y Cursor.

claude mcp list          # health status for every configured server
claude mcp get notion    # detail for one server, including its Issue line

Cuando un estado muestra un fallo, el comando list añade el detalle del fallo a esa línea, y la vista de un solo servidor lo repite en una línea Issue junto con el estado HTTP o el código de error y el texto que haya devuelto el servidor. Toma ese detalle como la prueba principal en lugar de releer tu JSON. El texto que parece una credencial se oculta, y la URL expandida nunca se incluye a propósito, porque una URL puede llevar un secreto en su cadena de consulta.

No todos los estados vienen de un intento de conexión. Algunos informan de una decisión de configuración, y Claude Code los imprime sin llegar a contactar con el servidor. Un servidor con ámbito de proyecto que viene del archivo compartido se queda en pending approval hasta que ejecutas el cliente interactivo una vez y aceptas el aviso. Un servidor marcado como disabled en tus ajustes aparece como disabled para este proyecto y se puede volver a habilitar desde el panel de la aplicación. Un servidor rechazado por una entrada de ajustes aparece en la vista de un solo servidor pero no en la lista, lo cual es una distinción útil cuando un servidor que sabes que añadiste parece haberse esfumado.

Por encima de eso hay una barrera de confianza. Los comandos list y detail leen las aprobaciones del archivo de proyecto compartido solo desde ajustes que no están comprometidos en el repositorio, hasta que confías en el espacio de trabajo ejecutando el cliente ahí y aceptando el diálogo de confianza. Un repositorio clonado no puede aprobar sus propios servidores: una lista de servidores preaprobados incluida en los ajustes del proyecto se ignora en una carpeta que no es de confianza, y el servidor se queda en pending approval en lugar de comprobarse. Es una defensa deliberada, no un error, y es la razón de que un clon reciente parezca haber perdido tus servidores.

Los servidores WebSocket son la excepción a todo lo anterior: no aparecen en la salida de list en absoluto. Usa la vista de un solo servidor o el panel de la aplicación para comprobarlos.

Añade el mismo servidor a Claude Desktop

Desktop es otro mundo, y el cambio que despista a la gente es que su ruta documentada principal para servidores locales ya no es un archivo JSON. El flujo actual son las extensiones empaquetadas: abre Settings, ve a Extensions, explora el directorio o usa la sección Developer para instalar un .mcpb empaquetado, y luego rellena los ajustes que pida el paquete. Los valores obligatorios, como las claves de API, se recogen a través de la interfaz, y los campos sensibles quedan cifrados por el almacén seguro del sistema operativo. Las extensiones del directorio se actualizan solas; una distribuida de forma privada necesita una reinstalación manual cuando aparece una versión nueva.

Si un proveedor todavía te da un fragmento JSON y ningún paquete, la ruta manual no ha desaparecido: se ha movido. Abre el menú de la aplicación de escritorio, elige Settings, luego Developer, y usa el control de edición de la configuración, que crea el archivo si no existe y lo abre si ya existe. En macOS ese archivo está en ~/Library/Application Support/Claude/claude_desktop_config.json; en Windows está en %APPDATA%\Claude\claude_desktop_config.jsonLa mayoría de los servidores locales se lanzan con npx y necesitan Node.js instalado, y la aplicación solo lee el archivo al arrancar, así que cerrarla por completo y volver a abrirla forma parte del procedimiento y no es un paso supersticioso de más.

Los servidores remotos toman la tercera ruta, y es remota de verdad en el sentido de red: Claude llega al servidor desde la nube de Anthropic y no desde tu dispositivo. Eso tiene dos consecuencias que la gente descubre a las malas. Tu servidor tiene que ser accesible públicamente, así que un servicio atado a una red privada necesita que sus rangos estén en la lista de permitidos antes de poder conectarse. Y el conector se autentica con OAuth en lugar de con una ruta de archivo, y por eso un conector remoto puede funcionar en una máquina que nunca ha ejecutado el código del servidor.

Para cuentas individuales la ruta es la pantalla de conectores dentro de los ajustes de personalización, donde añades un conector personalizado y pegas la URL del servidor; una sección avanzada acepta un ID de cliente y un secreto de OAuth cuando el servidor no admite el registro dinámico de clientes. En un plan de organización, un propietario añade el conector a nivel de organización y luego los miembros se autentican individualmente. Se aplican los límites del plan (una cuenta gratuita está limitada a un único conector personalizado), y un conector aparece como personalizado a menos que su dominio coincida con una ficha del directorio.

La estructura de configuración que ambas aplicaciones comparten

Por debajo de las distintas superficies, la entrada es el mismo objeto. Un servidor remoto es un type, una URL y headers opcionales. Un servidor local es un comando, sus argumentos y un bloque de entorno opcional. Esta es la estructura con la que comparar cuando la documentación de un proveedor y tu archivo no coincidan:

{
  "mcpServers": {
    "remote-example": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    },
    "local-example": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/mcp-server"],
      "env": { "CACHE_DIR": "/tmp" }
    }
  }
}

Tres detalles de ese objeto causan la mayoría de los fallos evitables. Una entrada stdio con una ruta relativa en su comando se rompe en cuanto cambia el directorio de trabajo, así que usa rutas absolutas. Una ruta de Windows dentro de una cadena JSON necesita barras invertidas escapadas, o el archivo se interpreta como una cadena mal formada. Y una entrada remota sin ningún type se lee como servidor local, lo que produce un error confuso sobre un comando que falta en vez de decir algo sobre la URL.

Donde las dos aplicaciones se separan es en los nombres. Claude Code exige nombres formados por letras, números, guiones y guiones bajos, mientras que una clave de configuración de escritorio es más permisiva. Mantener el nombre idéntico en ambos sitios es la forma más barata de no liarte con tus propias notas.

Credenciales, variables y la trampa de ${VAR}

Codificar un token directamente en un archivo de configuración es la vía por la que los secretos acaban en un repositorio, así que las configuraciones de MCP admiten expansión de variables. La sintaxis tiene dos formas, una simple y otra con valor predeterminado, y la expansión cubre el comando, sus argumentos, el bloque de entorno, la URL y los headers:

{
  "mcpServers": {
    "api-server": {
      "type": "http",
      "url": "${API_BASE_URL:-https://api.example.com}/mcp",
      "headers": { "Authorization": "Bearer ${API_KEY}" }
    }
  }
}

El comportamiento cuando falta una variable es donde está la trampa, y es distinto según las dos categorías de variable. Una variable normal que no está definida y no tiene valor predeterminado no rompe la configuración: el servidor sigue cargándose, la lista de estado informa de una advertencia de variable faltante y el texto sin expandir se usa como valor literal. Esa advertencia es la pista, y es fácil pasarla por alto al hacer scroll.

Un conjunto con nombre de variables de credenciales se comporta de otra manera en la URL y los headers de un servidor remoto: se leen como vacías, sin ninguna advertencia, y un valor predeterminado asociado a ellas se ignora. La diferencia práctica es que la primera categoría falla a voces y la segunda falla en silencio: obtienes una petición no autenticada y el error que devuelva el otro extremo, sin nada en tu propia configuración que señale la causa. Si un servidor remoto informa de errores de autenticación mientras tus variables parecen estar bien definidas, comprueba el entorno real que heredó el proceso del cliente antes de revisar el propio token.

Hay una segunda regla, más concreta, para las entradas con ámbito de proyecto: referenciar la variable del directorio del proyecto en un comando o un argumento exige que le proporciones un valor predeterminado, porque no hay garantía de que el valor esté definido en el momento en que se lee la entrada. Las configuraciones que aportan los plugins la sustituyen directamente y no están sujetas al mismo requisito.

Cómo solucionar los problemas de conexión

Trabaja de fuera hacia dentro, en cuatro pasos: arranca el servidor, el transporte llega hasta él, el handshake se completa y el agente puede hacer de verdad el trabajo. Cada paso tiene un síntoma distinto, y el orden importa porque un fallo en el primero hace que todo lo que venga después parezca roto también.

Para el mismo diagnóstico aplicado específicamente a un servidor de navegador, Chrome DevTools MCP: configuración, sesiones existentes y soluciones repasa en orden los fallos de conexión y de perfil.

El servidor no arranca. Saca el comando y los argumentos de la configuración y ejecútalos en una terminal normal. Si fallan ahí, ningún ajuste del cliente lo va a arreglar: falta un entorno de ejecución, el nombre del paquete está mal o la ruta no existe. Este paso por sí solo resuelve buena parte de los informes sobre servidores locales, porque quita el archivo de configuración de la ecuación por completo.

El transporte no llega hasta el servidor. En un endpoint remoto, confirma que la URL es la ruta de MCP y no la raíz del servicio, y luego confirma que la credencial llega de verdad. Un 401 o un 403 del otro extremo es la señal más clara de toda la guía: el cliente llegó al servidor y el servidor rechazó a quien llamaba, lo que te lleva directamente a la sección de credenciales de arriba. Un connection refused o un fallo de resolución apuntan en la otra dirección, a la dirección o a un firewall.

El handshake se queda atascado o la lista de herramientas vuelve vacía. Un servidor que arranca pero nunca termina su primer intercambio suele ir lento, no estar roto. El cliente aplica un tiempo de espera de arranque a los servidores MCP, y una descarga en frío de npx para un paquete grande puede superarlo en la primera ejecución; ejecuta el servidor a mano una vez para que el paquete quede en caché y vuelve a intentarlo. Un servidor que conecta pero no expone ninguna herramienta es un problema distinto: arrancó bien y no anunció nada, lo que normalmente significa que necesita que le pases configuración a través de su bloque de entorno antes de poder ofrecer algo.

Se está descartando la salida. Hay un techo para cuánto puede aportar un solo resultado de herramienta a la conversación, y aparece una advertencia cuando la salida supera un umbral inferior. Un servidor cuyas respuestas se están recortando parecerá que funciona, pero sin la última parte de cada respuesta. Si un servidor es legítimamente verboso, sube el techo a propósito en lugar de concluir que el servidor no es fiable.

Un servidor de proyecto no conecta para nadie más. Esta es la barrera de confianza, no una entrada rota. El clon reciente de un compañero tiene que confiar en el espacio de trabajo y aprobar la entrada compartida una vez. Si no lo ha hecho, el servidor aparece como pending approval y la comprobación de estado nunca se ejecuta.

Cuando el servidor MCP necesita una sesión de navegador

Los servidores orientados al navegador son donde el cuarto paso se convierte en toda la historia. El servidor conecta, el transporte está bien, el handshake se completa, la lista de herramientas está poblada y la tarea aun así falla, porque el navegador que controla no tiene una sesión iniciada o el perfil que lanzó no es el que guarda tus cookies. Todos los síntomas en el cliente parecen sanos.

El servidor de ese ejemplo es microsoft/playwright-mcp, que es donde se siguen su lista de herramientas y sus problemas conocidos.

Para ver el conjunto más amplio de formas en que un agente puede llegar a un navegador dentro de Claude Code, consulta la comparativa de las cinco rutas de navegador.

Esta es la capa que ocupa ego (lite) y merece la pena ser preciso sobre qué producto es. No es un servidor MCP y no registra ninguna herramienta: es un navegador construido para que un agente trabaje dentro del navegador que ya tiene tus inicios de sesión, en lugar de en un perfil de automatización limpio al lado. La conexión entre el agente y ese navegador es un asunto distinto de la conexión entre el agente y sus herramientas. Claude Code o Claude Desktop mantiene la conexión MCP; ego-browser mantiene la sesión del navegador, y las sesiones viven en Spaces aislados para que el trabajo de un agente no choque con la ventana que estás usando. Cuando un servidor MCP de navegador devuelve una página vacía, una redirección de inicio de sesión o un elemento que no ve, el arreglo está casi siempre en ese lado de la frontera y no en la configuración que acabas de verificar.

Si todavía no has elegido un servidor de navegador, la comparativa de servidores MCP de navegador para Claude Code clasifica las opciones actuales según a qué puede llegar cada una y cuánto cuesta.

MCP, una herramienta de línea de comandos, una extensión de navegador y un navegador construido para agentes son cuatro capas distintas, y elegir entre ellas es una cuestión de quién es dueño de la ventana y no de cuál es más capaz. La prueba práctica es lo que necesita la tarea: un servidor que pueda alcanzar tus sesiones autenticadas, con un coste en tokens que puedas asumir, en una ventana que siga siendo tuya. Ese último paso es donde se toma la decisión, diga lo que diga la línea de estado.

Los compromisos de cada capa se desglosan en MCP vs CLI y dónde encajan las extensiones de navegador.

Qué estás concediendo cuando se conecta un servidor

Conectar un servidor es conceder una capacidad, y la tabla de ámbitos de antes también sirve como tabla de permisos. Un servidor con ámbito user está presente en todos los proyectos que abras, incluidos los que no escribiste tú. Un servidor con ámbito project está presente para todo el que clone el repositorio. Ninguno de los dos hechos es malo por sí solo, pero los dos se olvidan con facilidad un mes después de configurarlos.

Tres hábitos cubren la mayor parte del riesgo. Mantén las credenciales en variables de entorno y no en un archivo comprometido, y recuerda que una entrada con ámbito de proyecto viaja. Instala en ámbito local los servidores que aún estás evaluando, donde eliminarlos es un solo comando y nada llega al control de versiones. Y cuando el acceso de un servidor sea más amplio que su trabajo, por ejemplo un servidor de sistema de archivos apuntando a tu directorio personal para editar una sola carpeta o un servidor de navegador que puede llegar a todas tus cuentas con sesión iniciada, reduce el permiso antes de reducir la configuración.

Si quieres ver qué exponen otros servidores antes de conceder nada, el repositorio oficial de servidores MCP enumera las implementaciones de referencia y sus ámbitos.

Las definiciones de servidores también consumen contexto en cuanto conectan; cómo reducir el uso de tokens de MCP cubre esa cara del equilibrio.

La interfaz de usuario refuerza la diferencia: un conector remoto se ejecuta desde la nube del proveedor con el alcance de red que eso implica, mientras que un servidor local se ejecuta con los permisos de tu cuenta en tu máquina. Por eso la pregunta de seguridad para un conector remoto es quién más puede alcanzar ese endpoint, y la pregunta de seguridad para un servidor local es a qué puede acceder ese proceso.

Preguntas frecuentes

¿Puede un mismo servidor MCP usarse en Claude Code y en Claude Desktop?

Sí, siempre que configures cada aplicación por separado. Los dos clientes leen configuraciones distintas, así que añadir un servidor en Claude Code no afecta a Desktop, e instalar una extensión de escritorio no hace que el servidor esté disponible en Claude Code. Un servidor remoto es el más barato de mantener en ambos sitios, porque la misma URL sirve para los dos y solo cambia la entrada que lo rodea.

¿Dónde se ejecuta realmente el servidor?

Un servidor local es un proceso en tu máquina, iniciado por el cliente, con los permisos de tu cuenta de usuario. A un servidor remoto por HTTP o por el transporte SSE obsoleto se llega por la red, y dentro de Claude Desktop ese acceso viene de la nube de Claude y no de tu dispositivo. Esta es la distinción más útil cuando un servidor funciona en una aplicación y en la otra no.

¿Por qué el servidor aparece como pending approval?

Viene de un archivo de proyecto compartido que todavía no has aprobado en este espacio de trabajo. El estado pending approval es una decisión de configuración y no una conexión fallida, así que el cliente nunca contactó con el servidor para generarlo. Ejecuta el cliente interactivo una vez en ese directorio, acepta el diálogo de confianza del espacio de trabajo y aprueba el servidor; el estado cambia en la siguiente comprobación.

¿SSE sigue siendo utilizable o debería migrar?

El transporte SSE está obsoleto pero todavía se acepta. Cuando un servidor ofrece ambos endpoints, el transporte HTTP es la mejor opción, y en versiones recientes el cliente prefiere HTTP y recurre a SSE cuando el servidor no lo acepta. Migrar es un cambio de una línea en el type y la URL de la entrada, no una reinstalación.

¿Por qué el servidor funciona en mi terminal pero no en la aplicación?

Casi siempre porque la aplicación no hereda el entorno que tenía tu shell. Tu terminal tiene un PATH y un conjunto de variables exportadas que una aplicación con interfaz gráfica nunca ve, así que un servidor lanzado con un nombre de comando a secas se resuelve en un sitio y no en el otro. Usa rutas absolutas para el comando y pasa las variables que el servidor necesita a través de su bloque de entorno en lugar de depender del shell que lo rodea.

¿Cómo elimino un servidor de forma limpia?

En Claude Code, elimínalo por su nombre, lo que quita la entrada del ámbito que la contenga. En Desktop, desinstala la extensión o borra la entrada y reinicia, ya que el archivo manual solo se lee al arrancar. Eliminarlo de un sitio nunca lo elimina del otro, algo que conviene recordar cuando un servidor que borraste en una aplicación sigue apareciendo en la otra.

¿Puedo hacer commit de un .mcp.json de proyecto en el repositorio?

Sí, y esa es precisamente la finalidad del ámbito de proyecto, pero el archivo no lleva credenciales y cada compañero tiene que aprobarlo una vez. Mantén los valores secretos en variables de entorno a las que haga referencia la entrada, y trata el archivo comprometido como una lista de nombres de servidor y comandos, no como una configuración en la que un clon pueda confiar por sí sola.

¿Por qué Claude Desktop no ve un servidor que añadí en Claude Code?

Porque las dos aplicaciones leen configuraciones distintas. Un servidor registrado con la CLI vive en los archivos de ámbito propios de Claude Code, y Desktop solo lee sus extensiones y su configuración de Developer. Añade el servidor otra vez en el lado de Desktop, o apunta ambos a la misma URL remota para tener una sola definición que mantener.

¿Tengo que reiniciar la aplicación después de editar un archivo de configuración?

Claude Code lee y escribe sus definiciones de servidor a través de sus propios comandos, así que no hace falta reiniciar a mano. Claude Desktop lee su archivo de configuración manual al arrancar, así que una edición hecha fuera de la aplicación solo surte efecto tras reiniciarla.

¿Qué significa needs authentication en la lista de servidores?

El servidor arrancó y respondió, pero quien lo llamaba no estaba autorizado. En un servidor remoto esto suele significar que la credencial de la URL o de los headers no llegó, o llegó vacía tras la expansión de variables. Abre la configuración del servidor y confirma los valores expandidos antes de cambiar cualquier otra cosa.