Noticia8 min

Claude ya deja sumar connectors personalizados por remote MCP: donde si acelera y donde te puede abrir un hueco

Anthropic documentó el 2 de abril de 2026 los custom connectors por remote MCP para Claude, Cowork y Claude Desktop. La mejora útil no es solo conectar más apps: es mover tools internas y SaaS a una superficie compartida, con permisos heredados, OAuth y controles por conversación.

ClaudeAnthropicMCP
Superficie editorial con Claude, conectores remotos y flujos MCP gobernados por permisos

Por qué importa

Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.

Muchos equipos ya entendieron la promesa de MCP, pero siguen atascados en el mismo borde operativo: el servidor vive local, el acceso es frágil y la experiencia cambia según si trabajas en escritorio, web o móvil. La documentación que Anthropic publicó el 2 de abril de 2026 sobre custom connectors usando remote MCP empuja justo ese límite.

La señal útil no es “Claude puede conectar otra cosa”. La señal útil es otra: Claude, Cowork y Claude Desktop ya pueden hablar con servidores MCP remotos como una capa compartida, con autenticación OAuth, permisos heredados y activación por conversación.

Panel editorial con Claude, servicios remotos y una capa MCP conectada por OAuth

Qué cambia realmente

La guía oficial de Anthropic deja varias piezas importantes:

  • los custom connectors funcionan en Claude, Cowork y Claude Desktop;
  • la conexión al servidor remoto sale desde la infraestructura cloud de Anthropic, no desde tu laptop;
  • en Team y Enterprise, un owner agrega el conector y luego cada usuario autentica su propio acceso;
  • y en planes individuales, Pro y Max pueden sumar conectores personalizados desde la UI.

Eso cambia el tipo de integración que vale la pena construir. Ya no piensas solo en “cómo conecto mi laptop a una tool”. Piensas en cómo exponer una herramienta o sistema interno para que el mismo conector funcione en varias superficies de Claude sin rehacer el flujo por cliente.

Por qué esto sí importa a builders

1. Permisos heredados, no permisos inventados

Anthropic insiste en que Claude hereda los permisos del usuario en el sistema origen. Si la persona no puede ver un archivo, canal o registro en la app conectada, el conector tampoco debería poder verlo desde Claude.

Eso no resuelve toda la seguridad, pero sí baja uno de los riesgos más incómodos de los agentes: crear una capa paralela de acceso difícil de gobernar.

2. El cuello de botella ya no es solo contexto; también es activación

La guía de conectores de Anthropic añade otro matiz útil: cuando acumulas muchos conectores, puedes cambiar el modo de carga y usar On demand para no inflar cada conversación. Esa pieza parece menor, pero responde a un problema real: más herramientas no siempre significa mejor agente si cada charla arranca quemando contexto en tool catalogs innecesarios.

3. Hay una ruta para apps internas, no solo para partners públicos

La documentación sobre building custom connectors aclara que cualquier organización puede levantar su propio servidor MCP remoto, soportar SSE o Streamable HTTP, y usar autenticación sin credenciales embebidas en el cliente. Para equipos que ya tienen SaaS propio, panel interno o APIs privadas publicables con allowlists, eso abre una ruta bastante más sería que seguir copiando tokens y scripts locales.

Escena editorial con un catálogo de conectores, permisos granulados y activación por conversación

El riesgo real está en la red y en la aprobación, no en el demo

Anthropic deja una advertencia que conviene leer completa: cuando activas un remote connector, Claude puede leer, crear, modificar o borrar datos según lo que exponga ese servidor. Y como la conexión sale desde la nube de Anthropic, el servidor debe estar reachable desde internet y, en algunos casos, permitir las IPs públicas correctas.

Ahí es donde el tema deja de ser “feature de productividad” y se vuelve diseño de sistema:

  1. qué tools expones;
  2. qué scopes pides;
  3. qué acciones quedan bloqueadas;
  4. y cuáles siguen requiriendo aprobación explícita.

Anthropic también documenta que Research puede invocar tools automáticamente en conectores durante una investigación profunda. Si no deshabilitas herramientas de escritura antes, puedes abrir un vector innecesario de cambios externos.

Qué consultas sí tienen intención buena aquí

No hace falta inventar volumen para ver la demanda. Las búsquedas obvias ya apuntan a usuarios con necesidad concreta:

  • claude custom connectors
  • remote mcp claude
  • claude mcp oauth
  • claude connector permissions

Además, la propia superficie de Anthropic ya muestra señal de ecosistema: directorio de conectores, modos de carga, badges de interfaces interactivas y soporte en varias superficies del producto.

Mi lectura práctica

Si hoy usas Claude para trabajo interno, esta novedad vale más para tres casos que para cincuenta:

  1. apps de operación donde un agente solo debe leer o triagear;
  2. herramientas internas donde quieres OAuth y permisos por usuario, no llaves compartidas;
  3. sistemas con artefactos interactivos donde conviene ver dashboards o tableros dentro de la conversación.

No lo desplegaría primero sobre acciones destructivas ni sobre sistemas mal segmentados. Primero ordenaría instrucciones, permisos y rutas de aprobación con una base simple como el curso gratis. Y si estás comparando superficies de tooling, esta historia conversa bien con GitHub MCP y secret scanning antes del commit, porque ambas mueven herramientas reales hacia el loop del agente, pero con exigencias de gobernanza distintas.

La conclusión corta es esta: Anthropic no solo amplió la lista de conectores; empezó a convertir remote MCP en una capa operativa compartida entre clientes de Claude. Eso es útil, pero solo si tratas permisos y aprobaciones como producto, no como detalle.