When to use Human Signal vs. a full Study
The two modes solve different problems. Pick based on the question you’re trying to answer.
Use Human Signal when you have a specific artifact (a tagline, a claim, a button label, two competing options) and you want a number plus a few sentences of “why.”
Use a full Study when you want open-ended discovery, long-form conversation, or multiple linked questions per Participant.
Human Signal is exposed through the API. Over MCP, use the unified Panel-study workflow described below; there is no separate
ask_humans tool. There is no separate Human Signal tab in the dashboard — completed runs appear alongside your other Studies and link to a dashboard URL returned in the response.The three modes
Every Human Signal run has amode that shapes how the question is asked and how Responses are aggregated.
preference
Compare 2-5 options and find out which one people prefer. Requires an
options list. Best for taglines, naming, layouts, value props.claim
Test whether people believe or agree with a single statement. Best for marketing claims, pricing assertions, or positioning lines.
message
Check whether a message is clear and what people think it means. Best for onboarding copy, error messages, or feature descriptions.
Asking a question
Human Signal is invoked through the REST API. From an AI assistant connected to the User Intuition MCP server, use the same supported study and Panel tools as any other research workflow. The legacyask_humans tool is not registered.
- MCP (Panel study)
- REST API
- Dry run
From any MCP-aware client connected to the User Intuition MCP server:Next call
customize_study with the returned study_id and the user’s request—for example, “Learn which of these two taglines resonates more with busy parents and why.” Relay any returned question to the user and send their answer back through customize_study.After get_study confirms the plan is persisted and provisioned, call launch_panel with target: 25, incident_rate: 100, country_code: "US", and dry_run: true. Show the returned cost and timeline, get the user’s approval, then repeat the launch with dry_run: false. Track fieldwork with get_study and list_interviews; once enough Interviews are complete, use generate_report and get_study_report.Key request fields
Getting results back
GET /api/human-signal/{study_id}/results returns the current status and, once available, the structured result.
1
creating
The Study record exists and the AI moderator and Interview script are being generated.
2
queued / fielding
Recruitment and Participant Responses are in flight.
progress.completed ticks up as Responses arrive.3
complete or partial
Fielding finished.
complete means the target n was hit; partial means the time_budget_hours expired before reaching n. Either way, results contains the analyzed output.4
failed or cancelled
The run stopped before producing a usable result.
failure_reason and cost_incurred are populated.results object contains a headline metric appropriate to the mode (e.g. percentage preferring each option), the top reasons Participants gave, and any minority objections. Transcripts are included only when include_transcripts: true was set.
Listing your runs
GET /api/human-signal/ returns a paginated list of your Human Signal Studies, each with a short summary and (for completed runs) a headline_metric. Filter by status and created_after as needed.
Editing and cancelling
Human Signal Studies are editable while they are stillcreating, queued, or fielding.
PATCH /api/human-signal/{study_id} accepts any subset of the original request fields. Note these behaviors:
- Changing content fields (
text,mode,options,context,audience) regenerates the moderation guide in the background. The response setsregenerating: true. - If the Study is already
fieldingand Responses have been collected, you’ll get a warning that earlier Responses were collected under the previous guide and may not be directly comparable. - You cannot reduce
nbelow the number of already-completed Interviews. - Changing
norvoicerecalculatesestimated_cost.
POST /api/human-signal/{study_id}/cancel stops a running Study. Cost incurred so far (based on completed Interviews) is captured and returned as cost_incurred; nothing further is charged.
Expiry and partial results
Every Human Signal run has atime_budget_hours (1-24, default 3). A scheduled job sweeps for Studies whose budget has expired while still fielding. When that happens:
- The Study transitions to
partial. - Whatever Responses have been collected are analyzed and returned in
results. - You are charged only for Interviews that actually completed.
time_budget_hours is safe — you’ll always get something back, even if the panel didn’t fill in time.
Pricing
Human Signal uses the same wallet and credit system as the rest of User Intuition. Cost is computed per completed Participant and depends on:- Whether the run is chat or voice (voice is more expensive)
- Your plan’s effective per-Participant rate
insufficient_credits response with the deficit and a top-up URL — no Study is created and no funds are held. Use dry_run: true to preview the cost first.
For exact rates, see your plan details in the billing settings.
Limits
Next steps
Human Signal over MCP
Use the unified study and Panel tools from an MCP client
Full Studies
For deeper, open-ended research with full Interviews

