Cómo cambia la precedencia de la configuración MCP entre terminales e IDEs

Los conflictos de configuración de MCP no son un problema de MCP. Son un problema del cliente, y distinguir ambas cosas evita muchas sesiones de depuración mal encaminadas.

El protocolo indica a un cliente cómo comunicarse con un servidor después de iniciarlo. No indica a Claude Code, VS Code, Cursor, GitHub Copilot CLI o una extensión qué archivo JSON debe leer primero, si deben combinarse dos entradas con el mismo nombre ni si un complemento puede registrar un servidor después de cargar la configuración basada en archivos. Si supones que existe una jerarquía universal, puedes ejecutar el programa equivocado con un nombre de herramienta que parece correcto.

Es fácil pasar por alto ese fallo. La lista de herramientas muestra github, el agente llama a github.search_code y la llamada funciona. Mientras tanto, el agente de tu terminal puede haber iniciado un envoltorio del proyecto con una cuenta de prueba, y el IDE puede haber iniciado un comando global con tu cuenta personal. El nombre coincidía. El comando no.

Esta es la regla de trabajo que sigo: resuelve la configuración MCP por cliente, por proceso y por nombre de servidor. Trata el comando del servidor, sus argumentos, el entorno, el directorio de trabajo, la URL de transporte y el origen de las credenciales como una sola definición de lanzamiento. No deduzcas ninguno de esos datos a partir de la etiqueta que aparece en el panel del agente.

MCP no tiene una escala de precedencia compartida

MCP estandariza los mensajes y las capacidades entre clientes y servidores. No establece una estructura de archivos portable ni decide cuál gana cuando varias fuentes de configuración discrepan. Un cliente puede usar archivos JSON, una base de datos de ajustes, una API de extensiones, una política empresarial administrada, una opción de línea de comandos o todas esas fuentes.

Por eso, cuatro expresiones que a menudo se tratan como equivalentes no lo son:

• Una configuración de usuario es una definición global específica del cliente para una cuenta o perfil.
• Una configuración de proyecto es una definición asociada a un repositorio o espacio de trabajo.
• Una configuración de complemento es un servidor registrado o proporcionado por una extensión o complemento instalado.
• Un ajuste del editor pertenece al editor y puede controlar o no la configuración de los servidores MCP.

La última diferencia causa más problemas de los que debería. VS Code tiene una jerarquía consolidada para sus ajustes generales: los ajustes del espacio de trabajo sustituyen a los del usuario en los casos habituales, y los valores de objeto pueden combinarse, mientras que los valores primitivos y los arrays sustituyen a los anteriores. Ese comportamiento corresponde a settings.json. No demuestra que .vscode/mcp.json siga las mismas reglas de combinación y colisión. VS Code documenta la configuración MCP como un archivo independiente, mcp.json, situado en un espacio de trabajo o en un perfil de usuario. No traslades las suposiciones del motor de ajustes a otro formato.

La consecuencia práctica es clara: «gana el espacio de trabajo» no es una respuesta útil hasta añadir el nombre del cliente, la versión del cliente, el formato de configuración y el conflicto exacto. Un archivo del espacio de trabajo puede añadir un servidor, ocultar otro global con el mismo nombre, coexistir con él o no cargarse porque el espacio de trabajo no es de confianza. Son resultados distintos, y un diagrama genérico de precedencia los oculta.

El nombre del servidor es la unidad del conflicto

La mayoría de los clientes organiza la configuración MCP como un mapa: a la izquierda aparece el nombre del servidor y a la derecha, una definición de lanzamiento. La clave del mapa suele ser lo que el cliente utiliza para decidir si dos declaraciones entran en conflicto.

Considera estos dos archivos:

// user configuration
{
  "mcpServers": {
    "catalog": {
      "command": "node",
      "args": ["/Users/dev/bin/catalog-live.js"],
      "env": { "CATALOG_TARGET": "production" }
    }
  }
}

// project configuration
{
  "mcpServers": {
    "catalog": {
      "command": "node",
      "args": ["./tools/catalog-fixture.js"],
      "env": { "CATALOG_TARGET": "fixture" }
    }
  }
}

Una persona ve dos servicios de catálogo. Un cliente ve dos valores en la clave catalog. Si selecciona una definición, normalmente selecciona la definición completa. No esperes que combine el comando global con los argumentos del proyecto, ni el comando del proyecto con el entorno global. Algunos sistemas de ajustes combinan objetos, pero un cliente MCP no tiene la obligación de hacerlo.

Por eso las sustituciones parciales son un mal diseño. Un proyecto que necesita otro endpoint debe declarar por completo el comando que pretende usar. Un usuario que quiera una herramienta personal debe utilizar otro nombre. Una sustitución a medias dificulta saber si el cliente reemplazó todo el objeto del servidor o combinó campos de una forma que no has probado.

Mientras diagnosticas la configuración, usa nombres que hagan visible la propiedad y la finalidad:

{
  "mcpServers": {
    "catalog-user-live": { "command": "node", "args": ["/Users/dev/bin/catalog-live.js"] },
    "catalog-repo-fixture": { "command": "node", "args": ["./tools/catalog-fixture.js"] }
  }
}

Esos nombres no son elegantes. Son honestos. Cuando el equipo tenga una única definición canónica, puedes renombrarla a catalog. Antes de eso, un nombre duplicado y conciso convierte cada llamada de herramienta en un ejercicio de adivinación.

También debes separar un nombre duplicado de una capacidad duplicada. Dos servidores pueden exponer una herramienta llamada search y seguir siendo distintos porque sus nombres de servidor son diferentes. El agente puede confundirse por descripciones parecidas, pero la configuración del cliente no tiene por qué estar ante una colisión de nombres. Resuelve primero el proceso del cliente y después mejora las descripciones y los nombres de las herramientas.

Claude Code tiene un orden de ámbitos MCP explícito

Claude Code es el caso más sencillo porque su documentación MCP indica el orden para las entradas de servidor con el mismo nombre. El ámbito local tiene prioridad sobre el de proyecto, y el de proyecto sobre el de usuario. La terminología actual importa: local es el ámbito privado y específico del proyecto; project escribe un .mcp.json compartido; user se aplica a todos los proyectos. Anthropic utilizaba antes otros nombres para algunos ámbitos, por lo que las notas antiguas y el historial del shell pueden inducir a error.

En la práctica, si los tres ámbitos contienen catalog, Claude Code inicia la definición local. Después viene la definición compartida de .mcp.json, y la definición de usuario queda como alternativa.

# private to this checkout and this user
claude mcp add catalog --scope local -- node ./tools/catalog-fixture.js

# shared with the repository
claude mcp add catalog --scope project -- node ./tools/catalog-service.js

# available in all repositories for this user
claude mcp add catalog --scope user -- node ~/bin/catalog-personal.js

El resultado esperado de la inspección es un único servidor efectivo llamado catalog, procedente del ámbito local cuando existen los tres. Ejecuta el comando del cliente que lista u obtiene el servidor después de cada cambio, en lugar de confiar en el archivo que acabas de editar:

claude mcp get catalog

La salida debería identificar el servidor y mostrar los detalles del transporte o del comando configurado. Compara el comando, los argumentos y el entorno reales con la definición que esperabas. Si el comando no es el que has editado, deja de cambiar archivos e identifica qué ámbito sigue siendo propietario del nombre.

No confundas esta regla de ámbitos MCP con la precedencia general de ajustes de Claude Code. Anthropic documenta políticas empresariales administradas, argumentos de línea de comandos, ajustes locales del proyecto, ajustes compartidos del proyecto y ajustes del usuario para la configuración general de Claude Code. Un ajuste administrado puede limitar el comportamiento que rodea el uso de MCP sin actuar como una segunda definición de servidor MCP. Las dos jerarquías responden a preguntas distintas.

Hay otra trampa en el ámbito del proyecto. Claude Code solicita aprobación antes de utilizar un servidor proporcionado por .mcp.json. Esa aprobación indica si el cliente puede utilizar el servidor del proyecto. No cambia la prioridad de una configuración con el mismo nombre. No interpretes una solicitud de aprobación como prueba de que ganó el comando compartido.

VS Code mantiene los archivos MCP separados de los ajustes normales

VS Code ofrece dos ubicaciones documentadas para la configuración de servidores MCP: .vscode/mcp.json en el espacio de trabajo y un mcp.json del perfil de usuario, que se abre mediante el comando MCP: Open User Configuration. El archivo del espacio de trabajo está pensado para compartirse mediante el control de versiones, mientras que el archivo del perfil sigue al usuario y puede variar según el perfil de VS Code.

Esta estructura invita a una expectativa razonable: la configuración de un repositorio debería definir sus herramientas, y el perfil debería definir las herramientas personales. Pero por sí sola no documenta una regla completa para resolver nombres duplicados. En particular, la referencia pública de configuración MCP describe el esquema y las ubicaciones, pero no afirma que la precedencia normal de los ajustes de VS Code se aplique campo por campo a las entradas de servers.

Aquí es donde los usuarios experimentados toman un atajo equivocado. Saben que los ajustes del espacio de trabajo sustituyen a los del usuario. Colocan el mismo nombre de servidor MCP en la configuración del perfil y del espacio de trabajo, cambian el comando del proyecto y concluyen que se ejecutará el comando del espacio de trabajo. Puede ocurrir. Pero una conclusión basada en un subsistema de ajustes cercano sigue siendo una conclusión, no un contrato documentado.

Trata una colisión de nombres en VS Code como un requisito de prueba. Haz que los dos candidatos sean claramente distintos y usa un comando inocuo que demuestre cuál se inició:

{
  "servers": {
    "precedence-probe": {
      "type": "stdio",
      "command": "sh",
      "args": ["-lc", "printf 'workspace probe started\\n' >&2; exec node ./tools/probe-server.js"]
    }
  }
}

Pon otra marca en la configuración del perfil de usuario:

{
  "servers": {
    "precedence-probe": {
      "type": "stdio",
      "command": "sh",
      "args": ["-lc", "printf 'profile probe started\\n' >&2; exec node $HOME/bin/probe-server.js"]
    }
  }
}

Después reinicia por completo el servidor desde la interfaz de gestión MCP de VS Code o reinicia el editor si la interfaz no deja claro el estado del proceso. Revisa la salida o los registros del servidor MCP para localizar la marca. No hagas la prueba contra una base de datos real ni contra un entorno de producción. Una comprobación de precedencia debe demostrar una ruta de lanzamiento, no modificar datos.

La misma precaución se aplica a la activación. VS Code documenta que el estado de activación y desactivación se guarda por separado de la configuración del servidor, así que un archivo compartido puede estar presente aunque el servidor no se inicie en un espacio de trabajo. «Puedo verlo en mcp.json» y «este cliente lo ha iniciado» son hechos distintos.

Los espacios de trabajo con varias raíces añaden otra fuente de certezas equivocadas. VS Code tiene ámbitos de espacio de trabajo y de carpeta para los ajustes generales, pero un archivo MCP vinculado a un espacio de trabajo no es automáticamente una declaración de servidor por carpeta. Si una herramienta necesita un comando relativo al repositorio, especifica en la prueba la raíz del espacio de trabajo y el directorio de trabajo esperado. Un comando que funciona en una raíz puede fallar o llegar silenciosamente a otro archivo cuando el editor abre varias carpetas.

Cursor añade rutas de configuración de proyecto, globales y de extensiones

Cursor documenta la configuración MCP específica del proyecto en .cursor/mcp.json y la configuración global en ~/.cursor/mcp.json. También ofrece una API de extensiones que puede registrar servidores MCP mediante programación. Son tres fuentes distintas: el archivo del repositorio, el archivo del usuario y el código que se ejecuta dentro de una extensión.

Las dos primeras son fáciles de entender cuando los nombres son únicos. Coloca el servicio de desarrollo compartido del repositorio en .cursor/mcp.json. Coloca una utilidad personal, como un servicio local de búsqueda de notas, en el archivo global. La CLI de Cursor indica que detecta y respeta mcp.json, lo que hace útil la configuración compartida cuando el IDE y su agente de terminal se ejecutan realmente en el mismo entorno.

El caso difícil es un nombre duplicado en las tres fuentes. La documentación pública de MCP de Cursor indica dónde colocar los archivos de proyecto y globales, pero no publica un contrato completo para todas las colisiones entre la configuración global, la del proyecto y un servidor de extensión registrado dinámicamente. No inventes una regla a partir de una publicación de foro, una nota de versión antigua o un comportamiento observado en un único equipo.

El diseño seguro consiste en evitar la colisión. Si una extensión proporciona issue-tracker, no pongas otra entrada issue-tracker en .cursor/mcp.json esperando que el comando del repositorio la sustituya. Da al servidor propiedad del repositorio otro nombre, como issue-tracker-fixture, y deja claro en las instrucciones del agente o en las descripciones de las herramientas cuándo debe utilizarlo.

Esto es especialmente importante en equipos que usan un complemento por comodidad y un archivo por reproducibilidad. El complemento puede encargarse de la instalación, OAuth, las actualizaciones o el registro siguiendo su propio calendario. Un archivo del repositorio queda visible en la revisión de código. Son modelos de propiedad distintos. Decide cuál es el propietario del servidor antes de intentar que ambos coincidan por casualidad.

Los límites del entorno hacen que los conflictos de Cursor parezcan más extraños de lo que son. Un editor de escritorio puede ejecutarse en un sistema operativo, mientras que su terminal, espacio de trabajo remoto o contenedor de desarrollo puede hacerlo en otro. Un archivo global del directorio personal puede existir en un entorno y no en otro. El comando de un archivo del proyecto puede resolver node, python o un ejecutable relativo mediante valores distintos de PATH. Antes de hablar de precedencia, anota dónde se ejecuta el proceso del cliente y dónde se ejecuta el proceso del servidor.

Para cada candidato, registra esta información de lanzamiento:

client: Cursor desktop / Cursor CLI
client environment: local macOS / WSL / remote host / container
config source: ~/.cursor/mcp.json / .cursor/mcp.json / extension registration
server name: issue-tracker
command: node ./tools/issue-mcp.js
working directory: repository root
credential source: OAuth / local environment / external gateway

Un registro de cinco minutos como este vale más que una tarde cambiando opciones en distintos paneles.

GitHub Copilot CLI documenta la resolución de MCP de proyecto sobre usuario

GitHub Copilot CLI es más explícito que muchos clientes. Su documentación indica que la configuración MCP del proyecto en .mcp.json o .github/mcp.json tiene prioridad sobre una definición con el mismo nombre en ~/.copilot/mcp-config.json. Es una regla clara de proyecto sobre usuario para los nombres de servidores MCP en la CLI.

Úsala como una regla específica del cliente, no como una verdad general sobre GitHub Copilot en todos los editores. Copilot CLI tiene su propio directorio de configuración, ajustes del repositorio, ajustes locales, compatibilidad con complementos, almacenamiento de permisos y proceso de línea de comandos. Una sesión de Copilot en VS Code es otra superficie de cliente, con su propia documentación de configuración MCP y su propio ciclo de vida.

Una configuración limpia de Copilot CLI puede tener este aspecto:

// ~/.copilot/mcp-config.json
{
  "mcpServers": {
    "docs": {
      "command": "node",
      "args": ["/Users/dev/bin/company-docs-mcp.js"]
    },
    "catalog": {
      "command": "node",
      "args": ["/Users/dev/bin/catalog-live.js"]
    }
  }
}

// .mcp.json in the repository
{
  "mcpServers": {
    "catalog": {
      "command": "node",
      "args": ["./tools/catalog-fixture.js"]
    }
  }
}

En ese repositorio, Copilot CLI debería usar la definición de proyecto para catalog y conservar la definición de usuario para docs, porque ninguna entrada del proyecto entra en conflicto con docs. Ese es el modelo útil: sustituye solo el nombre que pertenece al proyecto y deja intactas las utilidades personales que no están relacionadas.

Los complementos complican el panorama porque pueden aportar su propio comportamiento del agente y su propio ciclo de vida de servidores MCP. La documentación de configuración de GitHub describe los complementos habilitados para un repositorio como elementos vinculados al repositorio y señala que el cliente detiene el servidor MCP de un complemento cuando el repositorio deja de habilitarlo. Esto indica que el servidor del complemento está vinculado a la activación del complemento, no simplemente copiado en el archivo MCP del usuario.

Si un servidor proporcionado por un complemento y otro proporcionado por un archivo usan el mismo nombre, no adivines qué comando gana. Inspecciona el estado visible de los servidores de la CLI, el estado del complemento y la salida de inicio. Si la documentación de la versión instalada no indica cómo se resuelve el conflicto, cambia el nombre de una definición o elimina uno de los productores. El consejo popular de «sobrescribir el servidor del complemento desde el repositorio» resulta atractivo porque es corto. Es incorrecto cuando el complemento controla el registro después de cargar los archivos o aporta estado adicional del ciclo de vida.

El editor y su terminal son clientes MCP separados

Una terminal dentro de un IDE parece formar parte del editor. Sigue siendo un proceso de shell. Cuando ejecutas claude, copilot o cursor-agent, ese comando puede leer sus propios archivos, directorio actual, entorno, directorio personal y variables de sustitución de configuración. La extensión de chat del editor es otro proceso, con otra implementación de cliente.

Esta es la causa del informe habitual: «El servidor MCP funciona en el IDE, pero no en la terminal». Hay varias explicaciones normales:

• El editor abrió un archivo del espacio de trabajo, mientras que la terminal empezó en un subdirectorio o en otra copia del repositorio.
• El editor usa un host remoto o un contenedor, mientras que el comando de la terminal se ejecuta localmente.
• La terminal heredó un PATH, HOME, ajuste de proxy o variable de credenciales propios del shell.
• El editor activó un servidor de complemento que la CLI nunca carga.
• La CLI encontró un servidor de proyecto con el mismo nombre y sustituyó la entrada del usuario.

No empieces copiando todos los archivos de configuración a todas las ubicaciones. Eso aumenta la superficie de colisión y oculta la primera causa.

En su lugar, ejecuta un cliente cada vez y recopila pruebas. En los clientes de terminal, usa el comando integrado que lista u obtiene los servidores MCP. En los clientes del editor, usa la vista de gestión de servidores MCP y su salida o sus registros. Registra el nombre del servidor, el comando, los argumentos, la ubicación del proceso y la hora de inicio. Si la terminal y el editor muestran el mismo nombre pero comandos distintos, has encontrado un problema de resolución de configuración. Si muestran el mismo comando pero se comportan de manera distinta, investiga el directorio de trabajo, las credenciales, el acceso a la red o el propio servidor.

Una prueba útil consiste en sustituir temporalmente el comando del servidor por un envoltorio que escriba una marca inequívoca en la salida de error antes de ejecutar el servidor real. Mantén la prueba en modo de solo lectura y elimina el envoltorio al terminar.

#!/bin/sh
printf '%s client=%s cwd=%s\n' \
  "MCP probe started" \
  "${MCP_CLIENT_LABEL:-unknown}" \
  "$PWD" >&2
exec node "$(dirname "$0")/real-server.js"

No imprimas tokens, encabezados, valores de credenciales, volcados completos del entorno ni cargas útiles de solicitudes. Los registros suelen sobrevivir a la sesión de terminal, y una prueba de precedencia no debería provocar una filtración de secretos mientras intenta explicar otra.

El registro de un complemento no es una sustitución de archivo de configuración

Un complemento produce configuración de servidor, no es simplemente otra carpeta donde casualmente hay JSON. Puede registrar un servidor de forma dinámica, gestionar la autenticación, elegir una versión, reaccionar a cambios del espacio de trabajo o detener el servidor cuando se desactiva.

Esto hace que dos recomendaciones habituales sean arriesgadas.

La primera es «pon el mismo nombre en el archivo del proyecto para sustituir el servidor del complemento». Solo funciona cuando el cliente documenta que los archivos se cargan después de los complementos y que una colisión de nombres sustituye el registro del complemento. Sin ese contrato, el duplicado puede provocar un error, una sustitución oculta, dos herramientas con descripciones parecidas o un comportamiento que cambie después de una actualización.

La segunda es «desactiva el servidor en la interfaz y el proyecto estará limpio». El estado de activación puede vivir fuera del archivo compartido. VS Code separa explícitamente el estado de activación y desactivación de la configuración MCP. Un compañero puede clonar el repositorio, recibir el mismo archivo y seguir teniendo un conjunto diferente de servidores activos.

Usa uno de estos modelos de propiedad:

1. Servidor propiedad del archivo: el repositorio confirma la definición del servidor. Todos usan el archivo y ningún complemento registra el mismo servicio.
2. Servidor propiedad del complemento: el complemento gestiona el registro y la autenticación. El repositorio no declara un duplicado.
3. Roles de servidor separados: un complemento es propietario de tracker-live y un archivo del proyecto de tracker-fixture. Los nombres, las descripciones y los permisos dejan claros los destinos.

La tercera opción suele ser la menos llamativa y la más segura. Los equipos a menudo necesitan al mismo tiempo un servicio personal en vivo y un recurso de prueba del repositorio. Fingir que son un único servidor porque ambos hablan con un sistema de incidencias solo aumenta la probabilidad de una llamada accidental al entorno real.

Una forma repetible de demostrar qué comando gana

Puedes demostrar la resolución de la configuración sin depender del comportamiento del agente. El método siguiente usa un servidor stdio o un envoltorio inocuo y funciona tanto si el cliente inicia un comando local como si apunta a un servicio remoto.

Crea una prueba con dos fuentes

Elige un nombre de servidor, como precedence-probe. Defínelo exactamente en las dos fuentes que quieras comparar. Haz que cada candidato produzca una marca distinta antes de iniciar el mismo servidor de prueba inofensivo.

Para un servidor basado en comandos, distingue cada parte relevante:

{
  "mcpServers": {
    "precedence-probe": {
      "command": "sh",
      "args": ["-lc", "printf 'SOURCE=PROJECT CWD=%s\\n' \"$PWD\" >&2; exec node ./tools/probe.js"],
      "env": { "MCP_PROBE_SOURCE": "project" }
    }
  }
}

El candidato del usuario debería imprimir SOURCE=USER y apuntar a otro archivo conocido. No dependas solo de una variable de entorno si el cliente la oculta, filtra o inicia un proceso antiguo. Incluye también una marca visible en la ruta del comando y en la salida.

Reinicia el servidor, no solo el chat

Los servidores MCP suelen ser procesos hijos de larga duración. Editar JSON mientras el servidor sigue activo no demuestra nada sobre la siguiente solicitud. Usa el control del cliente que detiene y reinicia el servidor. Si no está claro, cierra por completo el cliente correspondiente y vuelve a abrir el espacio de trabajo.

Después revisa primero los registros del cliente. Las pruebas esperadas tienen este aspecto:

MCP probe started
SOURCE=PROJECT
CWD=/path/to/repository

Si no aparece ninguna marca, el cliente puede haber rechazado la configuración antes de iniciar el proceso, haber usado un transporte remoto o haber mantenido activo un servidor antiguo. El resultado es útil. Reduce la pregunta de «¿qué configuración gana?» a «¿se cargó esta configuración y este cliente inició un proceso?».

Cambia un límite cada vez

Ejecuta la prueba en el cliente de terminal y después en el cliente del IDE. Cambia el directorio de trabajo solo después de obtener una referencia inicial. Desactiva el complemento solo después de medir el comportamiento basado únicamente en archivos. Prueba las fuentes de usuario y de proyecto antes de añadir sustituciones locales o ajustes administrados.

Mantén una tabla breve en la incidencia del repositorio o en las notas del equipo:

La tabla debe informar del comportamiento observado, no del esperado. Un equipo puede actuar sobre el comportamiento observado. Un diagrama copiado de otro cliente es solo una hipótesis.

Mantén las credenciales fuera de la disputa de precedencia

Un conflicto de comandos es un problema de ejecución. Un conflicto de credenciales es un problema de seguridad. No resuelvas el primero repartiendo secretos entre la configuración del proyecto, el complemento, el usuario y el editor hasta que algo funcione.

La configuración confirmada del proyecto debería incluir normalmente el comando del servidor, información de endpoint no sensible e instrucciones para obtener credenciales. No debería incluir un token bearer de larga duración en env, una ruta a una clave privada SSH que falte a todos los compañeros ni un valor de encabezado personalizado que conceda acceso a producción. Un archivo del proyecto se convierte en una invitación de ejecución para cada copia y cada agente al que el cliente permita utilizarlo.

Si un servidor necesita un secreto, elige un límite de credenciales adecuado al trabajo:

• OAuth es apropiado cuando el servidor y el cliente lo admiten y el usuario debe conceder el acceso de forma interactiva.
• Un gestor local de secretos o una inyección de entorno son apropiados para una definición de servidor personal.
• Un recurso de prueba del repositorio debería usar credenciales que no sean de producción y tengan permisos limitados.
• Una pasarela de acciones es apropiada cuando el agente debe solicitar una acción sin recibir nunca la credencial de API o SSH subyacente.

Aquí es donde un comando de servidor puede parecer inofensivo y seguir siendo peligroso. npx some-mcp-server puede resolver una versión instalada distinta en cada equipo. node ./tools/server.js puede heredar AWS_PROFILE, GH_TOKEN o un proxy corporativo del proceso principal. La declaración del proyecto puede revisarse, mientras que el origen real de las credenciales permanece oculto.

Cuando los agentes necesitan acceso HTTP o SSH, Sallyport puede mantener la credencial de API o SSH en su bóveda cifrada mientras el agente se conecta mediante el asistente sp mcp y recibe solo los resultados de las acciones. Esto no decide qué configuración del cliente gana, pero evita que el comando ganador entregue también credenciales sin procesar al agente.

No trates la precedencia de configuración como un sistema de permisos. Una definición del proyecto puede seleccionar un comando, pero no demuestra que ese comando deba actuar sin revisión. Mantén la aprobación, el almacenamiento de credenciales y las pruebas de auditoría como controles independientes.

Haz evidente el comando canónico

Los equipos necesitan una respuesta clara a una pregunta sencilla: ¿qué comando debe iniciar el agente de este repositorio para este servicio? Si la respuesta está escondida entre archivos del usuario, comportamiento de complementos, fragmentos del README y ajustes del editor, la configuración ya es demasiado laxa.

Escribe la definición compartida canónica en un único lugar. Dale un nombre de servidor estable. Indica qué clientes la admiten y qué fuente es su propietaria. Pon las variantes personales bajo nombres distintos. Si un complemento debe ser propietario del servicio, documenta que el complemento es la fuente canónica y no distribuyas una definición de archivo que compita con él.

Después conserva en el repositorio un pequeño comando o una prueba de verificación. Los cambios de configuración merecen pruebas, igual que los scripts de despliegue. Un servidor que inicia el comando equivocado puede leer archivos incorrectos, llamar al endpoint equivocado o heredar credenciales erróneas antes de que el agente diga una palabra.

El resultado útil no es una tabla universal de precedencia. Es una configuración en la que cada cliente tiene una ruta de lanzamiento observable, cada nombre de servidor tiene un único propietario y nadie necesita adivinar qué comando ejecutará su agente.