Arroway

Pass unfinished work forward

arroway_pass

Call when you STOP with the task unfinished (out of time, blocked, told to stop): it leaves a HANDOFF served at the top of every read until someone closes it; a completed task ends in arroway_log instead. ALWAYS write the authored essence (only a frozen catalog without that field may omit it). Write what the next session needs to continue, never a dump.

Input Schema

TableJSON Schema

Name	Required	Description
`card`	No	Card, issue or PR, when one exists.
`essence`	No	One authored line with the operative in-flight state.
`project`	Yes	Project slug.
`next_step`	Yes	The single concrete next step. Not a plan: the step.
`open_risk`	No	The risk left open.
`supersedes`	No	#handle of the OPEN handoff this one replaces, from a read.
`do_not_redo`	No	What must NOT be redone or re-litigated.
`addressed_to`	No	Optional person or routine it is meant for; never a lock.
`read_handles`	No	The reading list: #handles of THIS project the next session must read in full, in order. Only what is required.
`where_stopped`	Yes	What is done and verified, what is half-done.

Schema Changelog

Changes observed during successful MCP inspections.

Changed28 schema fields changedOct 7, 2026

changedInput schema / properties / addressed_to / description

Previous value: -"Optional 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."New value: +"Optional person or routine it is meant for; never a lock."

removedInput schema / properties / addressed_to / maxLength
```
Removed value: -4096
```
removedInput schema / properties / addressed_to / minLength
```
Removed value: -1
```

changedInput schema / properties / card / description

Previous value: -"Pointer to the living tracker for this work (card id, issue, PR), when one exists."New value: +"Card, issue or PR, when one exists."

removedInput schema / properties / card / maxLength
```
Removed value: -4096
```
removedInput schema / properties / card / minLength
```
Removed value: -1
```

changedInput schema / properties / do_not_redo / description

Previous value: -"What is already done, verified or decided that the next session must NOT redo or re-litigate."New value: +"What must NOT be redone or re-litigated."

removedInput schema / properties / do_not_redo / maxLength
```
Removed value: -4096
```
removedInput schema / properties / do_not_redo / minLength
```
Removed value: -1
```

changedInput schema / properties / essence / description

Previous value: -"One authored line that states the operative in-flight state. This is the default read; the full handoff remains recoverable by handle."New value: +"One authored line with the operative in-flight state."

removedInput schema / properties / essence / minLength
```
Removed value: -1
```
removedInput schema / properties / next_step / maxLength
```
Removed value: -4096
```
removedInput schema / properties / next_step / minLength
```
Removed value: -1
```

changedInput schema / properties / open_risk / description

Previous value: -"The risk left open — what could bite whoever continues."New value: +"The risk left open."

removedInput schema / properties / open_risk / maxLength
```
Removed value: -4096
```
removedInput schema / properties / open_risk / minLength
```
Removed value: -1
```
addedInput schema / properties / project / description
```
Added value: +"Project slug."
```
removedInput schema / properties / project / minLength
```
Removed value: -1
```
removedInput schema / properties / project / pattern
```
Removed value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"
```

changedInput schema / properties / read_handles / description

Previous value: -"The 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."New value: +"The reading list: #handles of THIS project the next session must read in full, in order. Only what is required."

removedInput schema / properties / read_handles / items / pattern

Removed value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"

changedInput schema / properties / supersedes / description

Previous value: -"#handle of the OPEN handoff this one replaces, from a read. Replacement is explicit by reference, never guessed from titles."New value: +"#handle of the OPEN handoff this one replaces, from a read."

removedInput schema / properties / supersedes / maxLength
```
Removed value: -4096
```
removedInput schema / properties / supersedes / minLength
```
Removed value: -1
```

changedInput schema / properties / where_stopped / description

Previous value: -"Where the work stands right now — what is done and verified, what is half-done."New value: +"What is done and verified, what is half-done."

removedInput schema / properties / where_stopped / maxLength
```
Removed value: -4096
```
removedInput schema / properties / where_stopped / minLength
```
Removed value: -1
```
removedInput schema / x-maxSerializedLength
```
Removed value: -131072
```

First observedSep 25, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Adds traits the annotations do not carry: the handoff is persistent and highly visible ('served at the top of every read until someone closes it'), and essence is effectively mandatory ('ALWAYS write the authored essence'). It also hints at replacement semantics via the supersedes concept, though it never says what the call returns or what happens on repeated passes without supersedes.

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?

Three sentences, front-loaded with the trigger and artifact, no filler. The all-caps emphasis is stylistically heavy but functionally load-bearing, and no sentence is redundant.

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 10-parameter mutation tool with no output schema, the description covers when to call it, its persistence, the mandatory essence, and content expectations. It leaves the return value (e.g. whether a handle comes back) and the relationship to arroway_close/arroway_continue unstated.

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?

Schema coverage is 100% (baseline 3), but the description adds real value beyond it: it declares essence as required even though the schema's required list omits it (with a narrow frozen-catalog exception), and it constrains content quality for where_stopped/next_step ('what the next session needs to continue, never a dump').

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 artifact ('leaves a HANDOFF') plus the exact triggering situation, and explicitly contrasts itself with the sibling arroway_log for completed tasks. An agent can distinguish it from all 19 siblings without opening a schema.

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?

Gives explicit when-to-use triggers (out of time, blocked, told to stop) and names the alternative path ('a completed task ends in arroway_log instead'). The selection condition between the two tools is fully specified.

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

All Arroway tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?