WebAsk launched an MCP server for surveys and found that AI reads more than it creates

WebAsk connected its survey and test builder to MCP so Claude, Cursor, and other LLM clients could work with the service without switching to a browser. After launching, the team discovered that the main demand came not from generating new questionnaires, but from reading, analyzing, and exporting already collected responses.

Why WebAsk Needs MCP

The WebAsk team describes a familiar scenario: a user writes a report or reviews code in an LLM, then suddenly needs to quickly conduct a survey for HR, a conference, or onboarding. Without integration, this means a new tab, logging into the service, manually configuring a form, and losing context. In this situation, MCP became for the product not a fashionable add-on, but a way to keep the user in a single conversation with an assistant and give the model access to the service's already existing infrastructure.

At the same time, WebAsk emphasizes: LLMs can quickly come up with questions, but the questionnaire itself is only a small part of the work.

• publishing and hosting a survey for thousands of respondents
• collecting responses without loss and storing data
• analytics like NPS, segmentation, and heatmaps
• exporting results to CSV, Excel, PDF, and Word
• integrations with external systems and webhooks

How the Server Works

The team built the MCP server as a thin Node.js layer between clients like Claude and Cursor and WebAsk's main backend. On the outside, it's JSON-RPC 2.

0 with authorization via Bearer token; inside, it's a router, validation schemas, and a separate handler for each tool. The architecture turned out to be straightforward: a request comes in with the tool name, parameters are validated against the schema, then the server calls the corresponding REST API method and returns the response to the model. The main practical problem turned out not to be in the code, but in client compatibility.

According to the spec, MCP can work with tools, resources, and prompts, but in Claude Desktop the team saw support only for tools. So WebAsk wrapped 19 resources—such as reading responses, survey structure, and summaries—into separate wrapper tools. As a result, the server grew to approximately 60 tools, divided into groups: survey lifecycle, content, formatting, analytics, export, and promo codes.

Where the Pitfalls Were

The most painful lesson concerned tool descriptions. Short formulations saved tokens, but the model too often confused similar actions, substituted incorrect parameters, and sometimes even chose the wrong tool. After several iterations, the team rewrote the descriptions in more detail: with constraints, examples of parameters, and typical scenarios. This increased the context, but noticeably improved accuracy on complex call chains.

"Saving on descriptions is a false economy."

At the same time, they had to reconsider rate limits and the testing approach itself. If a person is fine with 60 requests per minute, an agent easily makes 50–70 calls in a few seconds, so WebAsk settled on a threshold of 180 requests per minute. And testing turned into a manual run-through of approximately 20 scenarios: the model could change the order of actions, add a welcome screen or formatting theme on its own, and show excessive initiative.

In practice, the most common case turned out not to be the builder, but analytics: Cursor reads hundreds of text responses, groups them by topic, and prepares a summary for the report faster than a person can open the right dashboard.

What This Means

The WebAsk story shows well that MCP for SaaS is no longer a toy for demos, but a new interface on top of an existing product. But the winner is not the one who simply opened API access for LLMs, but the one who thought through tool descriptions, client constraints, and real user workflows where AI saves not clicks, but hours of manual work.