WebAsk lanzó un servidor MCP para encuestas y descubrió que AI lee más de lo que crea

WebAsk conectó su constructor de encuestas y pruebas a MCP para que Claude, Cursor y otros clientes LLM pudieran trabajar con el servicio sin cambiar de pestaña en el navegador. Tras el lanzamiento, el equipo descubrió que la demanda principal no procedía de la generación de nuevos cuestionarios, sino de la lectura, análisis y exportación de respuestas ya recopiladas.

Por Qué WebAsk Necesita MCP

El equipo de WebAsk describe un escenario familiar: un usuario escribe un informe o revisa código en un LLM y luego necesita urgentemente realizar una encuesta para RR.HH., una conferencia u onboarding.

Sin integración, esto significa una pestaña nueva, iniciar sesión en el servicio, configurar manualmente el formulario y perder el contexto. En esta situación, MCP se convirtió para el producto no en un complemento de moda, sino en una forma de mantener al usuario en una única conversación con el asistente y darle al modelo acceso a la infraestructura ya existente del servicio. Al mismo tiempo, WebAsk enfatiza: los LLM pueden pensar rápidamente en preguntas, pero el cuestionario en sí es solo una pequeña parte del trabajo.

• publicación y alojamiento de encuestas para miles de encuestados
• recopilación de respuestas sin pérdida y almacenamiento de datos
• análisis como NPS, segmentación y mapas de calor
• exportación de resultados a CSV, Excel, PDF y Word
• integraciones con sistemas externos y webhooks

Cómo Está Construido el Servidor

El equipo construyó el servidor MCP como una capa Node.js fina entre clientes como Claude y Cursor y el backend principal de WebAsk. Por fuera, es JSON-RPC 2.

0 con autorización mediante token Bearer; por dentro, es un enrutador, esquemas de validación y un controlador separado para cada herramienta. La arquitectura resultó ser directa: una solicitud llega con el nombre de la herramienta, los parámetros se validan contra el esquema, luego el servidor llama al método REST API correspondiente y devuelve la respuesta al modelo. El principal problema práctico no estuvo en el código, sino en la compatibilidad de los clientes.

Según la especificación, MCP puede trabajar con tools, resources y prompts, pero en Claude Desktop el equipo solo vio soporte para tools. Entonces WebAsk envolvió 19 recursos—como lectura de respuestas, estructura de encuesta y resúmenes—en herramientas wrapper separadas. Como resultado, el servidor creció a aproximadamente 60 herramientas, divididas en grupos: ciclo de vida de la encuesta, contenido, formato, análisis, exportación y códigos promocionales.

Dónde Estuvieron los Problemas

La lección más dolorosa fue sobre descripciones de herramientas. Las formulaciones breves ahorraban tokens, pero el modelo confundía demasiado frecuentemente acciones similares, sustituía parámetros incorrectos y a veces incluso elegía la herramienta equivocada. Tras varias iteraciones, el equipo reescribió las descripciones con más detalle: con restricciones, ejemplos de parámetros y escenarios típicos. Esto aumentó el contexto, pero mejoró notablemente la precisión en cadenas de llamadas complejas.

"Ahorrar en descripciones es una falsa economía."

Al mismo tiempo, fue necesario reconsiderar los límites de velocidad y el propio enfoque de pruebas. Si una persona se desenvuelve bien con 60 solicitudes por minuto, un agente fácilmente hace 50–70 llamadas en segundos, así que WebAsk se estableció en un umbral de 180 solicitudes por minuto. Y las pruebas se convirtieron en una ejecución manual de aproximadamente 20 escenarios: el modelo podría cambiar el orden de las acciones, agregar una pantalla de bienvenida o tema de formato por su cuenta y mostrar iniciativa excesiva.

En la práctica, el caso más común resultó no ser el constructor, sino el análisis: Cursor lee cientos de respuestas de texto, las agrupa por tema y prepara un resumen para el informe más rápido de lo que una persona puede abrir el dashboard correcto.

Qué Significa Esto

La historia de WebAsk demuestra bien que MCP para SaaS ya no es un juguete para demostraciones, sino una nueva interfaz sobre un producto existente. Pero gana no quien simplemente abrió acceso a la API para LLMs, sino quien pensó cuidadosamente en descripciones de herramientas, restricciones de clientes y flujos de usuarios reales donde la IA ahorra no clics, sino horas de trabajo manual.