Skip to main content
Glama
Guitarmaniac24

GetABrain🧠 | Live Human-in-the-Loop MCP for AI Agents

submit_query

Submit structured questions to real human workers for judgment calls, evaluations, or tasks unsuited for AI. Returns a query ID for asynchronous response collection.

Instructions

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, 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesQuestion format/template. 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. Determines the required shape of content_data.
titleYesShort human-readable title for the query, shown to workers as the task headline (5-255 characters).
descriptionNoOptional longer explanation/context shown to workers alongside the title, for extra instructions or background.
content_dataYesType-specific payload whose required fields depend on "type" (e.g. {question, variant_a, variant_b} for ab_test; {question} for yes_no; {question, scale_type, scale_min, scale_max} for rating_scale). See the API docs for the full schema per type.
bid_amount_centsYesCents paid to EACH worker per accepted response (absolute floor 5 = $0.05, max 10000000 = $100,000.00). The REAL minimum is effort-based, not flat: it scales with how long the query type honestly takes a worker to answer, priced at a fair ~$9/hr (0.25 cents/second). Quick types (yes_no, multiple_choice, sentiment, ab_test, headline_test, rating_scale) floor around 5 cents; medium types (image_comparison, image_selection, ranking, text, image_analysis) around 8-12 cents; capture types (voice_capture, photo_capture, custom) around 15 cents; longer types (free_form_text, video_capture) around 30 cents. video_review and audio_review scale with the actual clip length (content_data.video_duration_seconds / audio_duration_seconds) plus a review/write-up overhead, so a 10-minute video review requires roughly $1.65+ -- there is no upper cap, longer clips need proportionally higher bids. Bidding below the type-appropriate minimum is rejected with a 400 telling you the exact floor; call GET /requestor/suggested-bid?type=... for the current min_bid_cents and suggested_bid_cents for a given type before submitting. Total cost = (bid_amount_cents + bonus_amount_cents) * required_responses, deducted from balance in live mode. No charge occurs in test mode.
bonus_amount_centsNoOptional extra cents paid to EACH worker on top of bid_amount_cents per accepted response (default 0). Included in the total cost calculation.
min_worker_qualityNoOptional minimum worker quality score (0-5) required to accept this query; higher restricts to more experienced/reliable workers.
required_responsesYesNumber of distinct human worker responses to collect before the query is considered complete (1-1000).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
statusNo
query_idNo
simulatedNo
total_cost_centsNo
required_responsesNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Exceeds annotations by detailing cost/side effects, balance deduction, test mode, and asynchronous behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Effectively front-loaded with purpose and examples, but slightly long. Structure is clear with logical sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all aspects: usage, parameters, cost, test mode, return behavior, and links to related tools. Adequate for a complex tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds significant context beyond the 100% schema coverage, with examples for content_data types, detailed pricing for bid_amount_cents, and behavior for test mode.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool submits a structured question to human workers for HITL tasks. It distinguishes from sibling tools like get_responses and wait_for_responses by noting it returns immediately and is the entry point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (judgment calls, subjective evaluation, etc.) and provides context on test vs live keys. Could more explicitly state when not to use, but the guidelines are clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Guitarmaniac24/getabrain-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server