Arroway

Record what the source says

arroway_verify

Destructive

Record what a memory's source says when your work ALREADY took you there — never go verifying memories as a task. A conflicting one: propose the correction with arroway_remember. On a FINDING, source_gone archives it and a conflict is corrected in place.

Input Schema

Name	Required	Description
`note`	No	Required for conflicts (what the source says) and source_gone (what proves removal).
`memory`	Yes	The #handle from the read, or the full id.
`outcome`	Yes	source_gone = PROVEN removed, never a timeout or login wall. conflicts = the source says something different.
`project`	Yes	Project slug.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / outcome / description

Previous value: -"source_gone = PROVEN removed (404, file deleted, record gone), never mere unavailability (timeout, login wall, outage). conflicts = the source says something different."New value: +"source_gone = PROVEN removed, never a timeout or login wall. conflicts = the source says something different."

Changed12 schema fields changedOct 7, 2026

changedInput schema / properties / memory / description

Previous value: -"The #handle from the read (8 chars), or the full id"New value: +"The #handle from the read, or the full id."

removedInput schema / properties / memory / minLength
```
Removed value: -1
```

removedInput schema / properties / memory / pattern

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

changedInput schema / properties / note / description

Previous value: -"Required for 'conflicts' (what the source actually says — it is what lets a human fix it without checking again) and for 'source_gone' (what you saw that proves removal — a note describing a timeout, an auth failure or a service being down is refused)."New value: +"Required for conflicts (what the source says) and source_gone (what proves removal)."

removedInput schema / properties / note / minLength
```
Removed value: -1
```

changedInput schema / properties / outcome / description

Previous value: -"matches = the source says what the memory says · source_gone = the source is PROVEN REMOVED (404, file deleted from the repository, record gone) — never 'unreachable': a timeout, a login wall or a service that is down is unavailability, and nothing is retired for it · conflicts = the source says something DIFFERENT (then also call arroway_remember with supersedes_id; on a fact that proposal retires the wrong fact at once; on a finding the correction replaces it in place, with no human queue)"New value: +"source_gone = PROVEN removed (404, file deleted, record gone), never mere unavailability (timeout, login wall, outage). conflicts = the source says something different."

removedInput schema / properties / outcome / maxLength
```
Removed value: -4096
```
removedInput schema / properties / outcome / 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]+)*$"
```
removedInput schema / x-maxSerializedLength
```
Removed value: -131072
```

First observedSep 25, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the description must add specifics about what gets destroyed. It does: source_gone archives the memory and a conflict is corrected in place, which tells the agent the write is consequential. It doesn't clarify whether these are reversible or what confirmation is returned.

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?

Two short sentences with the key constraint ('never go verifying memories as a task') front-loaded, and the alternative routing placed immediately after. A few fragments ('On a FINDING', 'A conflicting one') are terse to the point of ambiguity, but nothing is padding.

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?

No output schema exists, so the description carries the burden of explaining consequences, and it covers the destructive outcomes (archive on source_gone, in-place correction on conflict). It leaves the 'matches' path and any response/confirmation behavior unstated, which is a small but real gap for a mutation tool.

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 enum meanings and note requirement are already documented in structured data. The description adds only marginal semantics, mostly restating that a conflicting source leads to a correction via arroway_remember. Baseline 3 is appropriate.

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 states a specific verb and resource: recording what a memory's source says. It distinguishes itself from arroway_remember by assigning corrections to that sibling. The title 'Record what the source says' reinforces the purpose, though phrases like 'On a FINDING' are undefined and slightly obscure the exact outcome set.

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?

Explicit when-not guidance is given: 'never go verifying memories as a task', only record when work already took you there. It also names the alternative for the conflict case (arroway_remember). It stops short of spelling out what to do for a plain 'matches' outcome or how this interacts with arroway_read / arroway_complete_read.

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 All Your Agents Can ShareAgents share what they learn, hand off work, and hold 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?