Si quieres que un asistente consulte tu CRM, encuentre un pedido o prepare una tarea de seguimiento, el trabajo no termina al conectar el chat. Hay que definir qué datos puede leer, qué acciones puede solicitar y cómo comprobar que el resultado quedó guardado correctamente.
El desarrollo MCP a medida puede resolver esa conexión. Yo lo plantearía como un proyecto acotado de integración: una tarea de negocio, un grupo de usuarios y un resultado verificable. Esta guía sirve para preparar el alcance y evaluar una propuesta antes de contratar.
Cuándo merece la pena desarrollar un servidor MCP
MCP, Model Context Protocol, ofrece una interfaz común entre aplicaciones de IA y servidores que exponen capacidades. El cliente descubre las herramientas disponibles y puede solicitar su ejecución. La documentación oficial de arquitectura MCP explica esa separación. El modelo, el servidor MCP y tu CRM siguen siendo piezas distintas.
Empezaría revisando el conector que ya ofrece tu plataforma. Si cubre las operaciones, los permisos y la forma de desplegar que necesitas, quizá solo haga falta configurarlo. El desarrollo propio tiene sentido cuando faltan funciones, hay reglas internas o necesitas controlar la conexión con sistemas propios.
Si el objetivo es copiar un registro cuando cambia su estado, evaluaría primero una integración de APIs y sistemas empresariales. Si quieres decidir cuánto puede elegir el asistente, la comparación de agentes de IA y workflows aborda esa decisión. MCP no obliga a utilizar un agente autónomo.
Qué llevar a la primera conversación técnica
Antes de estimar, necesito entender el proceso y comprobar los accesos disponibles. Prepararía:
- Una tarea: quién la hace hoy, qué consulta y qué resultado debe obtener.
- Los sistemas: CRM, ERP u otra herramienta; documentación de sus interfaces y entorno de pruebas, si existe.
- Los usuarios: quién puede ver cada registro y quién autoriza cambios.
- Ejemplos anonimizados: un caso normal, uno incompleto y una excepción que hoy requiere ayuda.
- El cliente de IA: la aplicación desde la que se usará y sus requisitos de conexión. La compatibilidad se prueba con esa configuración concreta.
- Los límites: volumen esperado, tiempos aceptables, datos que no deben salir y responsable de revisar incidencias.
Si necesitas además un panel, un portal o nuevas reglas de negocio, lo separaría como desarrollo de software a medida. Así puedes distinguir el coste de construir la aplicación del coste de conectarla al asistente.
Ejemplo hipotético: consultar una oportunidad y preparar su seguimiento
Imagina que una persona de ventas pide: «Busca la oportunidad de Acme y prepara una tarea para el viernes». Es un ejemplo de diseño, no un proyecto realizado ni un resultado medido.
Primero limitaría la consulta a las oportunidades que esa persona puede ver. Si hay varias coincidencias, el asistente pide aclaración. Si no encuentra ninguna, lo indica; no completa los datos de memoria. La respuesta incluye una referencia al registro y el momento de consulta.
Para crear la tarea, mostraría oportunidad, responsable, fecha y contenido antes de confirmar. La aprobación debe corresponder a esos datos concretos. El servidor vuelve a comprobar los permisos al ejecutar y devuelve el identificador del registro creado. Si cambia el destinatario, la aprobación anterior deja de servir.
Definiría herramientas pequeñas como «consultar oportunidad» y «crear tarea aprobada». Evitaría una operación genérica que acepte instrucciones arbitrarias sobre la base de datos. Si una acción inicia trabajo en segundo plano, debe devolver un estado consultable; aceptar una petición no demuestra que el trabajo haya terminado.
Permisos, confirmaciones y recorrido de los datos
La identidad del usuario y sus permisos se comprueban en el servidor y en los sistemas conectados. Ocultar una herramienta en la interfaz no basta para impedir una llamada directa. Tampoco usaría una cuenta compartida con acceso total para resolver todos los casos.
La especificación de herramientas MCP recomienda intervención humana y confirmaciones para operaciones. En el proyecto concretaría dónde aparece esa confirmación, qué aprueba y cómo se comprueba al ejecutar. Una instrucción al modelo no sustituye estos controles.
También documentaría qué sale del CRM, qué recibe el asistente y qué queda en los registros de actividad. Pediría respuestas con solo los campos necesarios y un criterio explícito de retención. Desplegar el servidor dentro de la empresa no hace local al proveedor del modelo.
Para una conexión remota revisaría el mecanismo de identidad admitido por el cliente y el servidor frente a la especificación de autorización MCP. No daría por compatible cualquier combinación de aplicaciones solo porque ambas anuncien soporte MCP.
Pruebas para aceptar la primera entrega
Acordaría las pruebas antes de construir y las ejecutaría con usuarios de prueba con permisos distintos. Separaría dos comprobaciones: que cada herramienta cumple su contrato y que el asistente la utiliza correctamente dentro de la conversación.
| Situación | Resultado esperado | Evidencia |
|---|---|---|
| Consulta válida | Muestra solo los campos permitidos del registro correcto. | Resultado contrastado con el CRM y usuario utilizado. |
| Registro de otro equipo | Deniega el acceso, incluso al invocar directamente la herramienta. | Prueba negativa sin datos del otro equipo en la respuesta. |
| Coincidencia ambigua | Pide aclaración antes de preparar una acción. | Conversación y ausencia de una tarea creada por error. |
| Cambio después de aprobar | Exige una nueva aprobación para los datos modificados. | Contenido aprobado comparado con el ejecutado. |
| Timeout después de crear la tarea | Comprueba si se guardó antes de reintentar. | Un único registro o un estado pendiente de conciliación. |
| Texto que intenta cambiar las instrucciones | Mantiene los permisos y las operaciones permitidas. | Llamadas realizadas y resultado en el sistema de destino. |
Si el CRM no permite confirmar una escritura dudosa ni evitar duplicados con garantías, dejaría el caso pendiente de revisión. Un reintento ciego puede repetir la acción. El criterio de aceptación debe reflejar esa limitación.
Para tareas programadas, colas y recuperación, acordaría además el alcance de automatización e IA aplicada. Ese trabajo operativo debe estar contemplado en la propuesta.
Entregables y mantenimiento que deben quedar por escrito
Según el alcance, pediría código del servidor, catálogo de herramientas y parámetros, reglas de permisos, configuración sin secretos, pruebas de aceptación e instrucciones de despliegue. La documentación debe permitir a otra persona identificar un fallo, retirar un acceso y recuperar una ejecución pendiente.
Acordaría quién mantiene el servidor, quién gestiona las credenciales y quién aprueba cambios en las operaciones. El soporte debe concretar cobertura, canal de incidencias y condiciones de actualización. No presupongo atención continua ni mantenimiento ilimitado.
Una actualización del CRM, del cliente MCP o de sus requisitos de conexión puede exigir volver a probar. Mantendría registrada la combinación validada y un procedimiento para revertir cambios. Si el asistente toma decisiones incorrectas, también hay que revisar sus instrucciones y evaluación, aunque el servidor responda bien.
Qué determina el coste y el plazo
No daría un precio por «conectar el CRM» sin conocer las operaciones. Consultar un dato con acceso existente y modificar registros para varios equipos con aprobaciones tienen alcances diferentes.
Separaría análisis y construcción —interfaces, herramientas, permisos y pruebas— de operación —infraestructura, proveedores, supervisión e incidencias— y de cambios futuros. Las dependencias que más pueden mover el plazo son el acceso al entorno de pruebas, la calidad de las interfaces y la disponibilidad de quien valida las reglas del negocio.
Para comparar ofertas, pediría que cada proveedor explicase qué incluye, qué necesita de tu equipo y qué queda pendiente. La guía para comparar presupuestos de software desarrolla esa revisión. No hay una tarifa universal por herramienta MCP ni un ahorro garantizado por añadir IA.
Experiencia técnica que puedes revisar
Mi caso de control de Android mediante un servidor MCP documenta una implementación con herramientas concretas, accesibilidad y conexión privada. Permite revisar cómo separo el servidor de ejecución del modelo que solicita las acciones.
Ese caso acredita trabajo técnico en Android; no demuestra una integración con tu CRM ni resultados comerciales de otro sector. Para tu sistema, el primer paso sigue siendo validar sus interfaces y construir una prueba acotada.
Define una primera versión que puedas aceptar
Empezaría por una consulta útil y un grupo reducido de usuarios. Añadiría una escritura solo cuando estén definidos sus permisos, aprobación y recuperación. Si una integración existente resuelve el problema, la evaluamos antes de encargar desarrollo propio.
Soy David Rodríguez. Puedo ayudarte a revisar el proceso, definir la conexión y construir lo que falte. Cuéntame qué sistema y qué tarea quieres conectar; con esos datos podemos concretar una primera entrega y las pruebas para aceptarla.
Preguntas frecuentes
¿Necesito un servidor MCP para conectar IA con mi CRM?
Depende de cómo vaya a utilizarse. Una integración directa puede bastar para un flujo cerrado. MCP merece evaluarse cuando un asistente compatible necesita descubrir y utilizar operaciones de tus sistemas. Primero comprobaría si el conector existente cubre los datos y permisos necesarios.
¿Puedes conectar cualquier ERP o CRM?
La viabilidad depende de sus interfaces, licencia, permisos, límites y entorno de pruebas. Reviso esas condiciones antes de concretar el alcance. MCP no crea acceso a funciones que el sistema no permita utilizar.
¿Cuánto cuesta desarrollar un servidor MCP a medida?
El presupuesto depende de sistemas, operaciones, identidad, permisos, calidad de datos y pruebas. Separo análisis y construcción de infraestructura, consumo de proveedores y mantenimiento. El precio y el plazo se acuerdan después de revisar esas dependencias.
¿Puede alojarse en nuestra infraestructura?
Se estudia según conectividad, identidad y operación. Alojar allí el servidor MCP no significa que el modelo también sea local. Hay que documentar qué datos recibe cada componente y quién lo mantiene.