Skip to main content
Glama

Hand Off Evidence

handoff_evidence

Transfers approved evidence from a researcher to an analyst after review, using packet ID and destination agent key to complete a verified task handoff.

Instructions

[OPERATOR] Transfer approved evidence from researcher to analyst.

Input Schema

NameRequiredDescriptionDefault
task_idYesTask ID
to_roleYesDestination role (e.g. analyst)
packet_idYesApproved evidence packet ID
review_idYesReview ID that approved it
to_agent_keyYesDestination agent's public key

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Addedv2.8.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already disclose this is a non-read-only, non-idempotent mutation that is not open-world or destructive. The description adds meaningful context by tying the transfer to an approval ('approved evidence') and a destination agent key, but says nothing about what happens on retry (non-idempotent), whether the source agent loses access, or failure modes.

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?

A single front-loaded sentence with the [OPERATOR] tag leading; nothing is redundant. It is efficient, though arguably under-specified rather than lean.

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

Completeness3/5

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

With no output schema, the description should carry more of the behavioral burden for a 5-required-parameter mutation tool, and it does not describe the resulting state or return. It does supply the approval prerequisite and the actor pair, which is the minimum viable coverage.

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 100%, so all five parameters (task_id, packet_id, review_id, to_role, to_agent_key) are already documented in the schema. The description only loosely maps 'researcher to analyst' onto the role parameters and adds no format or constraint detail beyond the schema; baseline 3 applies.

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?

The description names a specific verb ('Transfer') and resource ('approved evidence') and identifies the direction ('from researcher to analyst'), which is clearer than the bare name. It does not, however, explicitly distinguish itself from siblings like submit_evidence, review_evidence, or assign_agent that operate on the same evidence/task domain.

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?

The word 'approved' implies a prerequisite (a review must already have passed, echoed by the required review_id) and 'researcher to analyst' implies role routing. But there is no explicit when-to-use statement, no mention of the alternative tools for moving or assigning work, and no preconditions spelled out.

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

Deploy Server

Other Tools