TaskBullet

Delegate task

delegate_task

DestructiveIdempotent

Delegate tasks to a real human virtual assistant when AI cannot act, including phone calls, physical-world steps, subjective QA, or manual data entry. Returns a taskId for tracking.

Instructions

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, owner-authorized login or captcha steps (never send passwords or OTP), physical-world actions, subjective QA, manual data entry, or anything else outside the model's reach. Returns a taskId for tracking. The job is NOT started until the customer clicks Start on Work. The receipt status is awaiting_customer_start.

Input Schema

Name	Required	Description	Default
`title`	Yes	Concise directive (max 5000 chars).
`dueDate`	No	Optional human-readable due date (e.g. EOD Friday).
`maxHours`	No	Spend cap in hours (default 0.5). VA/AM stop and ask before exceeding. Actual tracked time is billed, not this cap. Max 8.
`priority`	No		normal
`webhookUrl`	No	Optional public HTTPS callback URL.
`description`	No	Detailed context, instructions, and constraints (max 8000 chars). Never include passwords, OTP codes, recovery keys, cookies, or API keys.
`sourceAgent`	No	Optional calling-agent label for the audit trail (e.g. grok-bot).
`idempotencyKey`	Yes	Same value as the REST Idempotency-Key header. Required. A repeat returns the original task.

Output Schema

Name	Required	Description
`status`	No	awaiting_customer_start means the customer has not clicked Start on Work. received is a replay after start, a hold, or a sent card.
`taskId`	No	Stable id for get_task.
`message`	No	Human-readable result. Do not claim the VA has started unless the status says so.
`success`	No	True when the brief was filed or replayed.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.2.0Oct 22, 2026

addedInput schema / $schema

Added value: +"http://json-schema.org/draft-07/schema#"

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / description / description

Previous value: -"Detailed context, instructions, and constraints."New value: +"Detailed context, instructions, and constraints (max 8000 chars). Never include passwords, OTP codes, recovery keys, cookies, or API keys."

addedInput schema / properties / description / maxLength
```
Added value: +8000
```

addedInput schema / properties / dueDate

Added value: +{
+  "description": "Optional human-readable due date (e.g. EOD Friday).",
+  "maxLength": 120,
+  "type": "string"
+}

addedInput schema / properties / idempotencyKey

Added value: +{
+  "description": "Same value as the REST Idempotency-Key header. Required. A repeat returns the original task.",
+  "type": "string"
+}

addedInput schema / properties / maxHours

Added value: +{
+  "description": "Spend cap in hours (default 0.5). VA/AM stop and ask before exceeding. Actual tracked time is billed, not this cap. Max 8.",
+  "maximum": 8,
+  "minimum": 0.01,
+  "type": "number"
+}

changedInput schema / properties / priority / enum

Previous value: -[
-  "low",
-  "normal",
-  "high"
-]New value: +[
+  "low",
+  "normal",
+  "high",
+  "urgent"
+]

addedInput schema / properties / sourceAgent

Added value: +{
+  "description": "Optional calling-agent label for the audit trail (e.g. grok-bot).",
+  "maxLength": 80,
+  "type": "string"
+}

changedInput schema / properties / title / description

Previous value: -"Concise directive (max 500 chars)."New value: +"Concise directive (max 5000 chars)."

changedInput schema / properties / title / maxLength
```
Previous value: -500New value: +5000
```

changedInput schema / properties / webhookUrl / description

Previous value: -"Optional HTTPS callback URL."New value: +"Optional public HTTPS callback URL."

changedInput schema / required

Previous value: -[
-  "title"
-]New value: +[
+  "title",
+  "idempotencyKey"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "message": {
+      "description": "Human-readable result. Do not claim the VA has started unless the status says so.",
+      "type": "string"
+    },
+    "status": {
+      "description": "awaiting_customer_start means the customer has not clicked Start on Work. received is a replay after start, a hold, or a sent card.",
+      "type": "string"
+    },
+    "success": {
+      "description": "True when the brief was filed or replayed.",
+      "type": "boolean"
+    },
+    "taskId": {
+      "description": "Stable id for get_task.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedv0.1.1Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true) by disclosing the asynchronous lifecycle: the job is not started until the customer clicks Start, and the receipt status is awaiting_customer_start, plus a taskId is returned. It also adds a spend/confirmation policy and a secrets-handling prohibition that the annotations cannot express.

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?

Dense but nearly waste-free, with each sentence carrying a distinct rule (prerequisite, purpose, use cases, safety, return, lifecycle). It loses a point for leading with the get_balance/confirmation precondition before stating what the tool actually does, which weakens front-loading of the core purpose.

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?

For a complex, destructive, open-world creation tool with an output schema, the description supplies everything needed to invoke it correctly: prerequisites, confirmation policy, scope of use, secret-handling limits, the returned taskId, and the fact that work does not begin until customer activation. Nothing material is missing.

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

Parameters3/5

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

Schema description coverage is 88% and 8 parameters are present, so the schema already documents fields such as maxHours, idempotencyKey, and description in detail. The description only indirectly touches the spend-cap parameter via the get_balance/confirm-for-real-hours guidance and does not explain any parameter format beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb (delegate) and resource (task to a real human VA) and adds the governing condition (when the AI cannot complete it autonomously). This cleanly separates it from siblings like list_tasks, get_task, cancel_task, and place_call, which are retrieval/control operations rather than task creation.

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

Usage Guidelines5/5

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

Gives explicit when-to-use categories (phone calls, owner-authorized login/captcha, physical-world actions, subjective QA, manual data entry) and explicit exclusions (never send passwords or OTP). It also names the prerequisite sequence: call get_balance first, then confirm with the user before sending, unless already authorized.

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

Deploy Server