Skip to main content
Glama

Arroway

Pass unfinished work forward

arroway_pass

Call this when you STOP with the task unfinished — out of time, blocked, or told to stop. It leaves a HANDOFF: the in-flight state of open work, served at the top of every read of this project until someone takes it and closes it. It does not replace the log: a COMPLETED task still ends in arroway_log; this exists for the one you could not complete. ALWAYS write the authored essence too: it is the default in-flight state served in reads. An older, frozen catalog that truly has no essence field may still pass the full state; Arroway marks it as pending a reviewable essence proposal, never as if one had been authored. Deliberate only — never a dump of the session: write exactly what the next session needs to continue without redoing or re-deriving anything. A handoff never expires by clock: it dies in exactly three ways — closed with arroway_close, replaced by another pass naming it as superseded, or discarded by a person in the panel. Age is reported in the read as information; it never removes anything.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cardNoPointer to the living tracker for this work (card id, issue, PR), when one exists.
essenceNoOne authored line that states the operative in-flight state. This is the default read; the full handoff remains recoverable by handle.
projectYes
next_stepYesThe single concrete next step. Not a plan: the step.
open_riskNoThe risk left open — what could bite whoever continues.
supersedesNo#handle of the OPEN handoff this one replaces, from a read. Replacement is explicit by reference, never guessed from titles.
do_not_redoNoWhat is already done, verified or decided that the next session must NOT redo or re-litigate.
addressed_toNoOptional name of a person or routine this is meant for. A visible convention, never a lock: everyone still sees it, and the read says who may take it.
read_handlesNoThe reading list the next session needs: #handles of the memories, log entries and handoffs — of THIS project — that whoever continues must read in full. You know what you had to read to get here; naming it spares them rediscovering it. Order is kept as you write it. At most 10 unique references, and going over is refused rather than trimmed, because each one comes back in full body. Only what is genuinely required to continue: a handle merely cited in do_not_redo is history, not required reading, and is not picked up from the text — it counts only if you name it here.
where_stoppedYesWhere the work stands right now — what is done and verified, what is half-done.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description reveals significant non-obvious behavior beyond the annotations: the handoff is served at the top of every read until closed, it never expires by clock, it dies in exactly three ways, and age is only informational and never auto-removes. It also mandates writing the essence and warns against session dumps. This adds real behavioral context beyond the readOnly/destructive hints.

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?

The description is front-loaded with the trigger condition and is densely informative. It is longer than minimal, but almost every sentence carries a distinct operational rule or constraint needed for correct use. A little tightening is possible, but the length is largely justified by the tool's role as a handoff mechanism with a precise lifecycle.

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

Completeness5/5

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

For a tool with 10 parameters, no output schema, and nuanced lifecycle semantics, the description is remarkably complete. It covers when to call, what the handoff does, how it differs from the log, what the essence requirement is, how handoffs end, and how age is treated. It also gives per-field guidance through the schema such that an agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 90%, the structured schema already documents most parameters well. The description adds higher-level operational semantics, such as essence being the default read, supersedes needing explicit reference, read_handles being required reading (with order and refusal behavior), and do_not_redo preventing wasted rework. It does not redefine parameters but enriches how to choose their values.

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 opens with a specific invocation condition ('Call this when you STOP with the task unfinished') and clearly identifies the resource as a handoff of in-flight work. It distinguishes itself from arroway_log by explicitly stating that completed tasks go to the log, so an agent can immediately tell this tool apart from its closest sibling.

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

Usage Guidelines5/5

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

Usage is explicitly conditional: use it when out of time, blocked, or told to stop, and not for completed tasks, which belong in arroway_log. It also describes the handoff lifecycle—closed by arroway_close, replaced by a superseding pass, or discarded by a person—which helps the agent know when this tool is appropriate versus those siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.