Skip to main content
Glama

Arroway

Record what the source says

arroway_verify
DestructiveIdempotent

Record what you found when your work ALREADY took you to a memory's source. This is bookkeeping, not an errand: never go verifying memories as a task — measured over a month, that never happens. But when you open a file, query, ticket or CRM that a memory points at, and you can see whether it still holds, say so here. Use the #handle shown in the read. Never guess an outcome you did not actually see. What the evidence decides, Arroway closes by itself (ARROW-290): a FACT whose source is proven gone is retired on the spot; a FACT whose source says something different is retired the moment you propose the correction with arroway_remember supersedes_id in this same session. On a FINDING, source_gone archives it the same way; conflicts is corrected in place with treatment=finding and supersedes_id, with no human queue. Rules and decisions are never retired this way — they only get marked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoRequired 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).
memoryYesThe #handle from the read (8 chars), or the full id
outcomeYesmatches = 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)
projectYes

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?

Even though annotations already declare destructiveHint=true and idempotentHint=true, the description adds rich behavioral detail: facts are retired automatically when sources are gone, findings are archived or corrected in place, and notes describing timeouts or auth failures are refused. This goes well beyond the structured annotations and clarifies real side effects.

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 dense and front-loaded with the core 'bookkeeping, not an errand' rule, and every sentence adds a meaningful constraint or edge case. It is somewhat long and contains run-on sentences, but no sentence is filler.

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?

Given the conditional required-note schema, the destructive potential, and the absence of an output schema, this description covers everything an agent needs: when to invoke, what outcomes mean, what to record in notes, and what automatic consequences follow. The only minor omission is explaining the project parameter, which is likely shared tool context.

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?

The schema already documents memory, outcome, and note well (75% coverage). The description adds meaning by requiring the #handle from the read, forbidding guessed outcomes, and specifying that source_gone notes must describe actual proof of removal, not mere unavailability. Project is not mentioned, but the schema coverage and overall context make this a minor gap.

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 leads with a precise verb-resource pair: 'Record what you found when your work ALREADY took you to a memory's source.' It also differentiates itself from siblings by drawing a line against 'verifying memories as a task' and pointing to related tools like arroway_remember and arroway_retire.

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?

It gives explicit when/when-not guidance: only use when you are already at the source, never go verify as a standalone errand, use the read's #handle, and never guess an outcome. It also names the exact follow-up actions for conflicts and source_gone, including when to call arroway_remember with supersedes_id.

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.