Skip to main content
Glama

Invoke Human Tool

by com.invokehumantool
OverviewDiscussionsAdmin

Send a handoff

send_handoff
Destructive

Create one worksheet, form, approval, review, or sketch for the signed-in person. They write or draw on an Apple device. You get a filled PDF later. This sends something to a person and cannot be silently undone. It does not wait, and sending again creates a second handoff. Pass source so the device can show which session sent it.

Input Schema

NameRequiredDescriptionDefault
dueNoYYYY-MM-DD or an ISO timestamp.
htmlNoHTML body for type html. Scripts are removed. Named inputs become answer fields.
modeNosync waits for an answer. On a Tasks client that returns a task. async returns the handoff id. Default async. mode wins over await_answer.
tagsNo
typeNoDefaults to worksheet. Use html, or send_html_handoff, for tap and type answers. Use ui, or send_ui_handoff, for a HUI 0.1 document.
titleYes
fieldsNoStructured controls for type html.
promptNoQuestion or request when not sending markdown or problems. For type html, this becomes a required text field.
sourceNoOptional session context stored with the handoff and shown on the iPad.
routingNoowner: the sending account answers. first: the first recipient to submit wins. all: every answerer must submit. Defaults to first when a recipient can answer, otherwise owner.
markdownNo
problemsNo
questionNo
responsesNoWho sees answers when routing is all. private, the default, shows each person only their own. shared shows every response live, attributed by name.
from_agentYesName of the agent sending the handoff.
recipientsNoPeople who should receive this handoff, besides the signed-in account. Each entry targets user_id, email, handle, group, team, or group_id. They must accept before they can read it.
await_answerNoLegacy alias for mode sync. mode wins when both are set. When this client declares the MCP Tasks extension, true returns a task and the client delivers the same JSON as get_handoff_result once they submit. Omit it to get the handoff id immediately. Clients that do not declare Tasks ignore this flag.
callback_urlNoPublic https URL notified when the handoff is submitted.
instructionsNo
default_on_timeoutNoAnswers to record when due passes and the person has not tapped. The receipt says the system answered. A pay, send, delete, publish, or sign step is not defaulted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / await_answer / description
      Previous value: -"Set true to wait for the human's answer. When this client declares the MCP Tasks extension, the call returns a task and the client delivers the same JSON as get_handoff_result once they submit. Omit it, or pass false, to get the handoff id immediately and keep working. Clients that do not declare Tasks ignore this flag and return the handoff id, same as today."New value: +"Legacy alias for mode sync. mode wins when both are set. When this client declares the MCP Tasks extension, true returns a task and the client delivers the same JSON as get_handoff_result once they submit. Omit it to get the handoff id immediately. Clients that do not declare Tasks ignore this flag."
    • addedInput schema / properties / default_on_timeout
      Added value: +{
+  "description": "Answers to record when due passes and the person has not tapped. The receipt says the system answered. A pay, send, delete, publish, or sign step is not defaulted.",
+  "type": "object"
+}
    • addedInput schema / properties / mode
      Added value: +{
+  "description": "sync waits for an answer. On a Tasks client that returns a task. async returns the handoff id. Default async. mode wins over await_answer.",
+  "enum": [
+    "sync",
+    "async"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / responses
      Added value: +{
+  "description": "Who sees answers when routing is all. private, the default, shows each person only their own. shared shows every response live, attributed by name.",
+  "enum": [
+    "private",
+    "shared"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / await_answer
      Added value: +{
+  "description": "Set true to wait for the human's answer. When this client declares the MCP Tasks extension, the call returns a task and the client delivers the same JSON as get_handoff_result once they submit. Omit it, or pass false, to get the handoff id immediately and keep working. Clients that do not declare Tasks ignore this flag and return the handoff id, same as today.",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

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

The description goes beyond annotations by explicitly stating the non-reversibility ('cannot be silently undone') and the operational nature of the tool (non-blocking submission), which are critical behavioral traits.

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

Conciseness3/5

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

The description is functional and hits all necessary points but is slightly wordy and lacks punch. It is adequately sized but does not feel highly refined or front-loaded.

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

Completeness4/5

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

Given the high number of parameters (20) and the absence of an output schema, the description successfully provides the conceptual framework (what kind of digital object is created and how it functions on a device) to assist the agent.

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?

The schema coverage is 70%, setting a baseline of 3. The description supports this by defining the high-level use of the `source` object (providing session context for the device) and the general creation flow.

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?

The description clearly identifies the core actions (create worksheet, form, approval, review, or sketch) and the resulting output (filled PDF). This specific resource creation differentiates it from related functions like data retrieval or delegation.

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?

It provides clear constraints: the operation is non-blocking ('It does not wait'), and it addresses the implications of repetitive use ('sending again creates a second handoff'). It also advises on the necessity of providing context ('Pass source...').

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

All Invoke Human Tool toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources