Todo el mundo habla de MCP: lecciones de desarrolladores en Miro, Atlassian y más allá

A continuación se presenta una transcripción editada de la conversación. Las citas han sido ligeramente condensadas para mayor claridad. 

Las APIs han existido siempre. ¿Qué desbloquea realmente MCP que las APIs no podían?

Gunjan: En el pasado, tenías que entender la API de cada herramienta, gastar tus ya escasos recursos de desarrollo para construir esas diferentes integraciones, y si un requisito cambiaba —digamos, en lugar de solo leer algo tenías que escribir algo— tenías que volver y hacer el cambio y esperar seis semanas. Ese era el ciclo: era lento y era costoso.

Con MCP, los propios proveedores ofrecen servidores y tú simplemente expresas tu intención. Tu velocidad de desarrollo se acelera de manera muy, muy rápida. Pasas de definir llamadas específicas a una acción a describir lo que quieres. Ahí es donde la orquestación de agentes, que consiste en asignar trabajo a los agentes, se vuelve posible. Sin eso, era simplemente imposible.

Kosta: Las APIs conectan herramientas, pero alguien todavía tiene que hacer clic en las cosas y darles sentido. MCP permite a los agentes leer el contexto a través de las herramientas y actuar dentro de ellas, a una escala que ningún individuo podría igualar.

¿Qué construiste realmente con MCP y qué hace?

Michelle: Construí un sistema de triaje que conecta el MCP de Pendo con el resto de los datos de la organización. Es mi rutina matutina de todos los días. ¿Qué necesito saber antes de hablar con alguien? Antes de ver cualquier repetición de sesión, ¿cuáles son las más importantes? ¿Qué pasó ayer?

Me dice qué hicieron ciertas personas, según un grupo que configuré en torno a nuestros gerentes de éxito del cliente. Señala la actividad estándar, posibles problemas a vigilar, picos de datos, diferentes volúmenes a analizar, logros para celebrar. También puedo preguntarle qué sesiones debo ver antes de contactar a cualquier CSM. Muestra cosas como: revisión intensiva de contenido sesiones, muchos clics de frustración y clics muertos, eventos de frustración significativos, usuarios avanzados en un flujo de trabajo de creación breve. Ese es el resumen matutino de un director de producto, creado en un agente y ejecutado en un horario diario.

Kosta: Introdujimos la transcripción de una llamada de descubrimiento de clientes en Claude y generamos un PRD directamente en el tablero de Miro. A partir de ahí, trazamos un flujo de usuario, agregamos capturas de pantalla de referencia y tomamos notas, todo en un espacio compartido. Una vez que el equipo estuvo alineado, pegué la URL del tablero en Claude Code. El MCP entendió el contexto y generó un prototipo funcional que reflejaba lo que habíamos acordado. Lo mostramos a las partes interesadas y lo validamos con el cliente el mismo día. Hace un año, ese tipo de velocidad no era posible. Ahora, cualquiera puede pasar de un problema del cliente a una solución alineada en cuestión de horas.

Gunjan: Como PMs, hacemos malabares con muchas cosas, y uno de los trabajos más importantes es saber qué están pidiendo los clientes: qué les gusta, qué no les gusta, cómo están usando el producto y qué está pasando en las conversaciones de ventas recientes. Esa investigación solía tomar horas. Construí un agente en Rovo. Le di acceso a mi herramienta de ventas, Google Docs, Calendar, GitHub, tickets de Jira, páginas de Confluence, notas de reuniones, leads de Hotspot. Cuando le pido que me ayude a prepararme para una reunión próxima, utiliza todas esas herramientas y produce un informe completo en minutos. Cosas que antes me tomaban horas ahora toman minutos, y entro a la sala con mucha más confianza.

¿Qué errores cometiste cuando construiste tu primer servidor MCP?

Francois: Cometimos un gran error: expusimos las herramientas como primitivas de muy bajo nivel. Lo que dijimos fue: si tienes una pregunta, llama a este endpoint y pasa tu pregunta. Si quieres reformular tu pregunta, usa este endpoint para reformularla. El problema es que le estábamos dando demasiado poder al LLM. Entonces el modelo estaba decidir cuándo usar qué herramienta y, en realidad, tienden a no usar una herramienta. Si son inteligentes, dirán: "¿Sabes qué? Puedo resolverlo yo mismo."

Por ejemplo, si preguntas "muéstrame mis 10 principales clientes", eso es muy ambiguo. El LLM simplemente encontraría su propia definición y llamaría a Spotter para obtener la respuesta. Y si hicieras la misma pregunta dos veces, podrías obtener una respuesta diferente. Estaba alucinando en el sentido de que definiría "principal" según lo que considerara más relevante para un conjunto de datos bancarios: a veces cuenta de ahorros, a veces cuenta de crédito. 

Ahora ofrecemos herramientas que traen toda la inteligencia consigo. No dejamos que Claude aporte su propia inteligencia, porque conocemos nuestros datos y tenemos más contexto que el modelo. Lo controlamos a través de nuestra capa semántica, de modo que cada vez que haces una pregunta obtienes la misma respuesta, fundamentada en todo el contexto que tenemos.

Michelle: Por eso exactamente usé todas las consultas SQL en mi capa de instrucciones. Estas son las definiciones. Esto es lo que significa ser "top" en nuestros datos. Las personas que realizan las consultas no siempre saben qué palabra exacta usar o cuál es el nombre del campo, por lo que ese nivel de explicación fue necesario para nuestros datos internos.

¿Cómo decidiste qué exponer primero y cómo decides qué no exponer?

Kosta: No es una solución única para todos. En Miro, comenzamos con casos de uso validados y redujimos estratégicamente en qué queríamos enfocarnos. Cuando construimos el servidor MCP, los ingenieros fueron realmente quienes más lo adoptaron. Así que construimos en torno a los flujos de trabajo de ingeniería, específicamente el problema de los agentes que escriben miles de líneas de código y lo difícil que es visualizar lo que están haciendo para orientarlos. Nos enfocamos en eso, y en cómo se toma la intención del equipo y se la pasa a la generación de código. Eso nos impidió abarcar demasiado demasiado pronto, lo que habría confundido tanto a los agentes como a nuestra narrativa de salida al mercado.

Michelle: Empezamos con un solo agente y fuimos avanzando desde ahí. También comenzamos con lo que era más fácil y más confiable. Queríamos asegurarnos de que los usuarios confiaran en la herramienta antes de decir "vamos a manejar esto de principio a fin por ti." Queremos que el usuario siga siendo quien toma el control, con barreras de protección establecidas, antes de decir que podemos manejar todas estas tareas automáticamente. Ese ha sido el proceso de crecimiento lento.

Francois: Realmente necesitas pensar en dónde quieres aprovechar la inteligencia. ¿Quieres delegar en el LLM? En algunos casos, eso es perfecto. Pero en nuestro caso, como los datos son tan sensibles, tuvimos que diseñarlo de la manera opuesta. Es mucho más que MCP en sí. Se trata realmente de incorporar el lado agéntico del asunto.

En cuanto a lo que no se debe exponer, todo vuelve a tu capa semántica. Ahí es donde especificas qué tablas quieres exponer y quién tiene derecho a hacer qué. En el mundo anterior, el dashboard era la barrera de protección. Un analista controlaba qué visualizaciones aparecían en el dashboard. Ahora que los dashboards están desapareciendo y las personas quieren hablar directamente con la datos, la capa semántica se convierte en el nuevo punto de control.

¿Cómo logras que tu equipo realmente cambie su forma de trabajar?

Kosta: Se reduce a dos cosas. Una es el mandato: ni siquiera depende solo de mí. El liderazgo de la empresa necesita decidir que es importante. En Miro, se entiende ampliamente que queremos acelerar la adopción, especialmente con la rapidez con que se mueve el mercado. Pero el mandato solo no es suficiente. Por eso también estamos invirtiendo mucho en habilitación. Nosotros tienen Guilds de Productos de IA, canales de Slack donde las personas pueden aprender unas de otras, sesiones en vivo. Como líderes también necesitamos modelar el comportamiento. Yo hago vibe coding de un prototipo y lo discuto con mis reportes directos. Ellos se inspiran — y muchas veces son ellos quienes me inspiran a mí. Están cerca del metal. Están construyendo cosas realmente increíbles.

Gunjan: Genuinamente necesitamos darles una oportunidad a estas herramientas. Explicar qué queremos que hagan y creer que lo lograrán. Los modelos de hoy quizás no lleguen del todo, pero los modelos del mañana definitivamente sí. Así que un acto de fe, intentarlo sin apuntar a la perfección, era el objetivo. Y hay que seguir volviendo e intentándolo. Hoy Claude Code es realmente bueno. Mañana algo más podría ser mejor. Cada seis meses, vuelve a probar estas herramientas porque puede que hayan desbloqueado algo que antes no podían hacer.

¿Cómo se ve el éxito para tus herramientas MCP? ¿Cuál es la métrica estrella del norte?

Gunjan: Muy pronto, creo que dejaremos de distinguir entre un usuario humano y un usuario de IA. Se trata principalmente de flujos de trabajo. Cuántos estás impulsando y cómo se están acelerando. Un equipo que resuelve 100 tickets y organiza cinco scrums al mes, con agentes escribiendo 100 PRs cada día, probablemente querrá un scrum diario para gestionar y controlar lo que está sucediendo. Tu KPI se convierte en: número de flujos de trabajo orquestados en tus sistemas, independientemente de dónde se encuentre el front end de esa experiencia.

Kosta: Lo estamos viendo como cualquier otro producto. Estamos observando un crecimiento no lineal en la adopción de MCP, tanto en términos de personas que lo usan como en la frecuencia con que lo usan. Pero realmente estamos tratando de entender los flujos de trabajo. ¿Para qué lo están usando? ¿Están teniendo éxito? ¿Están volviendo a usarlo para esos flujos de trabajo? Estamos viendo una verdadera fidelización ahora, especialmente con cosas como la visualización de código. Todavía estamos analizando cómo las personas usan Miro en general, no solo MCP. Es ambas cosas.

Si los usuarios obtienen valor de tu producto sin abrir nunca tu interfaz de usuario, ¿qué significa eso para tu negocio?

Kosta: Yo lo vería al revés. Si los agentes están haciendo el trabajo, ¿adónde van los equipos para entenderlos y dirigirlos? La mayoría de las herramientas de IA son una caja negra. Nosotros pensamos mucho en dónde ir para alinear esos agentes, cómo asegurarse de que estén haciendo lo correcto. Para nosotros, eso es una oportunidad, no una amenaza. Miro fue creado para la colaboración en equipo. Eso no cambia. El equipo simplemente creció.

Gunjan: Tu ventaja competitiva es lo que construyes. Si alguien más puede reconstruir tu producto más rápido de lo que tú puedes defenderlo, entonces sí, reconsidera. Pero si puedes redoblar la apuesta en tu ventaja y decir "esta es la razón por la que la gente usa nuestro producto y este es el mejor resultado para ellos", puedes enfocarte de verdad. Estar obsesionado con el cliente te da el derecho de preguntar a tus clientes para que se queden contigo. Si están satisfechos con lo que les ofreces, lo harán.

Francois: Para nosotros, como herramienta de análisis, la experiencia del usuario es sumamente importante. Necesitas poder profundizar, visualizar y cambiar cosas. Lo bueno de las aplicaciones MCP es que ya no tienes que elegir. Los usuarios avanzados aún pueden explorar el producto en profundidad. Los usuarios de negocio pueden hacer una pregunta y obtener un gráfico directamente dentro de su agente. Es coexistencia, no competencia.

¿Cómo está evolucionando realmente la función de gestión de producto?

Michelle: Me encantaría dejar de escribir historias en Jira — y de hecho, la IA ya está escribiendo muchas por mí. Pero aún se necesita el cerebro. Lo que mejora: menos retrabajo, menos errores, porque el contexto se conserva y lo que se te pasó la última vez no se te pasará la próxima. Ya no pasamos tanto tiempo en los spikes. Cuánto tiempo pasamos leyendo la documentación de la API para averiguar si algo era posible? En cinco minutos puedes obtener esa respuesta. Quizás no más spikes.

Kosta: Los agentes están asumiendo más trabajo de ejecución y detalles operativos. Pero el verdadero oficio del PM (la definición del problema, la alineación, la comunicación) es más importante que nunca. No quieres que los agentes actúen sin control y decidan qué construir. Nadie quiere ese mundo. Así que los profesionales de producto necesitan dar un paso adelante, pensar más en la craft: definición del problema, curación del contexto. El rol está evolucionando, alejándose de la ejecución y orientándose hacia actividades de mayor impacto.

Gunjan: Las barreras que antes frenaban a las personas: "No sé escribir código", "No entiendo la sintaxis", han desaparecido. Entonces, la identificación de problemas es algo muy importante en esta nueva era. Conectar los puntos también es fundamental. La IA no va a conectar los puntos por ti. Necesitas ver qué problema resolver, qué problema existe. Y el criterio es un una habilidad muy difícil de desarrollar, y eso no ha cambiado. No importa qué tecnología aparezca o desaparezca. Dedicar tiempo a entender qué es lo bueno, en una experiencia o un producto, eso sigue importando mucho.

¿Listo para comenzar con Pendo MCP? Consulta nuestra biblioteca de prompts, y configúralo gratis.