Customer Research from Cursor: Running Studies Without Leaving the IDE

Why the IDE is becoming the right place for customer research

The Cursor audience builds with AI assistance baked into the editing loop. Features get drafted, refined, and shipped in cycles measured in hours, not sprints. The natural question that follows each draft is: do real users actually want this?

Until recently, answering that question meant leaving the IDE entirely — opening a research tool in a browser, drafting a study, waiting days for responses, and returning to development with stale context. The gap between the decision environment (the IDE) and the signal environment (a research dashboard) meant that most research questions never got asked, because the friction was too high.

MCP changes this. By connecting an agentic research platform directly to Cursor’s composer, customer research becomes a callable action within the same tool used to write code. A developer or PM building a feature can raise a research question and trigger a study without switching contexts. Results land asynchronously, the same way a long-running test suite does.

This guide walks through the setup, the practical workflow patterns, and the use cases that fit best inside an IDE research loop.

What Cursor + customer research changes about the build-test-ship cycle

Standard product development treats customer research as a phase — something that happens before or after the build, not during it. The constraint is mostly logistical: research has its own tools, timelines, and handoff processes.

When research runs through Cursor’s composer, the phase boundary dissolves. Research becomes a type of tool call, in the same category as a linter, a test runner, or a database query. The practical consequences:

Earlier signal on smaller decisions. Questions that would never justify a formal research project — “is this error message clear?” “does this feature name make sense to non-technical users?” — become cheap enough to ask. Studies with a focused scope return results in 24-48 hours.

Context stays fresh. Research questions raised while a feature is in active development get answered before the feature ships, not two sprints later. The context that motivated the question is still live.

The research habit compounds. Teams that run research from their IDE run more research, because the activation cost is lower. More research means the Intelligence Hub accumulates more signal, which makes future queries more useful. The workflow reinforces itself.

Setup: Cursor MCP config block

To connect User Intuition to Cursor, create or edit .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "userintuition": {
      "command": "npx",
      "args": ["-y", "@userintuition-ai/mcp"],
      "env": {
        "USERINTUITION_API_KEY": "ui_sk_your_key_here"
      }
    }
  }
}

Replace ui_sk_your_key_here with your actual API key from the User Intuition dashboard.

After saving, restart Cursor. On the next session start, the composer will discover User Intuition’s 72 tools from the server’s manifest and make them available as invokable actions.

Project-level vs. global config. The .cursor/mcp.json path applies only to the current project. For teams with multiple developers, commit this file to version control so every team member gets the same tool access when they pull the repository. If you want research tools available across all projects, use Cursor’s global MCP settings instead.

API key security. Do not commit the literal ui_sk_ key value to a public repository. Use an environment variable injection pattern or a .env file referenced from the config. The env block in the MCP config supports environment variable references, so you can write "USERINTUITION_API_KEY": "${USERINTUITION_API_KEY}" and source the actual value from your shell environment.

5 example prompts that fit IDE workflows

These prompts are designed for Cursor’s composer — they represent the kinds of questions that arise naturally during development and can now be answered without leaving the IDE.

1. Validate a feature description before writing the spec

Run a 10-participant study testing whether developers understand what 
"session-aware memory" means in this context. Use the panel — software 
engineers at companies with 10-200 employees. Ask them to describe in 
their own words what they expect this feature to do.

This kind of concept clarity check prevents building to an internal framing that real users won’t recognize.

2. Test copy for an error message before it ships

We're deciding between these three error messages for a failed API 
authentication. Create a study with 15 participants (developers, 
mid-career) and ask which message they find clearest and why. 
Target turnaround: 24 hours.

Error message copy is high-stakes and rarely tested. Running this from the IDE makes it practical.

3. Message-test a pricing page variant

We've written two versions of the pricing page headline. Run a 
message-testing study with 20 participants matching our ICP 
(product managers at B2B SaaS companies). Ask which version 
better communicates the value of the Pro plan and why.

4. Run a churn study on cancelled customers

Use our custom participant list (the CSV I'll attach) to run 
exit interviews with customers who cancelled in the last 90 days. 
Use the discovery interview format. I want verbatim quotes 
organized by cancellation reason.

Custom lists allow research targeted at your own user base, not just panel participants.

5. Query past research before a design decision

Before I finalize the onboarding flow redesign, search the 
Intelligence Hub for any past interview findings about where 
users got confused during onboarding. Summarize the top three 
friction points with supporting quotes.

This uses the cross-study query capability, not a new study — drawing on accumulated signal before committing to a design direction.

The “fire and check back” pattern for long-running studies

Studies don’t complete in real time. When you trigger a study from Cursor’s composer, the platform queues participant recruitment, schedules interviews, and runs them in parallel over the following hours. The composer call returns a study ID immediately; the results arrive later.

This maps cleanly to the fire-and-check-back pattern already common in IDE workflows — the same way you might trigger a CI run and check back when it completes.

In practice:

1. Trigger the study. Describe what you need to the composer. The MCP server creates the study, recruits participants, and returns a study ID.

2. Continue working. The study runs in the background. With panel recruitment, results typically start arriving within a few hours and are complete within 24-48 hours.

3. Check back. In a later Cursor session, ask the composer: “What are the results from the study I ran yesterday about error message clarity?” The composer calls the get_results or list_calls tools and surfaces the findings inline.

4. Act on the output. Verbatim quotes, thematic summaries, and minority views are all available in the results. The Intelligence Hub stores the findings automatically, making them queryable in future sessions.

No dashboard login, no context switch, no waiting to hear back from a research team. The entire loop stays within the IDE.

How does User Intuition handle Cursor-driven research?

User Intuition’s MCP server is designed for exactly this integration pattern. The same 72-tool surface available to Claude, ChatGPT, or any other MCP-compatible client is available through Cursor’s composer via the project-level config above.

What the Cursor integration unlocks specifically:

Full study lifecycle from the composer. Create a study, configure the assistant prompt, set target audience criteria, launch recruitment from the 4M+ panel, and retrieve results — all through tool calls in Cursor’s composer without opening a browser.

Async study management. Studies are first-class async operations. The list_studies tool returns all your active and completed studies, get_results retrieves findings for a specific study, and analyze_transcripts runs a structured analysis across a set of interviews. All are callable from Cursor.

Intelligence Hub queries as a research starting point. Before triggering new fieldwork, the query_intelligence tool lets you check what past studies have already found. This prevents redundant research and surfaces relevant signal that might already exist in the knowledge store.

Panel targeting from IDE context. Participant targeting criteria — role, company size, geography, domain experience — are specified as parameters in the tool call. A developer writing a feature for a specific user type can target that segment directly without navigating a separate audience builder.

Explore the full platform at userintuition.ai/platform/agentic-research/.

Get started

1. Get your ui_sk_ API key from the User Intuition dashboard.
2. Add the .cursor/mcp.json config block above to your project.
3. Restart Cursor — User Intuition tools will appear in the composer tool list.
4. Ask the composer to run your first study.

Full MCP documentation at docs.userintuition.ai/mcp-server/overview, including all 72 tool descriptions, parameter references, and example workflows.