MCP server for AI agent → human virtual assistant handoff. When your AI agent hits a task it can't complete (phone calls, 2FA-gated logins, physical-world actions, subjective QA), delegate it to a real human VA via the TaskBullet Agent API.
A Model Context Protocol server that gives any MCP-compatible AI client (Claude Desktop, Claude Code, Cursor, Continue, etc.) native tools to delegate tasks to a real human virtual assistant.
LLMs are brilliant at thinking. They are useless at:
Making phone calls
Logging into 2FA / captcha-gated portals
Subjective quality review ("does this look good?")
Physical-world actions (mail, deliveries, in-person errands)
Long-tail manual data entry
This server bridges that gap. Call get_balance first, confirm spend, then delegate_task — a TaskBullet virtual assistant picks it up.
Grok / Cursor / cloud agents: use the hosted MCP instead of this npx package. Cloud bots cannot run npx.
https://taskbullet.com/api/agent-mcp
Header: x-api-key: tb_live_… (API key only — not OAuth). Same four tools as below.
Related MCP server: humanrail-mcp-server
Tool | Description |
| Remaining hours and whether |
| Send a new task to a human virtual assistant. Returns a |
| List recently delegated tasks, optionally filtered by status. |
| Poll the status and result of a specific task by |
There is no cancel_task yet.
You need a TaskBullet account and an API key.
Sign up / log in at taskbullet.com
Generate an API key at taskbullet.com/dashboard/settings/api-keys
Wire up the server in your MCP client config (see below), or point Grok/Cursor at the hosted URL above.
Edit claude_desktop_config.json (location varies by OS — see Anthropic's docs):
{
"mcpServers": {
"taskbullet": {
"command": "npx",
"args": ["-y", "@taskbullet/mcp-server"],
"env": {
"TASKBULLET_API_KEY": "tb_live_your_key_here"
}
}
}
}Restart Claude Desktop. You'll see the TaskBullet tools appear in the tools panel.
Any client that supports MCP servers via stdio will work. Point it at:
command: npx
args: -y @taskbullet/mcp-server
env: TASKBULLET_API_KEY=tb_live_...For LangChain, CrewAI, AutoGen, or custom orchestration, you can either:
Use this MCP server directly via an MCP client library, OR
Call the underlying TaskBullet REST API (or the OpenAPI spec) directly.
You: Find me a flight from SFO to Austin next Tuesday under $300. If you can't book it directly, have someone book it for me.
Claude: I found a Delta flight at 8:15 AM for $278 but it requires phone booking due to a fare class restriction. Let me delegate the booking to your TaskBullet assistant.
[calls
delegate_taskwith title: "Book Delta DL1423 SFO→AUS Tue Jun 3, 8:15 AM, $278. Use my saved AmEx ending 4321. Email confirmation to me."]Booked task
atask_a3f9c2d1. Your assistant will pick this up and you'll get an email when it's confirmed.
Variable | Required | Default | Purpose |
| ✅ | — | Your |
| ❌ |
| Override for self-hosted or staging |
| ❌ |
| Audit label for which agent originated the request |
You have two options:
Poll — your agent calls get_task periodically until status === "completed".
Webhook — pass webhookUrl to delegate_task and TaskBullet POSTs a signed payload when the VA finishes. (See the webhook docs.)
You pre-purchase a Bucket of Hours (no monthly retainer).
Hours roll over for 90 days so bursty AI workloads don't waste capacity.
Tasks delegated through this MCP server route to your matched, dedicated virtual assistant.
You only spend bucket hours when the VA is actually working on a delegated task — the API itself is free.
Learn more at taskbullet.com.
MIT — see LICENSE.
Keywords: mcp server, model context protocol, claude, anthropic, ai agent handoff, human-in-the-loop, virtual assistant, AI delegation, autonomous agent, llm tools, agentic workflow
Call get_balance first, then confirm with the user before sending (real hours) unless they already said to send it. Delegate a task to a real human virtual assistant when the AI cannot complete it autonomously. Use this for phone calls, 2FA-gated logins, physical-world actions, subjective QA, manual data entry, or anything else outside the model's reach. Returns a taskId for tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Concise directive (max 500 chars). | |
| priority | No | normal | |
| webhookUrl | No | Optional HTTPS callback URL. | |
| description | No | Detailed context, instructions, and constraints. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers key behavioral context: the operation consumes real billable hours and requires user confirmation unless pre-authorized. It also discloses the return value (taskId for tracking). It stops short of stating cancellation, failure, or turnaround behavior for a real-world action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no filler, and the cost/confirmation prerequisite is front-loaded. Slight structural awkwardness in leading with the workflow instruction before stating what the tool actually does, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation with no output schema and no annotations, the description covers purpose, selection criteria, cost, prerequisite workflow, and the returned identifier. Remaining gaps (expected content of the description field, cost magnitude, failure handling) are minor but real.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents title, webhookUrl, and description; the description adds no field-level syntax or format guidance. Baseline 3 is appropriate given the schema does the heavy lifting and priority's enum is left unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Delegate a task to a real human virtual assistant') plus the scope condition ('when the AI cannot complete it autonomously'). The concrete examples (phone calls, 2FA-gated logins, physical-world actions) make it unmistakable against siblings get_balance, list_tasks, and get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use enumeration plus a named alternative in the workflow: 'Call get_balance first, then confirm with the user before sending... unless they already said to send it.' The exclusion/exception condition is spelled out rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return remaining VA hours on this account and whether delegate_task will be accepted. Call this before proposing spend. Does not create a task.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose behavior beyond the name: it is non-mutating ('Does not create a task') and it predicts whether delegate_task will be accepted, which is non-obvious gating semantics. It omits auth/rate-limit considerations, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the return value, then the usage trigger, then the negative scope. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with no output schema, the description names both returned values (hours remaining, acceptance status) and clarifies it is non-mutating — enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters and 100% schema coverage, so the 4-baseline applies; there is no parameter meaning for the description to add or omit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return') and the exact resources ('remaining VA hours', whether delegate_task will be accepted). The reference to delegate_task distinguishes it from the sibling list by showing its role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this before proposing spend' is an explicit precondition telling the agent when to invoke it. It does not name an alternative read tool (list_tasks/get_task) or state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status, completion timestamp, and result notes for a specific delegated task.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | The taskId returned by delegate_task. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Get' correctly signals a read-only operation and it discloses the returned fields, but it says nothing about behavior for unknown/expired taskIds, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb, scope, and return contents in order and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully summarizes the return payload (status, completion timestamp, result notes), which is what an agent needs to interpret results. It falls short only on not-found/error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already explains that taskId is the value returned by delegate_task, so the description adds no parameter detail beyond the structured field. Baseline 3 applies for a single fully documented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (get) and resource (a specific delegated task) and enumerates what is returned: current status, completion timestamp, and result notes. This clearly separates it from list_tasks (plural listing) and delegate_task (creation), though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'a specific delegated task' and the schema note that taskId comes from delegate_task suggest polling a task after delegation. There is no explicit statement of when to use this versus list_tasks, nor any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recently delegated tasks for this account, optionally filtered by status. Use to check progress on prior delegations.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. "Recently" hints at a bounded result window, but it says nothing about how many tasks are returned, pagination, ordering, or permissions — the agent cannot predict the response shape from this text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resource and scope followed immediately by the use case. No filler, though the second sentence could have been folded into the first without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter read tool with no output schema and no annotations, the description covers the basic contract but leaves result volume, ordering, and pagination unspecified — details an agent would need to use the list sensibly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description has to compensate. It does say the status filter is optional and that filtering is by status, and the enum values are self-documenting, but it adds no meaning about "all" versus a specific status beyond the default already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List ... delegated tasks") plus the scope of the listing ("recently ... for this account"). It clearly implies a collection read, but never names the sibling get_task as the singular-lookup alternative, so sibling differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use to check progress on prior delegations" gives a concrete reason to call it, which is better than nothing. However, there is no when-not guidance, no mention of get_task for a single task, and no prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1delegate_taskget_balanceget_tasklist_tasksScored across 4 tools
Each tool targets a distinct action: checking balance, creating a delegation, listing tasks, and retrieving one task. There is no meaningful overlap; list_tasks and get_task are clearly differentiated by collection vs. single item.
All tool names follow a consistent snake_case verb_noun pattern: get_balance, delegate_task, list_tasks, get_task. The pattern is predictable and easy to scan.
Four tools are well-scoped for a focused delegation service. Each tool serves a clear purpose in the workflow: precheck, create, list, and inspect.
The core lifecycle is covered: check balance, delegate a task, list tasks, and get task details. Minor gaps like canceling or updating a delegated task are absent, but agents can work around them for most workflows.
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
Human-in-the-loop API for AI agents. CAPTCHA, OTP, KYC, and approvals by real humans.
Hand phone calls to vetted humans. Agents create call tasks; people dial and report outcomes.
Lets AI agents use a real human as a tool: visual checks, taste, phone calls, unblocking, approvals
