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 can then select tools based on context: “I need to run a study, so I’ll call create_assistant and then create_invite.” The tool selection is driven by the agent’s reasoning over the manifest, not by hard-coded application logic. This is the core value proposition of MCP for research workflows — the agent knows what operations are available and can compose them into a workflow without explicit scripting.
The User Intuition MCP server exposes 72 tools across 9 capability 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 uses Claude to run customer research from a conversation — “Ask 20 customers why they churned last quarter.” Claude calls ask_humans, create_assistant, create_invite, and eventually analyze_transcripts based on context.
Verdict: MCP. The agent needs schema discovery to compose the multi-step workflow. Hard-coding these steps as REST calls would require building custom orchestration logic that MCP provides for free.
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
An AI assistant answers internal product questions by calling query_intelligence over accumulated research. “What did customers say about the onboarding flow in Q1?” The assistant decides whether to query the Intelligence Hub or commission new research based on the question.
Verdict: MCP. The decision logic (query existing data vs. run new fieldwork) is context-dependent. MCP lets the agent make that decision using the tool manifest. A REST-only implementation requires the developer to pre-define the routing rules.
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 same API key authenticates both. The Intelligence Hub accumulates data from both paths.
How does User Intuition handle both protocols?
User Intuition ships both surfaces as first-class citizens. The MCP server (@userintuition-ai/mcp v0.2.5) wraps the same REST API at https://api.userintuition.ai, so capabilities are identical across both. The choice of protocol is an integration architecture decision, not a capability tradeoff.
For MCP integrations: the server exposes 72 tools across 9 groups. Three proof points relevant to the MCP-vs-REST decision — query_intelligence in the Intelligence Hub group is the clearest MCP-specific win (the agent selects this tool based on question context rather than a developer pre-specifying it); bulk_create_invites_from_segment is a powerful REST call for batch participant enrollment where the segment is already known; and the Streamable HTTP transport at https://mcp.userintuition.ai/mcp supports cloud agent deployments that cannot run a local subprocess.
For REST integrations: the API reference at docs.userintuition.ai includes the OpenAPI spec. Core endpoint groups — assistants, calls, invites — cover the main research workflow. Authentication is the same ui_sk_ key used for MCP.
Both surfaces are documented alongside each other in the agentic research platform docs. Teams can start with either path and migrate or combine as their architecture evolves.
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.