When a customer research platform ships both an MCP server and a REST API, the natural question is: which one should I use? The answer depends on who is making the integration decisions — an AI agent at runtime, or a software developer at build time.
This guide is a decision framework for teams evaluating both surfaces. Both are fully supported. Both access the same underlying platform capabilities. The right choice depends on your workflow architecture, not on which one is more modern or more powerful. For teams building agent-native research workflows, the User Intuition agentic research platform supports both paths.
What each protocol exposes
MCP: tool discovery for AI agents
The Model Context Protocol exposes a research platform as a set of typed tools that an AI agent discovers at runtime. When an agent connects to an MCP server, it receives a manifest listing every available tool — its name, description, and input/output schema — without the developer pre-specifying which operations the agent will use.
The agent selects from the discovered schemas: for example, create_study for a metadata draft and customize_study for the research brief. Tool selection is context-driven, while the saved plan and recruitment still require the user’s approval.
The User Intuition MCP server exposes research tools across six research tool groups via npx -y @userintuition-ai/mcp (stdio) or https://mcp.userintuition.ai/mcp (Streamable HTTP / OAuth).
REST API: deterministic calls for software pipelines
The REST API exposes the same capabilities as named HTTP endpoints at https://api.userintuition.ai. A developer calls a specific endpoint, constructs the request body according to the documentation, and handles the structured JSON response in application code.
REST is a deterministic contract: the developer specifies exactly what operation runs and when. The code does not discover available operations at runtime — the developer reads the API reference and writes the call explicitly. This is a strength for predictable, repeatable workflows and a constraint when the workflow needs to adapt dynamically to context.
Both surfaces authenticate with the same ui_sk_ key. Operations are identical; what differs is how the caller learns about them and how the integration is structured.
Five decision factors
1. Agent involvement
MCP is the right choice when an AI agent is driving the research workflow — deciding which study to run, which participants to target, when to retrieve results, and what to do with them. MCP’s tool discovery lets the agent make those decisions with full schema awareness.
REST is the right choice when a software service — not an agent — is driving the workflow. A backend job that always runs the same study type on a weekly schedule does not need schema discovery; it knows exactly what to call.
2. Schema discovery
MCP provides tool manifests at connection time. The agent does not need prior knowledge of the API; it reads the schema on connect. This matters for agent frameworks that route research operations across multiple tools without developer-defined routing logic.
REST requires the developer to read the documentation and build explicit request constructors. No runtime discovery. If the API changes (new endpoint, new required field), the developer updates the code; the application does not self-adapt.
3. Multi-client support
MCP enables the same research server to serve multiple agent clients with zero per-client code: Claude Desktop, Claude Code, ChatGPT (via Streamable HTTP connector), Cursor, and any other MCP-compatible agent framework. The server is defined once; each client discovers it via the same protocol.
REST typically requires per-client integration code, authentication handling, and response parsing. If you want to expose research capabilities to multiple AI tools or internal applications, REST means building multiple integration layers.
4. Error handling and retry logic
REST gives you direct control: HTTP status codes, retry logic in your application layer, explicit error branches. For production batch jobs where reliability is the primary concern, REST’s error transparency is an advantage.
MCP delegates error handling to the agent framework and the MCP client implementation. This is fine for interactive agent workflows and most cloud deployments, but for high-volume scheduled batch jobs, direct REST error handling is more predictable.
5. Future-proofing
MCP adoption is expanding rapidly — Claude, ChatGPT, Cursor, and most new agent frameworks are adding MCP support. An MCP integration today works across a widening surface of AI tools without re-integration.
REST is stable and permanent. It will never be deprecated for backend use cases. But connecting new AI tools to REST requires new integration code each time; MCP avoids that overhead.
Side-by-side: four workflow scenarios
Scenario 1: Chat-driven research
A product team asks an agent to investigate churn. The agent discovers create_study and customize_study, collects the research brief, and shows the saved plan for approval. If the user chooses BYOP, it invites an authorized customer list through create_participants. It retrieves interviews and the study report as evidence becomes available.
Scenario 2: Backend batch workflow
A scheduled nightly job creates a pulse-check study (same 5 questions, same target segment, weekly cadence) and exports the prior week’s transcripts to a data warehouse.
Verdict: REST. The workflow is fixed and predictable. REST calls are simpler, the retry logic is in the application layer, and there is no need for schema discovery. Adding MCP would add ceremony without benefit.
Scenario 3: Scheduled studies triggered by product events
When a user downgrades their account, a webhook triggers an automated study to understand the driver. The trigger is a product event; the research workflow is mostly fixed but the participant profile varies by downgrade context.
Verdict: Either, or hybrid. A REST call works if the study parameters are deterministic. An MCP tool call works if the agent needs to make decisions about study design based on the downgrade context. Many teams start with REST for the happy path and add MCP when the workflow grows more context-dependent.
Scenario 4: Intelligence Hub queries
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.
For this scenario, choose between dashboard Hub search and application-managed synthesis of selected reports. Switching from MCP to REST does not add a public Hub search endpoint.
Migration paths
MCP → REST (narrowing down)
Teams sometimes start with MCP for exploration and want to lock down specific operations as deterministic REST calls for production reliability. The path is straightforward: identify the specific tool calls in your MCP workflow, read the equivalent REST endpoint in the API docs, and rewrite those operations as direct HTTP calls. The rest of the MCP workflow continues to work alongside the REST-migrated steps.
REST → MCP (expanding capability)
Teams with existing REST integrations often add MCP when they introduce an AI agent layer that needs dynamic tool selection. The migration is additive: add the MCP server config to your agent framework, verify tool discovery, then rewrite the agent-facing steps as MCP calls. Backend batch jobs that are already working via REST do not need to change.
Hybrid (permanent architecture)
The most mature pattern treats REST and MCP as complementary surfaces rather than alternatives. Interactive, context-driven research runs through the MCP server. Scheduled, deterministic batch operations run via REST. The API key supports REST and local stdio; hosted MCP uses OAuth. The Intelligence Hub accumulates data from both paths.
How does User Intuition handle both protocols?
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.
MCP and CLI study creation deliberately accept metadata, then use Customize Plan for planning and audience setup. The public REST API also supports richer raw configuration and composite operations. Choose the documented contract for your integration instead of assuming exact tool-to-endpoint parity.
Use the hosted endpoint, https://mcp.userintuition.ai/mcp, with OAuth in compatible clients. For local stdio, run npx -y @userintuition-ai/mcp with USERINTUITION_API_KEY set to your ui_sk_ key. The CLI supports browser login and API-key management. Hosted OAuth does not require exchanging a user-supplied API key.
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.
Pick one, get started
If you are building an AI agent that drives research decisions: start with MCP. The tool discovery layer is what makes the agent-driven pattern work at full capability.
If you are building a backend service that runs fixed research operations on a schedule: start with REST. Simpler contract, direct error handling, no overhead.
If you are not sure: start with MCP and note which tool calls are always the same sequence. Migrate those to REST when the workflow stabilizes. The User Intuition agentic research platform and the MCP server docs have everything needed to get the first integration running.