Sesgo declarado, como siempre: enseño Claude Code a equipos de ingeniería, así que los cambios de gobernanza me vienen bien para tener de qué hablar en clase. Precisamente por eso esta pieza va de hechos verificables y de qué te toca revisar tras actualizar, no de vender que la herramienta "ahora es más corporativa" sin matices.
La novedad de esta semana no es una feature vistosa: es un cambio que solo nota quien administra Claude Code para un equipo. Pero si ese eres tú, cambia dónde viven los servidores MCP de tu gente y, sobre todo, cambia el comportamiento por defecto al actualizar. Conviene saberlo antes de que te sorprenda.
Qué ha cambiado
El 2 de septiembre, la
versión 2.1.259 de Claude Code
añade el ajuste gestionado managedMcpServers. Con él, tu organización puede
ofrecer servidores MCP a todos los usuarios desde la configuración
gestionada, sin que cada persona los añada a mano en su .mcp.json.
Dos precisiones del changelog que importan para no llevarse una idea equivocada:
- Misma forma de entrada que
.mcp.json. Si ya sabes escribir una entrada de servidor MCP, sabes escribir esto: el formato es el mismo, solo que lo publica la organización en lugar de cada usuario. - Solo servidores remotos. Las entradas que nombran un comando a ejecutar se omiten. Es decir, por esta vía puedes repartir servidores HTTP/SSE (los remotos), no servidores locales que arrancan un proceso en la máquina de cada persona. Si tu conector vive en un binario local, esto no es su canal.
El segundo cambio es el que puede pillarte desprevenido, y es de comportamiento
por defecto. Hasta ahora, allowedMcpServers —la lista blanca de servidores
permitidos— filtraba también lo que llegara por la vía gestionada. A partir de
esta versión, allowedMcpServers gobierna solo los servidores que añade el
usuario. ¿La consecuencia práctica? Un servidor gestionado que tu lista blanca
antes dejaba fuera ahora se carga al actualizar. Si quieres mantenerlo
desactivado, el mecanismo pasa a ser deniedMcpServers, la lista negra.
Y una nota práctica del mismo terreno, útil para no quedarte a ciegas: el
changelog también reforzó los
diagnósticos de la configuración gestionada, con avisos al arrancar y una línea
en /doctor y /status cuando esos ajustes no se cargan o no se pudieron pedir
(por ejemplo, en Bedrock, Vertex, proveedores de terceros o con un
ANTHROPIC_BASE_URL propio). Si administras esto, es tu primera parada para
confirmar que lo que publicaste le está llegando a la gente.
Lo que no voy a afirmar, porque no está en las fuentes: nada sobre qué conectores concretos deberías repartir, ni sobre planes futuros de esta función. Cuando haya fuente, lo contamos.
Qué te afecta, según quién seas
Si administras Claude Code para un equipo. Aquí está casi todo el trabajo, y hay una parte buena y una tarea que no puedes saltarte.
La parte buena: dejas de depender de que cada ingeniero configure a mano el mismo servidor MCP. Publicas los conectores remotos que tu equipo debe tener —un MCP interno de tu documentación, de tu tracker, de lo que sea— y aparecen para todos por igual. Menos deriva de configuración, menos "a mí no me funciona el conector". Repartir y gobernar ese acceso de forma centralizada es justo lo que trabajamos en el curso de MCP: conecta tus herramientas, que incluye una lección dedicada a gobernar el acceso.
La tarea que no puedes saltarte: si dependías de allowedMcpServers para
mantener algo fuera, revísalo tras actualizar. Con el nuevo comportamiento, un
servidor gestionado que tu lista blanca filtraba se cargará solo. Si eso no es lo
que quieres, muévelo a deniedMcpServers. No es un cambio hipotético: es el tipo
de detalle en settings.json que, mal entendido, abre acceso que creías cerrado
—exactamente el terreno del curso de
permisos, settings y seguridad.
Si usas Claude Code de forma interactiva y no administras nada. Poco que hacer, pero conviene entenderlo. Tras actualizar, es posible que veas nuevos servidores MCP que tú no añadiste: los ha publicado tu organización. No es un fallo ni una intrusión de un tercero al azar; es configuración gestionada por quien administra tu cuenta. Si algo te choca, pregunta a quien lleve la administración antes de desactivarlo por tu cuenta.
Si corres Claude Code en un proveedor de terceros o con base URL propia.
Piensa en Bedrock, Vertex, un gateway o un ANTHROPIC_BASE_URL personalizado.
Ahí es donde más fácil es que la configuración gestionada no llegue como esperas.
Antes de dar por hecho que tu reparto de MCP está en marcha, mira la línea de
/doctor o /status: te dirá si los ajustes gestionados se cargaron o por qué
no se pidieron.
Qué llevarte
managedMcpServers(desde la v2.1.259) deja que la organización ofrezca servidores MCP a todos los usuarios, con la misma forma que.mcp.jsony solo para servidores remotos HTTP/SSE: las entradas con comando a ejecutar se omiten.allowedMcpServerscambia de alcance: ahora gobierna solo los servidores que añade el usuario. Un servidor gestionado que tu lista blanca antes filtraba se carga por defecto al actualizar.- Para bloquear un servidor gestionado, usa
deniedMcpServers(la lista negra), no la blanca. - Si algo no llega,
/doctory/statusexplican por qué los ajustes gestionados no se cargaron o no se pidieron.
Preguntas rápidas
¿Puedo repartir a mi equipo un servidor MCP que arranca un comando local?
No por esta vía. managedMcpServers omite las entradas que nombran un comando a
ejecutar; sirve para servidores remotos HTTP/SSE. Los conectores locales por
comando siguen siendo cosa de cada máquina.
Tenía servidores fuera con allowedMcpServers. ¿Se me van a colar?
Solo los gestionados por tu organización, y solo porque la lista blanca ya no
los filtra. Tras actualizar, confirma tu configuración y mueve a
deniedMcpServers lo que quieras mantener apagado.
Soy un usuario normal y ha aparecido un servidor MCP nuevo. ¿Es seguro? Si lo publicó tu organización por configuración gestionada, es esperado. Ante la duda, verifícalo con quien administra tu cuenta antes de tocarlo.
¿Vais a centralizar los conectores MCP de vuestro equipo? Decidir qué servidores publicáis para todos, cuáles dejáis en manos de cada persona y cómo gobernáis ese acceso sin abrir puertas que creíais cerradas es justo el tipo de criterio que trabajamos en la formación en directo para equipos — sobre vuestro repo, vuestros conectores reales y vuestra configuración gestionada.