Skip to main content
Glama
TheK3nsai

ops-brain

by TheK3nsai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

create_handoff

Send a handoff to another agent as an action item or FYI notification. Use in_reply_to to keep replies in the same thread.

Instructions

Create a handoff for another agent; this is sufficient notification. Category action = the recipient must do it; notify = FYI, pruned from operational queries after 7 days. Replying? Pass in_reply_to to stay in the existing thread instead of opening a parallel handoff.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesDetailed body, markdown supported (max 100,000 bytes)
titleYesShort title for the handoff (max 200 bytes)
contextNoOptional structured context: a JSON object, max 8,192 bytes serialized. Point at evidence (paths, IDs, URLs) instead of inlining it.
categoryNoCategory: "action" (default — persistent until completed) or "notify" (ephemeral FYI, auto-pruned from operational queries after 7 days). Use "notify" for introductions, "I just shipped X" announcements — anything the recipient doesn't need to act on.
priorityNoPriority: low, normal, high, or critical
to_agentNoTarget agent (free-form slug, same form as `from_agent`). Omit to broadcast: the handoff then appears in every other agent's `check_in` until one of them accepts it.
from_agentYesSender agent (free-form slug, 1–80 chars, [a-zA-Z0-9._-]). Examples: "Claude-Laptop", "Codex-Buildbox".
in_reply_toNoParent handoff ID (UUID) when this handoff is a reply to another. Enables threaded discovery via `list_replies_to_me`. The reply's `category` is preserved as written — a reply can legitimately be `action` (it requires a response) or `notify` (pure FYI).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv6.2.0
    • removedInput schema / properties / idempotency_key
      Removed value: -{
-  "description": "Retry key (1–200 bytes), scoped to this sender. Reusing it with the\nsame request returns the original row even after completion; changed\npayloads fail. Keys remain reserved until the handoff is deleted.",
-  "type": [
-    "string",
-    "null"
-  ]
-}
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare non-read-only, non-idempotent, non-destructive writes, and the description adds real value beyond that: 'this is sufficient notification' (no separate notify call needed) and the 7-day pruning of notify-category handoffs. It stops short of describing the return value 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.

Conciseness5/5

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

Three dense clauses, zero filler, with the core purpose front-loaded and the reply-routing tip positioned as the closing actionable instruction.

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 write tool with no output schema, the description covers notification semantics, category persistence, and threading. It omits what the caller gets back (handoff ID) and any error/permission conditions, which is a minor gap given rich annotations and full schema 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 the schema already documents every parameter in detail. The description restates category semantics and adds the threading rationale for in_reply_to, but largely mirrors schema content, so the baseline 3 is appropriate.

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 and resource ('Create a handoff for another agent') and immediately scopes the two behavioral modes (action vs notify). An agent can distinguish this from siblings like accept_handoff or complete_handoff without inspecting schemas.

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?

Gives explicit when-to-use guidance for the two categories and, crucially, routes replies: 'Replying? Pass in_reply_to to stay in the existing thread instead of opening a parallel handoff' names the alternative behavior. It does not clarify when to prefer this over add_knowledge or other siblings, so it falls short of full alternative coverage.

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