Customer Research from Cursor: MCP Setup and Workflow

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 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 the client or open a new session so it loads the current research tool catalog. Verify the connection with a read such as list_studies.

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 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 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 retrieves the selected study report with get_study_report and checks interviews with list_interviews and get_interview.

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?

MCP exposes study planning, recruitment, interviews, results, evidence search, and supporting configuration operations. The CLI provides shell access to research workflows. Use the current tool catalog and API reference for exact names and arguments; tool counts vary by release.

Create a metadata draft with create_study, then send the research brief through customize_study. Relay any planning questions to the user. Retrieve the persisted plan with get_study and obtain approval before recruitment. The user must choose panel or BYOP explicitly.

Study results expose findings, participant responses, sample profiles, recommendations, and source references in JSON. Use generate_report when analysis is needed, and get_interview to verify supporting messages and recording links. Preference shares, credibility scores, and ranked themes are not guaranteed typed fields in this response.

Agents can search findings and participant responses across authorized studies, then retrieve the underlying reports and interviews. Results preserve study context and source links; the calling agent interprets the evidence. Search coverage is explicit, and retrieving evidence does not launch 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 33 tool descriptions, parameter references, and example workflows.