La comparativa corta cabe en una frase: una API la usa quien programa; un MCP (Model Context Protocol) la usa un asistente de IA, y normalmente envuelve la API que ya tienes. Hasta ahí, todo el mundo de acuerdo. Lo interesante empieza después, cuando dejas de leer sobre el tema y conectas un asistente a una herramienta real con datos de clientes dentro. Nosotros acabamos de hacerlo con nuestro propio sistema de tickets, y las decisiones difíciles no fueron las de la tabla comparativa: fueron las de permisos, identidad y qué puede salir por la puerta sin que nadie lo mire.
La diferencia real: quién está al otro lado
Una API y un MCP exponen las mismas capacidades, pero a públicos distintos, y eso cambia el diseño:
- Una API asume un programa que sabe de antemano qué endpoints existen
- Un MCP describe sus herramientas para que el modelo las descubra solo
- Por eso el nombre y la descripción de cada herramienta son parte de la lógica, no documentación
- El MCP no sustituye la API: se apoya en ella
💡 Si ya tienes una API bien hecha, montar el MCP encima es trabajo de días, no de meses. La API es la parte difícil, y ya la tienes.
Leer y escribir no son el mismo permiso
La decisión que más cambió nuestro diseño. Una herramienta que lee tickets y redacta un borrador es inofensiva. Una que envía manda un correo a un cliente real:
- Permiso de lectura: listar la bandeja, abrir un hilo, generar un borrador
- Permiso de escritura: responder, cambiar estados, asignar
- Son dos permisos separados, y se conceden por separado
- Con solo lectura, el asistente analiza y propone, pero no puede enviar nada
💡 Empieza en solo lectura. Ya es útil desde el primer día, y te deja ver cómo se comporta el asistente antes de darle la capacidad de hablar con tus clientes.
Un agente actúa en nombre de alguien
Si el asistente escribe en un ticket, ese mensaje lleva una firma. Dejarlo en un identificador anónimo rompe la trazabilidad justo cuando hace falta:
- Cada credencial de agente está ligada a la persona que la creó
- Lo que el asistente publica queda atribuido a esa persona
- Se sigue distinguiendo que vino por el asistente, para poder auditarlo
- Si alguien pregunta "¿quién respondió esto?", hay respuesta
💡 Una credencial por persona y por equipo, no una compartida. Cuando haya que revocar, querrás revocar una sola cosa.
El permiso se comprueba al usarlo, no al crearlo
Un permiso que solo vive dentro de una credencial sobrevive a que se lo quiten a su dueño. Por eso no basta con comprobar al emitirla:
- El rol se verifica en cada petición, contra el sistema de usuarios
- Si a esa persona se le retira el acceso, la credencial deja de servir al instante
- No hay que esperar a que caduque ni acordarse de ir a revocarla
- Vale igual para una baja, un cambio de equipo o un portátil perdido
💡 Prueba a quitarte a ti mismo el permiso y vuelve a lanzar una petición. Si sigue funcionando, el control está en el sitio equivocado.
Lo que no debe salir solo
Un asistente puede redactar una respuesta excelente. Eso no significa que deba enviarla sin que nadie la lea:
- El borrador se genera y se queda esperando: no se envía
- Al publicar hay que declarar si es una nota interna o una respuesta visible
- No hay valor por defecto: obligar a elegir evita el accidente
- Una persona revisa antes de que el mensaje salga hacia un cliente
💡 El campo que decide si el cliente lo ve nunca debería tener un valor por defecto. Es el tipo de descuido que solo se descubre cuando ya ha pasado.
Lo que el asistente puede hacer, no lo que promete hacer
Al montar esto acabamos quitando una funcionalidad que parecía buena idea: mostrar la lista de servidores externos con los que hablaría un proceso. No se puede sostener:
- Un destino puede construirse durante la ejecución, no estar escrito antes
- Una herramienta con nombre inocente puede acabar enviando a cualquier sitio
- Una lista incompleta es peor que ninguna: da confianza falsa
- Mejor declarar capacidades: "esto puede enviar datos fuera", "esto ejecuta código"
💡 Cuando una señal de seguridad no se puede garantizar siempre, quitarla es más honesto que enseñarla con letra pequeña.
Antes de conectar un asistente a tu herramienta
Preguntas frecuentes
¿MCP sustituye a las APIs?
No. Un MCP se apoya en la API que ya tienes y la presenta de forma que un modelo pueda descubrirla y usarla. Si tu API está bien hecha, el MCP es una capa encima; si no lo está, el MCP no lo arregla.
¿Cuándo me compensa montar un MCP?
Cuando quieras que un asistente trabaje sobre tu herramienta de forma conversacional, en vez de programar cada integración. Si solo necesitas conectar dos sistemas entre sí y nadie va a conversar con ellos, una automatización normal es más simple y más predecible.
¿Es seguro darle a una IA acceso a datos de clientes?
Depende de lo que pueda hacer con ellos, no de que sea una IA. Las mismas preguntas de siempre: qué permisos tiene, en nombre de quién actúa, quién revisa lo que sale y con qué rapidez se puede cortar el acceso. Si esas cuatro tienen respuesta, es tan seguro como cualquier integración.
¿Puede el asistente responder solo a los clientes?
Técnicamente sí; nosotros hemos decidido que no. El asistente redacta y propone, una persona revisa y envía. La calidad del borrador no es el problema: el problema es que un error sale por la puerta sin que nadie lo vea.
¿Qué pasa si alguien deja la empresa?
Su credencial deja de funcionar en la siguiente petición, porque el permiso se comprueba contra el sistema de usuarios cada vez y no se guarda dentro de la credencial. No hay que acordarse de ir a revocar nada.
La comparativa entre MCP y API se resuelve rápido: son capas distintas para públicos distintos, y la segunda sigue siendo el cimiento. Lo que no se resuelve leyendo es el resto. Conectar un asistente a una herramienta con datos de clientes dentro es, sobre todo, un ejercicio de permisos: qué puede leer, qué puede escribir, en nombre de quién, y qué no sale nunca sin que una persona lo mire. Nosotros lo hemos montado sobre nuestro propio soporte, y las decisiones que más nos costaron no aparecían en ninguna tabla comparativa. Si vas a hacerlo, empieza en solo lectura: sigue siendo útil desde el primer día y te ahorra descubrir las cosas por las malas.