Invoke Human Tool

Send a tap-or-type form

send_html_handoff

Destructive

Create one HTML handoff the person answers by tapping or typing, on an Apple device or in a browser. Pass html, fields, or both. Scripts are removed. fields are text, choice, checkbox, rating, approval, or file. The result is JSON answers, not handwriting. This sends something to a person and cannot be silently undone. Sending again creates a second handoff. An agent key does not receive answer_url.

Input Schema

Name	Required	Description
`due`	No	YYYY-MM-DD or an ISO timestamp.
`html`	No	HTML body. Script, iframes, and event handlers are removed. Inputs with a name are returned as answers.
`mode`	No	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.
`tags`	No
`title`	Yes
`fields`	No
`prompt`	No	Adds a required text field named response when you do not define that field yourself.
`source`	No	Optional session context stored with the handoff and shown on the iPad.
`routing`	No	Same as send_handoff. routing all waits until every answerer submits. The signed link is not a vote for routing all.
`responses`	No	Who sees answers when routing is all. private, the default, shows each person only their own. shared shows every response live, attributed by name.
`from_agent`	Yes	Name of the agent sending the handoff.
`recipients`	No	People who should receive this handoff, besides the signed-in account. Same shape as send_handoff.
`await_answer`	No	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.
`callback_url`	No	Public https URL notified when the handoff is submitted. The body includes answers and answered_by.
`instructions`	No
`default_on_timeout`	No	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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 27, 2026

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"
+}

Changed1 schema field changedOct 27, 2026

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"
+}

First observedOct 27, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Goes well past the destructive/non-idempotent hints: scripts are stripped, delivery to a person 'cannot be silently undone', repeats create new handoffs, and an agent key does not receive answer_url. These are concrete consequences and auth caveats an agent can act on.

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?

Six short sentences, front-loaded with what is created and how to construct it, then the sanitization and irreversibility facts. Dense with little waste; the field-type sentence partially duplicates the schema enum.

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?

For a 16-parameter, deeply nested, no-output-schema tool it covers creation inputs, sanitization, irreversibility and one auth caveat. It does not describe what comes back in sync vs async mode (answers vs handoff id), which is left entirely to the schema's mode description.

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 coverage is 75%, so per-parameter meaning is largely already documented; the description only restates the field type enumeration and the 'answers as JSON keyed by field id' idea. It adds no syntax or format detail beyond what the schema already carries for the 16 parameters.

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

Purpose4/5

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

States a concrete verb and resource — 'Create one HTML handoff the person answers by tapping or typing' — plus the scope of where it renders (Apple device or browser). It differentiates only obliquely from siblings via 'The result is JSON answers, not handwriting', without naming send_handoff or send_ui_handoff, so the boundary is inferable but not stated.

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

Usage Guidelines3/5

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

'Pass html, fields, or both' gives construction guidance and 'Sending again creates a second handoff' warns about repeat invocation. However, nothing states when to pick this over send_handoff or send_ui_handoff, or what prerequisites (recipients, routing) apply, leaving the sibling choice to inference.

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 tools Inspect

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.

Send a tap-or-type form

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources