Three ways into the same infrastructure. Here is what each one does, who it is for, and how they work together.
Product Overview · August 2026
Start here
Rally is one system: your participant CRM, your study templates, your consent records, your governance rules, your incentive rails, your audit trail. That system does not change based on how you reach it. What changes is who is doing the reaching.
The one-line version
A direct, programmatic way for your own systems to read and write data in Rally. Your developers decide exactly what gets called and when.
Connects Rally to the AI tools your team already uses, like Claude, so the AI can pull research data and take actions in Rally on your behalf, deciding which steps to take based on your instructions.
Rally's built-in Research Ops Agent that runs research work for you: setting up studies, managing recruiting, and handling day-to-day research tasks through conversation.
Side by side
API |
MCP |
Agent |
|
|---|---|---|---|
| Who it's for | Engineers and data teams, building to a spec that Research Architects define | Product builders and researchers working inside their own AI tools. Research Architects wire it into shared team workflows | Product builders and researchers who need a study without learning your process. Research Architects set the rails everyone runs inside |
| Where it runs | Your infrastructure, calling Rally | Claude, ChatGPT, Cursor, Figma, Notion, Linear, or your own internal tooling | The Rally Agent Command Center inside the Rally platform, or through the Rally Slackbot |
| How it behaves | Deterministic. The same request returns the same result every time | Composable. You direct it, and it chooses which Rally tool calls to make at each step | Guided. It builds the study from your approved templates and walks you through approvals |
| Setup | Generate an API key in workspace settings, then build the integration | Connect in under 5 minutes from the help center instructions | Ask your CSM to enable your workspace for the beta |
| Strongest at | Panel sync, compliance exports, event-driven integration, reporting pipelines | Recruitment and study management as one step inside a larger workflow you designed | End-to-end study execution for someone who has never built a study |
How they fit together
They sit on the same foundation and do different jobs.
Your CRM or data warehouse is the source of truth for who your users are. The API mirrors that into Rally on a schedule, so the panel you recruit from reflects reality rather than a CSV someone exported in March.
Exposes recruitment, study management, screening, scheduling, and incentive tool calls to any MCP-compatible AI tool, with your governance applied on every call.
Lives in the Rally Agent Command Center, a focused workspace built for product builders, and in Slack through the Rally Slackbot. The fastest path for teams who want an agent rather than a set of tools to build with.
Participant CRM, governance rules, consent management, study templates, permissions, incentive rails, audit trail. Every other surface reaches this same system.
The pattern we see at scale: the API keeps the panel current, and the MCP and Agent recruit against it.
Why ours is different
Many MCP servers are built the same way: wrap an existing API with tool calls and ship as many as possible. The result is a long list of capabilities that are technically functional but shallow in practice. Agents can call them, but they cannot do much with them.
Tool calls mirror API endpoints one for one. A recruitment call returns a list of people. Whether those people are in cooldown, whether consent is current, and whether this person is allowed to contact them are all questions left for the researcher to answer, or left unanswered.
When you build for agents rather than for API coverage, you invest differently. Individual tool calls get deeper. They carry more context, enforce more rules, and handle more of the workflow autonomously so the researcher does not have to fill in the gaps.
A tool call that recruits participants does not just pull a list. It checks eligibility, applies cooldown windows, validates consent status, and enforces the criteria your Research Ops team configured in Rally before a single invitation goes out.
That is where our investment goes. Not into the number of tool calls, but into how much each one can actually do. The result is a focused set of tools built specifically around recruitment and governance, the two areas where research programs most often break down and where the consequences of getting it wrong are highest.
Read the full tool call reference at rallyuxr.com/post/rally-mcp-tool-calls-explained
Governance
Read this section closely if you are the person who signs off on research access. These controls are properties of Rally Research, not features of any one surface, so they apply the same way whether the request came from a script, an AI tool, or the Agent.
Cooldown windows, opt-out and consent status, and the criteria your Research Ops team configured are all checked before a single invitation goes out. A person in cooldown is not surfaced as an option to skip past. They are not reachable.
Approved study templates bring your consent language, incentive rules, and interview structure with them. Someone who has never run a study inherits your standards without needing to know they exist.
Role-based access carries over from Rally. If a product manager cannot launch a paid external panel or set an incentive amount in Rally, that option is not available to them through the MCP or the Agent either.
Recruitment sends in batches rather than contacting everyone who matches. A study that needs 8 participants does not invite 300 people to get them.
Proposed sends and a study's first round hold for approval in Rally. If nobody approves, nothing sends.
Starting paid external-panel recruitment requires confirming on Rally's cost sheet. Reviewing a quote does not reserve funds or notify the panel provider. The Agent can propose spend. It cannot commit it.
Each participant record carries a governance activity feed: when their contact status changed, who changed it, and why. When product builders run their own research, that history lives inside Rally for legal and compliance review.
The agent does not draw the line. You do.
What each one covers
check_recruiting_feasibility tells you
whether an audience is reachable from your panel and recommends a route: recruit from the
panel, import a list, or use a paid external panel. Teams use this to choose a recruitment
approach before building anything.One boundary worth stating plainly: recruitment orchestration, outreach campaigns, external panel workflows, and live scheduling are MCP and Agent capabilities. They are not in the API. If the question is whether recruitment can be automated through the API alone, the answer is no.
Customer stories
| Customer | What they're doing | Surface |
|---|---|---|
| Ramp | Hands off an audience and the agent runs recruitment through to incentives, invoked from Slack or Claude with progressive approval at each step. They describe what they want as a research ops secretary inside their community of agents. | Agent + MCP |
| Figma | Runs full end-to-end studies inside their own Claude instance, using their own tooling to source users and Rally MCP to import and launch. | MCP |
| Procore | PMs and designers describe project scope and the agent builds the study. Ops builds reporting dashboards on top. | Agent |
| Accelerant | Queries their product analytics MCP to find an audience that never lived in Rally, then hands it to Rally Agent to build and launch. Runs a weekly automated research digest into Slack. | MCP-led |
| Twilio | Screener generation on tenure and usage questions, plus automated incentive reminders replacing manual ops work. | Agent |
| Perplexity | Recruits through the MCP with a browser fallback, pushing hard on quota and scheduling behavior. | MCP |
| Blackbaud | Checks how many people are likely to qualify before a study kicks off, so teams choose their recruitment approach with real numbers rather than assumptions. | MCP |
FAQs
The API covers people, studies, screeners, incentives, and reporting. It does not cover recruitment orchestration, outreach campaigns, external panel workflows, or live scheduling. To build agentic recruitment on the API, you would need to construct those yourself, along with cooldown enforcement, consent validation, eligibility checks, template locking, approval gates, and batched sending. The MCP is that work, already built and maintained.
No. Most research MCPs are built by wrapping an existing API and shipping
as many tool calls as possible, which produces a long list of shallow capabilities. Rally MCP
tool calls do more per call. check_recruiting_feasibility returns a routing
recommendation, not a row count. A recruitment call checks eligibility, applies cooldown
windows, validates consent, and enforces your Research Ops criteria before any invitation
goes out. That logic is not in the API surface.
They serve different needs and most teams end up with both. The Agent covers the standard shape of a study for someone who does not want to design a workflow, and it runs in the Rally Command Center and Slack. The MCP is what you use when the audience lives in another system, when recruitment is one step in a chain you built, or when your team works in Claude or Cursor and will not switch surfaces to run research.
Several controls, and they stack. Eligibility rules make people in cooldown unreachable rather than skippable. Outreach sends in waves and holds the first round for approval in Rally. Paid external panel spend requires confirmation on Rally's cost sheet.
Underneath all of that, you decide what a product builder can reach in the first place. Custom roles and permissions control which areas of Rally each person can access and which actions they can take, including whether they can send incentives or use a paid external panel. You can also lock individual areas of a study template so they cannot be edited, such as the incentive amount and the consent form. A builder working from a locked template inherits those decisions and cannot change them, whether they are in Rally, the MCP, or the Agent.
Every participant record carries a governance activity feed showing contact status changes, who made them, and why. Research run through the Agent or MCP produces the same trail as research run by hand in Rally, because it is the same system. Rally is SOC 2 Type II audited annually, supports GDPR and CCPA requirements, enables HIPAA compliance through zero-retention LLM APIs, and holds contractual agreements with every AI subprocessor prohibiting use of customer data for model training.
Same infrastructure, same permission model, same audit trail across all three. The MCP and Agent act as the person using them and inherit that person's role. The API authenticates with a workspace-level key, so scope who holds it deliberately. Generating an API key requires a Developer or Admin role.
Their own. Rally MCP works with Claude, ChatGPT, Cursor, and any MCP-compatible platform, and connects with research tools like Maze, Ballpark, Outset, and Listen Labs so participants can be managed across study types without switching context.
MCP connection takes under five minutes with a Rally workspace. Agent beta access takes a request to your CSM. The API takes as long as your integration work requires, which for a scheduled panel sync is typically a short project.
No. Rally holds contractual agreements with every AI subprocessor prohibiting the use of customer data to train models. Your participants, studies, and findings stay yours.
Connect Rally MCP in under five minutes from the help center, or ask your CSM to enable Rally Agent beta on your workspace.
Book a demo at rallyuxr.com/demo to see governance running across a live recruitment workflow.