MCP en una empresa: casos reales donde sí cambia algo

La condición que decide

Antes de los casos, el filtro. Si no se cumple, todo lo demás es teoría interesante.

«Que ya se nota» es literal y se puede medir: cuánto tardó la última integración que pidió el negocio y cuántas hay pendientes en la cola.

Si la respuesta es «una semana y no hay cola», MCP no resuelve un problema que tengas. Si es «un mes y hay tres esperando», ahí está el caso.

Hay una segunda forma de medirlo que funciona incluso sin equipo técnico: contar cuántas veces en los últimos seis meses alguien del negocio pidió conectar la IA a algo y la respuesta fue «más adelante».

Ese número es el tamaño de la cola invisible. Y suele ser bastante mayor que la cola formal, porque la mayoría de las peticiones ni siquiera llegan a registrarse: se descartan en la conversación.

Caso 1 · El asistente interno que consulta cuatro sistemas

Empresa de servicios, unos 150 empleados. El caso más común de todos.

El equipo comercial preguntaba lo mismo todo el día: estado del contrato, saldo del cliente, última incidencia abierta, condiciones vigentes. Cada dato en un sistema distinto.

Antes de MCP eso eran cuatro integraciones a medida contra el modelo. Se hicieron dos, la tercera quedó en la cola y la cuarta nunca se pidió porque ya nadie creía que llegaría.

Con servidores MCP de sólo lectura, las cuatro se declararon una vez. El asistente consulta lo que necesite sin que nadie escriba una integración nueva cada vez, y el equipo técnico dejó de ser el cuello de botella del proyecto.

Un detalle de ese caso que conviene retener: el ahorro no vino de la IA sino de dejar de esperar.

La información ya estaba disponible antes. Lo que no estaba disponible era la capacidad de preguntarla sin abrir cuatro sistemas y sin pedirle a nadie que la buscara.

Es un patrón que se repite: en la mayoría de las empresas medianas el problema no es que falte el dato, es que cuesta demasiado llegar a él en el momento en que hace falta.

Caso 2 · Varios agentes contra las mismas herramientas

Aquí el ahorro no está en conectar, está en no repetir.

Cuando una empresa tiene tres agentes (uno de atención, uno de compras y uno interno de soporte) y los tres necesitan leer el estado de un pedido, sin MCP esa lectura se implementa tres veces.

Tres implementaciones significan tres formas de fallar, tres sitios donde actualizar cuando el sistema de pedidos cambie y tres versiones de la verdad cuando una se quede vieja.

Con un servidor, la lectura vive en un sitio. Cambia una vez y los tres agentes se enteran. Es el mismo argumento que sostiene el supervisor de agentes: a partir de varios agentes, lo compartido tiene que estar en un solo lugar.

Caso 3 · La empresa que quiere poder cambiar de modelo

Es el caso menos urgente y el más estratégico, y por eso casi nunca se decide a tiempo.

Una empresa que construyó todas sus integraciones contra un modelo concreto queda atada a ese proveedor por el costo de rehacerlas, no por la calidad del modelo.

Con MCP, la capa de herramientas es independiente del modelo. Cambiar de proveedor pasa a ser una prueba, no un proyecto.

El costo de esa atadura tiene nombre y está en qué es el vendor lock-in en IA.

Hay una versión más modesta de este caso que aplica a casi cualquier empresa: no querer cambiar de proveedor, sino poder usar dos a la vez.

Repartir tareas entre un modelo caro y uno barato es la palanca de costo más grande que existe en un sistema de IA, y sólo es viable si la capa de herramientas no está atada a ninguno de los dos.

Con integraciones a medida, usar dos modelos significa mantener dos juegos de conexiones. Con un estándar, significa cambiar a cuál se le manda cada tarea.

Dónde no cambia nada

Es la parte que casi ninguna presentación sobre MCP incluye, y es la que evita gastar en algo que no hacía falta.

• Una sola herramienta y un solo modelo. Una integración directa es más simple, más rápida y más fácil de depurar.
• Flujos fijos sin decisión. Si el proceso es siempre igual, un flujo en n8n o Make lo hace mejor y más barato.
• Calidad de las respuestas. MCP da acceso; no mejora el criterio del modelo ni la calidad del dato de detrás.
• Datos desordenados. Exponer por un estándar un dato sucio lo hace accesible, no correcto.

El último merece énfasis porque es el que más decepciona. MCP resuelve el problema de la conexión, y el problema de la mayoría de empresas está antes: en el estado del dato.

Hay un quinto sitio donde no cambia nada y conviene decirlo porque es el que más ilusiona: la calidad de las decisiones del negocio.

Un asistente con acceso a todos los sistemas responde más rápido y con más contexto. No decide mejor por eso, ni convierte en analista a quien no lo era.

Lo que sí hace es quitar la excusa de la falta de información, que a veces es justo lo que sostenía una decisión mala.

El orden en que conviene hacerlo

Se sostiene el mismo orden de siempre, y aquí se salta más que en otros territorios porque MCP suena a solución técnica limpia.

Qué cuesta de verdad

Tres partidas, y la primera es la menor de las tres.

• Construir el servidor. Días por sistema, cuando hay API. Es la parte visible y la barata.
• Decidir qué expone. Reuniones con quien es dueño de cada sistema. Suele tardar más que el código.
• Mantenerlo. Cuando el sistema de detrás cambia, el servidor cambia. Sin dueño, se degrada en silencio.

El desglose completo está en cuánto cuesta una integración de IA.

Una nota sobre la segunda partida, que es la que sorprende: decidir qué expone cada servidor obliga a una conversación que la empresa nunca tuvo.

Quién es dueño del dato de clientes, qué campos son sensibles, quién puede aprobar que un sistema los lea. Son preguntas de gobierno de datos disfrazadas de decisión técnica.

Es trabajo real y es trabajo que había que hacer igual. Contarlo como costo del proyecto de MCP es honesto y a la vez lo hace parecer más caro de lo que es.

Señales de que ya te tocaba

Cuatro frases que se escuchan en la empresa antes de que nadie mencione MCP. Cuando aparecen dos, la decisión ya está madura.

• «No hay tiempo para conectar eso ahora.»
• «Eso lo hizo Fulano y no está documentado.»
• «Si cambiamos de modelo hay que rehacerlo todo.»
• «Cada agente tiene su propia forma de leer lo mismo.»

Ninguna de las cuatro es un problema de IA. Todas son problemas de arquitectura de integración, que es exactamente el territorio que MCP ordena.

Hay una quinta frase que aparece más tarde y es la más cara de todas: «mejor lo hacemos a mano hasta que se estabilice».

Cuando el negocio empieza a resolver por su cuenta lo que la IA debía resolver, el proyecto ya perdió, aunque siga encendido y siga facturando.

Cómo se decide en una reunión de treinta minutos

Sin comité técnico y sin prueba de concepto. Tres preguntas y una tabla.

• ¿Cuántas herramientas distintas necesita tocar la IA en los próximos doce meses? Menos de tres, no toca.
• ¿Cuántos agentes o asistentes van a compartirlas? Uno solo, probablemente no toca.
• ¿Cuánto tardó la última integración y cuántas hay en cola? Es el número que convence a quien paga.

Con esas tres respuestas la decisión se toma sola, y no depende de que nadie en la sala entienda el protocolo.