Conectores MCP personalizados

Qué es un conector MCP y en qué se diferencia de un servidor MCP

En el ecosistema MCP hay dos piezas complementarias. El servidor MCP es el proceso que implementa el protocolo y expone las capacidades. El conector MCP es el cliente que usa el agente para comunicarse con ese servidor. Cuando hablamos de conectores MCP personalizados, hablamos de construir ese cliente con lógica propia adaptada a tu entorno, no de reutilizar uno genérico que puede no encajar. Para la parte servidora, te lo explicamos en detalle en desarrollo de servidores MCP.

• El servidor expone herramientas — define qué operaciones están disponibles, con qué nombre y qué parámetros. Es la parte que vive cerca del sistema externo.
• El conector invoca esas herramientas — es la lógica del lado del agente que decide cuándo llamar, cómo gestionar errores y qué hacer con la respuesta antes de pasársela al modelo.
• Un conector público asume el caso genérico — funciona bien cuando el sistema externo es un SaaS estándar con API bien documentada y sin particularidades de autenticación.
• Un conector a medida asume tu caso concreto — incorpora las reglas de negocio, la autenticación corporativa y los límites de uso de tu sistema, sin que el agente tenga que gestionarlos él mismo.
• La combinación óptima es servidor + conector diseñados juntos — cuando construimos ambas piezas, el contrato entre ellas es explícito y el resultado es predecible en producción.

Cuándo los conectores MCP públicos no son suficientes

Existen conectores MCP públicos para muchos servicios conocidos. Pero hay escenarios donde el conector público introduce más problemas de los que resuelve. Estos son los casos en que un mcp connector personalizado es la decisión técnica correcta.

Patrones comunes de conector MCP personalizado

En proyectos de agentes administrativos y de automatización con agentes autónomos hemos identificado los patrones de integración MCP a medida más habituales. Cada uno tiene sus particularidades de diseño.

• Conector a CRM — expone operaciones de lectura y escritura sobre contactos, oportunidades y actividad comercial. La clave es definir qué puede crear el agente y qué solo puede leer, para no contaminar datos.
• Conector a ERP — acceso a pedidos, inventario, facturas o albaranes. Los ERP suelen tener APIs propietarias con autenticación NTLM, tokens de sesión o integraciones SOAP que requieren un adaptador a medida.
• Conector a base de datos interna — cuando el sistema de origen es una base de datos SQL o NoSQL sin API REST por delante. El conector expone consultas predefinidas como herramientas, sin exponer el esquema completo.
• Conector a SaaS de nicho — plataformas verticales (gestión de obras, logística, sanidad) con APIs poco documentadas o con modelos de datos muy específicos del sector.
• Conector a sistema interno propio — aplicaciones desarrolladas a medida por el equipo de IT de la empresa. Aquí la ventaja es máxima: se diseñan conector y sistema en paralelo para garantizar compatibilidad.

Auth, permisos y trust boundary en conectores MCP

La seguridad de un conector MCP personalizado no es opcional. El conector actúa como proxy entre el agente y un sistema con datos reales, y ese rol exige que el trust boundary esté bien definido desde el primer día.

1. Definir el perímetro de operaciones — qué herramientas expone el conector y qué queda fuera. El agente solo ve lo que el conector le muestra. Si una operación no está en el esquema, no existe para él.
2. Gestionar credenciales fuera del agente — las claves de acceso al sistema externo viven en el conector, nunca en el contexto del agente. El modelo no tiene acceso a ellas ni puede filtrarlas en sus respuestas.
3. Validar entradas antes de ejecutar — el conector valida los parámetros que llegan del agente antes de llamar al sistema externo. Un agente puede ser manipulado para pedir operaciones anómalas; el conector es la última línea.
4. Registrar cada llamada con trazabilidad — cada operación queda registrada con timestamp, parámetros y respuesta. Imprescindible para auditorías, para depuración y para detectar comportamientos inesperados del agente.
5. Gestionar permisos por operación — no todas las herramientas del conector tienen el mismo nivel de riesgo. Las operaciones de escritura o borrado llevan controles adicionales, idealmente con confirmación explícita.

Pruebas, observabilidad y mantenimiento del conector

Un desarrollo de conectores MCP no termina cuando el conector funciona en local. Las pruebas, la observabilidad y el mantenimiento ante cambios en el sistema externo son parte del ciclo de vida. Aquí explicamos cómo lo abordamos.

• Pruebas de contrato — verificamos que el esquema del conector coincide con lo que el sistema externo devuelve realmente. Si el sistema cambia su API, las pruebas de contrato lo detectan antes de que el agente falle en producción.
• Pruebas de integración con el agente — simulamos conversaciones reales para verificar que el modelo elige la herramienta correcta en cada escenario y que el conector responde como se espera.
• Trazas de cada invocación — el conector emite trazas estructuradas (herramienta llamada, parámetros, tiempo de respuesta, errores) que permiten depurar problemas sin acceso al sistema externo.
• Alertas ante errores reiterados — si el sistema externo empieza a devolver errores de autenticación o de límite de uso, el conector lo notifica antes de que el agente acumule fallos.
• Versionado del esquema — cuando añadimos o modificamos herramientas, versionamos el esquema para que los agentes en producción no se vean afectados por cambios que aún no han validado.

Sin permanencia, sin letra pequeña. Hablemos sin compromiso si necesitas conectar un sistema que ningún conector público cubre bien.