GetABrain.ai

Give your AI agent access to real human judgment with our Human-in-the-Loop MCP Server.

CommunityOnlineAPI key requiredGlobalFreeCan modify data

What it can do

  • Get Balance: Check the prepaid balance (in cents) available to fund submit_query calls, plus account mode. Call before submit_query if unsure funds suffice, or whenever a query fails/stalls for balanc
  • Create Topup Link: Generate a one-time Stripe Checkout URL for adding funds to the prepaid balance. Use when get_balance shows insufficient funds for an upcoming submit_query, or a human asks to add m
  • Submit Query: Submit a structured question to real human workers, returning a query_id -- the entry point for any human-in-the-loop (HITL) step: judgment calls, subjective evaluation, approval/review,

What data it sees

Do you need an account

An API key from the service settings is required

Give your AI agent access to real human judgment with our Human-in-the-Loop MCP Server.

When your agent encounters a question it cannot answer reliably, it sends the request to a real pool of humans and receives a structured response back.

Ideal for:

  • Judgment calls and subjective ratings
  • Real-world and local knowledge
  • Image and audio review
  • Quality checks and human verification
  • Tasks where accuracy matters more than guessing

Includes 7 MCP tools, a free sandbox mode for testing, and simple pay-per-answer pricing when you go live.

Works with Claude Desktop, Cursor, and any MCP-compatible client.

Server tool list (7)

Raw names from tools/list. Only developers need these.

get_balanceCheck the prepaid balance (in cents) available to fund submit_query calls, plus account mode. Call before submit_query if unsure funds suffice, or whenever a query fails/stalls for balance reasons. Read-only, no side effects, free in test and live mode. Response includes mode ("test" = sandbox key, free simulated responses; "live" = real key, real spend), and when relevant whether auto_reload is on, plus an auto_reload_setup_url + hint to enable it so a live account does not stall at zero balance. Disambiguation: reports funds available to spend; does not list queries (list_queries) or responses (get_responses/wait_for_responses).
create_topup_linkGenerate a one-time Stripe Checkout URL for adding funds to the prepaid balance. Use when get_balance shows insufficient funds for an upcoming submit_query, or a human asks to add money. Side effect: creates a pending Stripe session (no charge yet); the returned checkout_url must be OPENED IN A BROWSER BY A HUMAN to enter payment details and complete the charge -- the agent cannot complete payment itself; this is an out-of-band, human-in-the-loop step. Works with a test-mode or live-mode key (funding a test-mode account is how you move a sandbox integration to real spending power). Balance updates only after checkout completes; poll get_balance to confirm. Disambiguation: only mints a payment link -- never moves money or blocks waiting for payment itself.
submit_querySubmit a structured question to real human workers, returning a query_id -- the entry point for any human-in-the-loop (HITL) step: judgment calls, subjective evaluation, approval/review, or "ask a real person" tasks a model should not answer itself. "type" selects the question format (one of: text, multiple_choice, rating_scale, image_comparison, ranking, yes_no, sentiment, image_selection, free_form_text, video_review, audio_review, image_analysis, ab_test, voice_capture, video_capture, photo_capture); "content_data" is the matching type-specific payload (e.g. ab_test: {question, variant_a:{description}, variant_b:{description}}; yes_no: {question}; rating_scale: {question, scale_type, scale_min, scale_max}). Cost/side effects: with a LIVE key this deducts (bid_amount_cents + bonus_amount_cents) * required_responses from balance immediately and dispatches to paid workers (fails if balance too low -- check get_balance or use create_topup_link). With a TEST key, no balance is touched and responses are synthetic, marked simulated: true, so you can build/test a full pipeline for free before going live. Returns immediately, does not wait -- use get_responses (one-shot) or wait_for_responses (bounded polling) to retrieve answers.
get_responsesOne-shot read: fetch a query's current status and whatever human responses have been submitted so far, without waiting. Use this to check progress on demand, or after wait_for_responses reports "pending" if you want an immediate snapshot instead of polling again. Read-only, no cost, returns instantly (does not block or retry). Disambiguation: unlike wait_for_responses, this never delays or blocks waiting for more answers to arrive -- it just reports what exists right now, which may be fewer than required_responses.
wait_for_responsesPoll for human responses to a query, blocking for up to max_wait_seconds (default 50, max 50) before returning. Use right after submit_query to wait for real answers in one call instead of manually re-checking with get_responses. DOES NOT GUARANTEE COMPLETION -- if min_responses have not arrived within the time budget it returns status "pending" (with a hint to call again) rather than erroring; call again to keep waiting. Returns status "ready" with the responses array once enough have arrived (or the query otherwise completed). Read-only / free -- cost was already charged by submit_query. Disambiguation: unlike get_responses (instant, one-shot, may return 0 responses), this actively waits, trading time for a higher chance of a complete result.
list_queriesList your recent GetABrain queries, most recent first. Use this to get an overview of past/active queries, recover a query_id you lost track of, or filter by status (e.g. find everything still "active" or "pending"). Read-only, no cost. Disambiguation: this lists MANY queries at a summary level; it does not return the individual worker responses for any one query -- use get_responses or wait_for_responses with a specific query_id for that.
rate_responseRate a single worker's response 1-5 to feed the worker quality/reputation system, optionally with free-text feedback. Use after reviewing a response from get_responses/wait_for_responses, to reward good answers and flag poor ones -- this affects the worker's quality score and future eligibility (e.g. queries with min_worker_quality set) and can trigger rewards/suspension server-side. Side effect: writes a rating record and returns the updated worker quality score; does not resubmit or modify the original response. Disambiguation: rates a response you already have -- does not fetch new responses (use get_responses/wait_for_responses first).