Hand off work to another agent by generating a graph-bound receipt that proves continuation for a given workstream. Specify the receiving agent and workstream ID to create the handoff record.
Create a graph-bound handoff receipt and complete continuation proof.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| to_agent | Yes | ||
| from_agent | Yes | ||
| workstream_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.62Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates side effects (creating a receipt and completing a proof) but does not clarify whether a graph write occurs, whether the operation is destructive, what 'continuation proof' entails, or whether the tool is idempotent.
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?
The description is a single, short sentence with no filler or repetition. It front-loads the core action. The cryptic 'complete continuation proof' phrase reduces clarity but does not make the description bloated.
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 four parameters, three required, no annotations, and many closely related sibling tools, this description is too minimal to be complete. It does not explain what a handoff receipt is used for, when continuation proof is needed, or how this relates semantically to work_resume or create_context_receipt. The presence of an output schema helps return-value understanding but not invocation decisions.
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%, and the description does not mention any of the four parameters. The parameter names from_agent, to_agent, and workstream_id are fairly self-explanatory, but the meaning of 'project' with a default empty string and the expected format of each value are left completely unspecified.
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?
The description uses a specific verb 'Create' and identifies a concrete resource: a 'graph-bound handoff receipt'. This clearly distinguishes the tool from siblings like work_claim or work_resume by naming the handoff artifact. However, the phrase 'complete continuation proof' is unexplained jargon, preventing a perfect 5.
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?
The description offers no guidance on when to use this tool, when not to use it, or which alternatives might be more appropriate. With a large sibling set that includes create_context_receipt, work_claim, and work_resume, the agent is left to infer the exact handoff scenario from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.