Sabíamos que FlowHunt necesitaba un servidor MCP, y no pensábamos que nos ayudaría mucho. Al final resultó siendo la mayor ayuda.
Puntos clave
- Siempre supimos que FlowHunt necesitaba un servidor MCP. Lo vimos como una característica que los usuarios esperan, y estábamos seguros de que no nos ayudaría en nada como desarrolladores. Eso resultó ser falso.
- Un agente conectado a un servidor MCP no puede ver el código. Solo ve las herramientas y sus respuestas, por lo que prueba la aplicación como lo haría un usuario. En nuestras pruebas antes del lanzamiento encontró ejecuciones que reportaban costo cero, acciones en lote que decían “éxito” para ids que no existían, y un lote de 11 filas que reportaba 16 realizadas. Las reparamos todas antes de que el servidor se lanzara.
- También nos mostró dónde nuestro diseño no coincidía con cómo un agente piensa realmente. Seis agentes creando flujos todos fallaron su primera llamada por culpa de un nombre de argumento.
- Construirlo con un agente de codificación fue bastante rápido, porque nuestra API ya existía. La mayoría del trabajo fue elegir qué exponer y hacerlo seguro.
- Ambos servidores están en vivo: AmICited para SEO, GEO y AEO, y AI Studio para automatización, donde tu agente crea flujos a partir del conocimiento de nuestra Biblioteca de Agentes. Los pasos de conexión están al final.
¿Por qué crear un servidor MCP si tu aplicación ya tiene una API?
Un servidor MCP expone tu aplicación a agentes de IA a través del Protocolo de Contexto del Modelo , el estándar abierto que permite a un cliente MCP como Claude, ChatGPT o Cursor descubrir tus herramientas y llamarlas. Si es la primera vez que lo oyes, nuestra guía sobre qué es un servidor MCP cubre los conceptos básicos.
Durante mucho tiempo, FlowHunt no tuvo un servidor MCP adecuado. Cada aplicación popular parecía estar lanzando una, y nosotros tuvimos una beta aquí y allá, pero nadie se tomó el tiempo de terminarla.
Sabíamos que la necesitábamos. Con AmICited era obvio, porque la gente quiere preguntarle a un agente “¿cómo se cita mi marca en la búsqueda de IA esta semana?” sin abrir un panel de control. AI Studio, nuestro constructor visual de flujos, también necesitaba una. Solo lo vimos como una casilla: algo que los usuarios esperan, que vale la pena tener, nada especial. Y estábamos seguros de que no tenía nada que ofrecernos como desarrolladores. Sería una superficie de API más para mantener.
Lo opuesto resultó ser cierto. El servidor MCP se convirtió en una de las cosas más útiles que construimos en 2026, y las personas a las que más ayudó fueron nosotros.
Cómo crear un servidor MCP para una aplicación existente
Si ya tienes una aplicación, ya tienes la mayor parte de un servidor MCP. Las funciones y rutas de API existen. Lo que queda es principalmente decisiones, y un agente de codificación toma esas decisiones rápidamente. Para el código mismo (instalar el SDK, definir una herramienta, ejecutar el servidor), consulta nuestra guía de desarrollo de servidores MCP .
Convierte tus rutas de API en herramientas MCP
- Pídele a tu agente que liste cada función y ruta de API que tiene la aplicación.
- Decide cuáles de ellas debería poder usar un agente. Para nosotros fue casi todo lo que un usuario puede hacer en el panel de control.
- Haz que el agente envuelva cada una como una herramienta: un nombre, una descripción escrita en las palabras que un usuario buscaría, y una llamada al endpoint existente.
- Haz el trabajo de seguridad.
- Envía el servidor a los directorios de conectores de Anthropic y otros proveedores de IA, para que la gente pueda encontrarlo donde ya mira.
Nuestras herramientas MCP son envoltorios finos. Cada una llama a un endpoint existente y devuelve su respuesta existente, por lo que el agente puede listar flujos, leer el canvas de un flujo, editarlo, ejecutarlo y leer el resultado. Los permisos y controles de crédito viven debajo de ese envoltorio, por lo que el agente obtiene exactamente los derechos que el usuario tiene en el panel de control.
Asegura el servidor MCP
El trabajo de seguridad requería la mayor reflexión, y aun así fue cuestión de sesiones enfocadas con Claude, no semanas. En esas sesiones hicimos:
- movimos el inicio de sesión a OAuth, con concesiones que el usuario puede ver y revocar desde el panel de control
- vinculamos cada conexión a un espacio de trabajo, por lo que ninguna herramienta toma un id de espacio de trabajo que un agente pudiera cambiar
- limitamos los tamaños de importación y la concurrencia
- marcamos cada herramienta que escribe datos, e indicamos deletes y cualquier cosa que gasta dinero como destructiva
Nada de eso es exótico. Es la misma lista de verificación que ejecutarías en cualquier API pública. Claude fue bueno encontrando los lugares donde nos habíamos saltado una. Nuestra lista de verificación de seguridad de MCP y el artículo sobre autenticación MCP con OAuth van más a fondo.
¿Cómo es diferente la prueba de servidor MCP de los tests unitarios?
Esta es la parte que no vi venir.
Cuando los agentes escriben código para ti, principalmente prueban el código. Ejecutan los tests unitarios. A veces hacen una pasada de verificación, o hacen clic a través de la UI web en un navegador. Todo eso verifica que el código hace lo que el código dice. Nada de eso verifica si una persona, o un agente, puede realmente hacer su trabajo con el producto.
Un servidor MCP cambia eso. El agente conectado a él no puede ver la fuente. Solo ve las herramientas, sus descripciones y las respuestas que devuelven. Esa es la misma posición en la que se encuentra un usuario real, así que cuando el agente usa el servidor MCP está probando la aplicación.
Lo que los agentes encontraron antes del lanzamiento
Nuestra prueba de caja negra antes del lanzamiento hizo exactamente eso. Les dimos a los agentes tareas y les permitimos usar AI Studio a través del servidor MCP en nuestro entorno de prueba interno, y encontraron problemas que ningún test unitario había capturado:
- Una ejecución finalizada reportaba un costo de cero, aunque había gastado créditos.
- Las acciones en lote decían “éxito” para ids que no existían.
- Un lote de 11 filas reportaba 16 filas realizadas, porque los pasos reproducidos contaban las filas completadas una segunda vez.
- Una ejecución detenida parecía que seguía ejecutándose, y así se quedó para siempre.
- Cambiar la respuesta de una FAQ no actualizaba sus preguntas alternativas.
- Las herramientas aceptaban configuraciones que el producto no puede usar, como un nombre de modelo que no está en el catálogo, y las guardaban sin quejarse.
Ninguno de estos llegó a nuestros usuarios. Las pruebas internas los encontraron, y los reparamos antes de que el servidor se lanzara. Los tests unitarios habían pasado sobre cada uno de ellos, y una persona haciendo clic a través de la UI fácilmente podría haberlos perdido también, actualizando la página o encogiéndose de hombros ante un número impar. Un agente no. Toma la respuesta al pie de la letra y hace lo incorrecto a continuación, lo que te muestra exactamente dónde la respuesta fue incorrecta.
¿Qué brechas en el diseño de herramientas expusieron los agentes?
El segundo tipo de hallazgo fue más interesante. Estos no eran errores. Eran brechas entre cómo diseñamos una herramienta y cómo un agente realmente intentó usarla.
Nombres de argumentos que un agente adivina
En una prueba, seis agentes cada uno construyeron un flujo a través del servidor MCP. Los seis fallaron en su primera llamada para buscar un componente, porque adivinaron que el argumento se llamaba type y nosotros lo habíamos nombrado component_type. Un agente pasó alrededor de diez llamadas buscando Google Search, porque nuestra búsqueda clasificaba un paso “Search Received Orders” de una integración ERP por encima de “Google Search Retriever” cuando escribías “search”.
Nunca lo atraparías en una revisión de código, porque el código era correcto. La herramienta hizo lo que dijo. Solo no coincidía con lo que cualquiera razonablemente intentaría primero. Así que renombramos los argumentos a los nombres que los resultados de búsqueda devuelven, y clasificamos los resultados de búsqueda por qué tan bien coinciden. Los agentes dejaron de tropezar.
Los manuales se probaron de la misma manera
También escribimos manuales cortos, servidos a través del servidor MCP como habilidades, que le dicen a un agente cómo construir un buen flujo: busca en la biblioteca primero, prueba el borrador antes de publicar, mantén los guardrails fuera de la respuesta final. Luego probamos los manuales de la misma manera. Agentes frescos reconstruyeron las mismas tareas con solo el manual para leer, y un modelo separado juzgó los resultados sin saber cuál fue cuál. Con el manual final, los constructores terminaron en aproximadamente una tercera parte del tiempo que les tomó con el borrador. Las ejecuciones también expusieron brechas en el manual mismo, como el hecho de que la búsqueda no tiene filtro de fecha a menos que pongas after:YYYY-MM-DD en la consulta. Eso volvió al texto.
Ese es un bucle de retroalimentación que nunca habíamos tenido antes. El agente usa la aplicación, se atasca en algún lugar específico, y reparamos ese lugar.
Cómo un servidor MCP cambia la revisión de solicitudes de cambio
Revisar una solicitud de cambio es diferente ahora. Antes, verificar un cambio significaba leer el diff, ejecutar los tests y tal vez hacer clic a través de la UI. Ahora el escenario de prueba es una oración: “conecta al servidor MCP, crea un flujo que haga X, ejecútalo, verifica el costo.” El agente maneja la aplicación real, y el resultado es algo que puedes pegar en la solicitud de cambio como evidencia.
Los escenarios se hicieron más claros porque se escriben como tareas de usuario, no como funciones de prueba. También cuestan menos tokens. Manejar una aplicación a través de herramientas MCP es mucho más barato que hacer que un agente lea capturas de pantalla y busque botones en un navegador. Y encontran las brechas entre características, que es donde la mayoría de nuestros problemas reales se estaban escondiendo.
Qué cambia un servidor MCP para tus usuarios
FlowHunt es una aplicación grande. AI Studio sola tiene flujos, agentes, chatbots, bases de conocimiento, horarios, lotes, integraciones y más de mil componentes. AmICited tiene su propia lista larga de informes. Mucha gente encuentra difícil empezar. Incluso las personas que empiezan se pierden características, o las encuentran por accidente meses después.
Con el servidor MCP, eso importa mucho menos. Le dices a tu agente lo que quieres, y el agente encuentra la herramienta que lo hace. Lee la descripción, sabe qué característica encaja, y la usa. Aparte de copiar la URL de conexión, no tienes que abrir el panel de control. Las personas terminan usando más de lo que el producto puede hacer, y creo que lo valoran más, porque realmente ven todo.
Cómo conectar los servidores MCP de FlowHunt y AmICited
Ambos servidores están en vivo, y me gustaría que todos los probaran: empresas, agencias, equipos de marketing, fundadores que hacen su propio SEO. Conectas el agente que ya usas, inicias sesión, eliges un espacio de trabajo, y empiezas a preguntar.
Servidor MCP de AmICited para SEO, GEO y AEO
AmICited rastrea cómo los motores de búsqueda de IA citan tu marca, y conecta Search Console, GA4, auditorías de sitio, backlinks, competidores, plataformas publicitarias y modelos de mezcla de marketing. A través de MCP, tu agente puede usar todo eso. El servidor también incluye 29 manuales que el agente puede leer, escritos a partir de cómo hacemos nosotros mismos estos análisis: triaje de caída de tráfico, auditoría de visibilidad de IA, análisis de brecha de competidores, limpieza de canibalización, revisión de gasto en anuncios, “¿funcionó nuestro cambio?”, y más. Haces una pregunta en palabras simples y el agente sigue el manual que encaja:
- “¿Por qué cayó el tráfico orgánico la semana pasada?”
- “¿Qué prompts citan a mis competidores pero no a nosotros, y qué contenido lo arreglería?”
- “¿Qué campañas publicitarias gastan dinero sin convertir?”
- “Audita el sitio y cuéntame los cinco arreglos que vale la pena hacer primero.”
No necesitas saber qué informe tiene la respuesta. El agente lo sabe.
Servidor MCP de FlowHunt AI Studio para automatización de flujos de trabajo
Esta parte me sorprendió la más. La Biblioteca de Agentes de FlowHunt tiene 264 flujos publicados que hemos construido y refinado a lo largo de años, y los clientes contratan algunos de ellos cada día. Destilamos lo que hace que esos flujos funcionen en un manual que el servidor MCP le entrega a tu agente, ponderado hacia los 28 flujos que los clientes contratan más. Así que cuando le pides a tu agente que automatice algo, no empieza desde un canvas en blanco. Busca en la biblioteca una plantilla similar, lee cómo se construye ese flujo (las herramientas, el prompt, el formato de salida, los guardrails), aplica el patrón a tu tarea, prueba un borrador, y solo entonces lo publica.
En la práctica, describes el trabajo y obtienes un flujo funcionando que usa años de nuestro conocimiento:
- “Cada mañana, resume las noticias sobre nuestros competidores y envíalas a Slack.”
- “Lee nuevos tickets de soporte, responde los que la base de conocimiento cubre, y etiqueta el resto.”
- “Construye un chatbot para nuestra página de precios que responda desde nuestros documentos.”
Puedes construir flujos complejos de esta manera: agentes que llaman a otros agentes, routers, ejecuciones programadas, lotes sobre una hoja de cálculo. Ese tipo de flujo tarda un tiempo en aprender en el editor visual. Tu agente llega allí en minutos, y aún puedes abrir el canvas después para ver qué construyó.
Conecta en Claude Code, Claude o ChatGPT
Conectar tarda un minuto. Añade el servidor a cualquier cliente MCP que admita servidores remotos. En Claude Code, ejecuta:
claude mcp add --transport http flowhunt-aistudio https://api.flowhunt.io/mcp/aistudio
claude mcp add --transport http flowhunt-amicited https://api.flowhunt.io/mcp/amicited
En Claude y ChatGPT, añade la misma URL como un conector personalizado. Tu cliente abre una página de inicio de sesión, eliges el espacio de trabajo, y el agente ve solo ese espacio de trabajo. Puedes ver y revocar clientes conectados desde el panel de control en cualquier momento. La documentación de conexión tiene los pasos para cada cliente.
Planes y precios
Puedes conectar un agente en la prueba de 7 días y en los planes Pro, Agencia y Enterprise . Starter no incluye acceso a MCP. En AI Studio, las llamadas MCP en sí son gratuitas, hasta un límite por hora que depende de tu plan: 120 llamadas en la prueba, 600 en Pro, 2.000 en Agencia, y sin límite en Enterprise. Cualquier cosa que gaste créditos en el panel de control, como ejecutar un flujo, gasta los mismos créditos a través de MCP. En AmICited, cada solicitud MCP cuesta 0,001 créditos, por lo que mil solicitudes cuestan un crédito.
Próximos pasos: crea un servidor MCP y prueba el nuestro
Si posees una aplicación, crea el servidor MCP. Hazlo incluso si piensas que es solo una característica para usuarios y no hará nada para tus desarrolladores. Nosotros pensamos eso también, y nos equivocamos. Es un cliente de prueba que usa tu producto como lo haría un extraño, e informa cada nombre de argumento confuso, cada número incorrecto y cada “éxito” que no lo fue. Si ya tienes una API, construirlo es rápido, y el trabajo de seguridad es algunas sesiones enfocadas, no un proyecto.
Si trabajas en marketing, SEO u operaciones, conecta tu agente a FlowHunt y AmICited y dale una tarea real de tu semana. Encontrarás características que no sabías que teníamos, y no tendrás que aprender el panel de control para usarlas.
Los servidores MCP no son solo para tus usuarios. Son una de las mejores herramientas que tus desarrolladores pueden tener. Y para tus usuarios, son la forma más rápida de aprovechar al máximo tu producto.

