Arroway keeps people and their AIs on the same page. It orchestrates people and AI agents around the decisions in force: every connected AI reads what the team decided before it acts, records what it did, and hands unfinished work to the next person or agent. What an AI proposes waits for a person's approval.
Scored across 19 tools
Most tools have sharply distinct triggers and the descriptions explicitly contrast siblings (log vs pass, retire vs withdraw, read vs norms). The read family (read, norms, catch_up, search_log) and the multi-part pair (continue vs complete_read) require careful reading, but the guidance largely disambiguates them.
Every tool uses the same arroway_ prefix with a consistent snake_case verb or verb_noun form (arroway_read, arroway_start_project, arroway_search_log). No mixing of conventions; the pattern is fully predictable.
19 tools sits at the heavy end of the range, but the domain (memory curation, handoffs, multi-part reads, import/export, admin config) is genuinely broad and most tools earn their place. A couple of niche tools (configure_referrer, complete_read) push it slightly past ideal.
The surface covers the full memory lifecycle: read/recall, remember/verify, retire/withdraw, move, log/pass, claim/close, export/import, and project start, plus session bootstrap and admin config. Destructive/discard actions are intentionally delegated to the human panel, so no real agent-facing gaps remain.
Call ONCE at the START of a session, before there is a task: what happened recently across all of this person's projects, opening with the roster of their projects (slug and purpose) and open handoffs.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days back, counting today. Default 2; more only when picking up work after being away. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuine behavioral context beyond them: the call-frequency expectation ('ONCE at the start') and the structure of what is returned (roster first, then handoffs). No pagination or size cues, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the imperative action timing, no filler. Every clause (once, start of session, cross-project scope, return contents) carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value context, and it does describe the opening roster and handoffs. 'What happened recently' remains slightly abstract about the full range of returned activity, keeping this just short of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single 'days' parameter is fully documented in the schema (range 1-30, default 2, when to increase). The description adds nothing about the parameter, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (catch up on what happened) with an explicit cross-project scope, and even previews the return shape (project roster with slug and purpose, plus open handoffs). That scope distinguishes it from narrower siblings like arroway_read, arroway_search_log, or arroway_continue without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear usage condition and timing constraint: 'Call ONCE at the START of a session, before there is a task.' This implicitly excludes mid-task use and repeated calls. It stops short of naming an alternative sibling or an explicit when-not, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark that you are taking an open handoff BEFORE working on it, so parallel sessions do not duplicate it. A claim is a mark, never a lock. Addressing rule: addressed to YOUR user — take it; to someone else — only a human in this conversation can decide to take it, and an autonomous session must leave it.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Who is taking it — a routine names itself here. | |
| handoff | Yes | The #handle from the read, or the full id. | |
| project | Yes | Project slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the mutation/safety profile is partly covered. The description adds genuinely non-annotated behavior: claims are advisory marks rather than locks, and the addressing rule governs whether an autonomous agent is permitted to act. It stops short of saying what happens if the handoff is already claimed or already closed, which is the remaining behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct load: what the tool does, the concurrency rationale, and the addressing decision rule. The most important action timing ('BEFORE working on it') is front-loaded with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must stand alone for behavior, and it covers purpose, timing, concurrency semantics, and authorization. It is nearly complete; only the outcome of claiming an already-taken or closed handoff is unaddressed, a minor gap given the idempotentHint annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: project, handoff, and note are each documented in the schema, including that note names the taker. The description adds no format, handle syntax, or requiredness detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Mark that you are taking an open handoff') plus the scope constraint ('BEFORE working on it, so parallel sessions do not duplicate it'). It also clarifies the semantics of the operation ('a claim is a mark, never a lock'), which cleanly separates it from siblings like arroway_withdraw, arroway_pass, and arroway_close.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when ('BEFORE working on it'), a why (avoid duplication across parallel sessions), and a when-not with the deciding authority spelled out: addressed to someone else, only a human in this conversation may take it and an autonomous session must leave it. That is a complete routing rule an agent can act on without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close an open handoff when its work is DONE, alongside the arroway_log entry that records the residue. Work that removes what an open handoff exists to fix closes that handoff in the same pass — even when the handoff is someone else's. So this is also the call for someone ELSE's handoff, with a note naming what emptied it. A handoff that still carries real work, which a passer-by must never close, stays open; discarding a handoff is the human's gesture, in the panel.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | One line on what landed; it points at the residue. | |
| handoff | Yes | The #handle from the read, or the full id. | |
| project | Yes | Project slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint=false, destructiveHint=false and idempotentHint=true, and the description adds genuinely new behavior: closing another person's handoff is permitted, a note is expected to name what emptied it, and destruction is deliberately out of scope (the human discards in the panel). It does not say what state the handoff lands in after closing or whether the action is auditable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core rule in the first clause, but the middle sags: 'even when the handoff is someone else's' is restated by 'So this is also the call for someone ELSE's handoff,' and the panel aside is stylized. Efficient in content, but a sentence of redundancy survives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation with full schema coverage, no output schema and helpful annotations, the description covers selection, the companion call, and the prohibition adequately. Remaining gap is post-close state and any permission/ownership nuance for touching another person's handoff.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns a bump by explaining the note's role ('with a note naming what emptied it', 'one line on what landed; it points at the residue') and clarifying that the handoff handle can come from the read or be a full id, which contextualizes the two required params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (close) + resource (an open handoff) with a clear success condition: 'when its work is DONE.' It also implicitly distinguishes itself from arroway_log (used alongside, not instead) and from human panel discard. It stops short of naming a sibling explicitly (e.g. arroway_pass, arroway_withdraw), so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the trigger ('work is DONE'), the companion call (arroway_log records the residue), an extended case (removing what a handoff exists to fix, closing even someone else's handoff), and an explicit prohibition ('a handoff that still carries real work … must never close') plus the correct alternative (discarding is the human's gesture, in the panel).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Acknowledge the final part of a multi-part Arroway read with its read_id and receipt, closing the sequence. It is not a precondition for working.
| Name | Required | Description | Default |
|---|---|---|---|
| read_id | Yes | Opaque id returned by the incomplete arroway_read response. | |
| receipt | Yes | Opaque receipt returned by the final part. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: this call terminates a sequence and is optional, so skipping it does not break the workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and followed by the optionality caveat. 'Closing the sequence' slightly restates 'final part', a minor redundancy in an otherwise waste-free description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-param, idempotent ack call with no output schema, the description covers what it does, when to call it, and that it is optional. It does not say what happens if the receipt is stale or the call is skipped, but nothing essential to invoking it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both read_id and receipt are already documented as opaque values with their provenance. The description only restates that they are supplied together, adding no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (acknowledge/confirm) and resource (the final part of a multi-part Arroway read) and explains the effect: closing the sequence. This is enough to separate it from arroway_read and arroway_continue, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use (after the final part of a multi-part read) and an explicit non-requirement: 'It is not a precondition for working.' That tells the agent not to block on this call, but no alternative tool is named for related cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Product administrators only: map an external referrer domain to a source and channel in Arroway's acquisition view, when an administrator asks. Stores only the domain and two labels; calling again replaces the mapping.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | External hostname only, such as linkedin.com. | |
| source | Yes | Short source label, such as linkedin. | |
| channel | Yes | Short channel label, such as organic-social or directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by stating the permission requirement and the storage footprint ('Stores only the domain and two labels'), which is the kind of scope detail annotations cannot convey. 'Calling again replaces the mapping' restates the idempotentHint in operational terms and clarifies that no duplicates accumulate. It stops short of describing the response, but the write/idempotent/non-destructive profile is fully covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with zero filler, front-loading the audience restriction before the action. Every clause (audience, action, storage, replace semantics) carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter write tool with no output schema and annotations covering safety and idempotency, the description supplies the key extras: who may call it and what state it mutates. The only gap is that it does not explain the effect of the mapping on downstream acquisition reporting, which would help an agent set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (domain hostname, source label, channel label) is already documented with examples. The description adds only the aggregate observation that all three values are persisted, which is marginal beyond the schema. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: map an external referrer domain to a source and channel in the acquisition view. The three arguments are named inline, so an agent knows exactly what the tool operates on. Nothing in the sibling list (catch_up, claim, export, etc.) competes with this function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition ('Product administrators only') and a trigger ('when an administrator asks'), which is the relevant context for a privileged admin configuration tool. It names no alternative tool or exclusion, but no sibling performs comparable mapping, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the next part of a read that did not fit in one response (read_id and receipt of the preceding part). OPTIONAL: the first part already counts as delivered and names what later parts hold.
| Name | Required | Description | Default |
|---|---|---|---|
| read_id | Yes | Opaque id returned by the incomplete arroway_read response. | |
| receipt | Yes | Opaque receipt returned by the immediately preceding part. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds pagination semantics (the preceding part supplies the receipt) but omits whether more parts may follow, how completion is signalled, or why the call is non-idempotent. Some added value, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded and the parameters parenthesized where expected. The second sentence is awkwardly phrased and slightly cryptic ('names what later parts hold'), costing some clarity but not much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining what comes back on a continuation call, and it does not: it never says whether more parts may remain or how the agent knows the read is finished. Annotations cover safety, but for a pagination continuation tool this is a meaningful omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description's notes about read_id and receipt provenance largely restate that, adding no format or edge-case detail beyond structured data. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource: fetching the next part of a paginated read, with the trigger condition (the read did not fit in one response). It references the originating arroway_read implicitly via 'read_id ... returned by the incomplete arroway_read response', but does not explicitly name a sibling alternative, so it falls short of the 5 bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The trigger condition is stated ('a read that did not fit in one response'), which is useful context. However, there is no explicit comparison with alternatives and the 'OPTIONAL: the first part already counts as delivered' clause is ambiguous about whether/when the agent should actually call this, leaving usage partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export OUT of a project what it has DECIDED, as a portable memory pack for another team or project. Only sanctioned, live memories travel: a FINDING never was one, so findings stay and the answer tells you how many did. Nothing about people travels.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | What this pack IS, in a few words: the first thing the other side reads. | |
| topic | No | Optional: export only the memories carrying this topic. | |
| project | Yes | Slug of the project whose norms you are exporting | |
| description | No | Optional: who it is for, what it assumes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, and the description does not contradict them. It then adds genuinely non-obvious scope behavior: only sanctioned live memories travel, findings are deliberately excluded, the response reports how many were withheld, and no personal data is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the action and scope, each clause carrying real information about inclusion/exclusion rules. No filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully notes that the answer reports how many memories were skipped. It covers scope and side effects well, though it leaves the pack's form and how the receiving side consumes it unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (name, topic, project, description) is already documented in the schema. The description adds no syntax, defaults, or semantics beyond that, which is the expected baseline when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (export) and resource (a project's decided norms, packaged as a portable memory pack) with unusual precision about what is and is not included. It does not name the obvious inverse sibling arroway_import, so an agent must infer the pairing, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through 'for another team or project', which signals the transfer scenario, but there is no explicit when-to-use statement and no reference to arroway_import as the counterpart operation. An agent can guess the intent but gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bring a memory pack made by arroway_export INTO a project. Everything lands as a PROPOSAL for the person's review and nothing is pinned, whatever the pack says. If any part is malformed, nothing is imported.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | Yes | The pack document itself; this server does not fetch URLs. | |
| project | Yes | Project slug. Not from the person or a read this session? It is a guess: check the arroway_catch_up roster. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the write/non-idempotent profile, but the description adds real semantics beyond them: everything lands as a PROPOSAL, nothing is pinned regardless of pack content, and the import is atomic (any malformed part aborts the whole thing). It stops short of naming required permissions or a result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: purpose first, then the propose-not-pin guarantee, then the atomicity constraint. No filler and every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter write tool with no output schema, the description covers purpose, default state (proposals), and failure behavior (all-or-nothing). It omits required authorization and what the response reports, which keeps it just short of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the pack and project parameters, including the roster cross-check guidance for project. The description only implicitly references the pack and target project, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (import/bring) and resource (a memory pack) with explicit scope (INTO a project), and names the sibling that produces the input (arroway_export). An agent can distinguish this from siblings like arroway_remember without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly establishes the context of use: importing a pack that originated from arroway_export. It does not, however, state exclusions or route the agent to any alternative tool for a different need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the durable residue of a COMPLETED task in the team-visible daily log: what someone arriving later needs in order not to redo it, dated state included. ALWAYS write the authored essence (only a frozen catalog without that field may omit it). If the person corrected you for re-litigating a decision, say so. If this work made a read memory's 'dies when' true, name it in fulfills and it is retired with this entry.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional free tag (e.g. 'marketing') | |
| source | No | Optional pointer to a living source (URL, doc, CRM id) | |
| content | Yes | What was decided, found or changed, and what it cost. You judge the length. | |
| essence | No | One authored line with the operative result; never the opening of the body. | |
| project | Yes | Project slug. Not from the person or a read this session? It is a guess: check the arroway_catch_up roster. | |
| fulfills | No | Memories whose 'dies when' this work made true (decision/fact/reference received in full in a read). Never one that merely looks old. | |
| backfilled | No | true for history from BEFORE Arroway existed, not today's work. | |
| keep_whole | No | true only after you considered cutting an indivisible oversized residue. | |
| operational | No | true for HOW the work went (failures, measurements, self-corrections): kept for catch-up, out of task reads. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a write (readOnlyHint=false) and non-idempotent. The description adds context annotations cannot carry: the entry is team-visible, and naming a memory in 'fulfills' retires it as a side effect of this call. It omits the practical consequence of idempotentHint=false (repeat calls duplicate the entry).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the action and scope, with no filler or marketing language. Density is high but the parentheticals ('only a frozen catalog without that field may omit it') are cryptic enough that an agent may need a second pass.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, no-output-schema write tool this covers the hard parts: what to include, the essence requirement, the retirement side effect, and backfill vs today's work. Remaining gaps are minor (duplicate-write behavior on retry, and how to recover from a bad project slug beyond the catch_up hint already in the schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond it: it declares 'essence' effectively mandatory ('ALWAYS write the authored essence') even though the schema does not list it as required, and explains the semantic trigger for 'fulfills' as a kill condition rather than mere staleness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Record ... in the team-visible daily log') scoped to a COMPLETED task, so the agent knows this is a post-completion write, not an in-flight note. The metaphor 'durable residue' and 'dated state included' add fog rather than precision, and no sibling (e.g. arroway_remember or arroway_retire) is named for contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear trigger ('COMPLETED task') plus conditional instructions for edge cases: when a correction happened, when a read memory's 'dies when' became true. It does not, however, state when NOT to use it or which sibling to prefer for related writes, so the agent must infer the boundary with arroway_remember/arroway_close.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move something to the project it belongs in. A memory is only PROPOSED: the change waits for the person's review, because moving changes who sees it. A log entry you wrote moves at once, text unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| why | Yes | Why it belongs there and not here. For a memory, the person decides on this sentence. | |
| memory | Yes | #handle of the memory or log entry, from a read or arroway_search_log | |
| target | Yes | Slug of the project you believe it belongs to | |
| project | Yes | Slug of the project it is in TODAY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond what annotations provide: a memory move is only PROPOSED and waits for human review, whereas a log entry move happens immediately with text unchanged, plus the note that moving changes who sees it. These are exactly the workflow and visibility consequences an agent must know, and they are consistent with the annotations (non-destructive, idempotent).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, each carrying a distinct fact: the action, the memory path with its review gate, and the log path with text preservation. No filler and the high-value distinction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, all-required mutation tool with no output schema, the description covers the critical behavioral divergence (review vs immediate) and the visibility implication. It could note any permission or precondition requirements, but nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all four parameters including why, memory handle, and the today-vs-target project slugs. The description reinforces the 'why' semantics and the immediacy of log moves but adds no new syntax or format detail beyond the schema, so baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (move) and resource (memory or log entry) and clarifies the target concept ('the project it belongs in'). The word 'something' is a bit loose, but the body immediately disambiguates into the two moveable things, so an agent can tell it apart from siblings like arroway_remember or arroway_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the two usage paths (memory vs log entry) and their differing outcomes, which effectively tells the agent when each case applies. It does not name an alternative tool for related operations, so it falls short of the explicit when/when-not/alternative standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call in the seconds BEFORE you tell the person something or propose a course of action: returns what is already decided (the project's and this person's own) AND THEN A MAP of the titles and handles of everything else. arroway_read include GUARANTEES a mapped one in full; it does not make that read any cheaper, so use it to be sure, never to pay less. Before publishing text for others, pass it as draft: what it touches comes back in full.
| Name | Required | Description | Default |
|---|---|---|---|
| draft | No | Optional: the text you will publish or say (PR, comment, message, page), ending with one line in the project's language on what it claims, recommends and names. | |
| since | No | Optional: checkpoint from a previous arroway_norms call for THIS project (not the read's). Omit after compaction or in a new conversation. | |
| project | Yes | Project slug the claim is about. |
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
Read Arroway for a project BEFORE acting on any task related to it. It serves the authored essence of memories, dated-log entries and handoffs by default; name a #handle in include to recover that object's full body.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Optional: checkpoint from a previous read of THIS project, so standing rules are not reprinted. Omit after compaction or in a new conversation. | |
| handoff | No | Optional: #handle of an OPEN handoff you are continuing; the read is built from its reading list (none: falls back to the normal read). Cannot be combined with include. | |
| include | No | #handles whose full body you need; they come first, so others fall out — it chooses, it does not add. | |
| project | Yes | Project slug, e.g. 'seven50' | |
| task_context | No | Optional: what you are about to do; it ranks results. The declaration alone is NOT evidence of use: a matching completion residue from the same session must corroborate it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds useful behavioral context about the default serving mode (essence vs. full body via include), but says nothing about result volume, truncation, or pagination behavior for a read that can return many objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the imperative and the timing constraint, with no filler. The second clause is dense but slightly abstract ('authored essence'), which is the only thing keeping it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of describing the return payload — it names the three content types returned, which is adequate. It is complete enough for a low-risk read-only tool, though it omits any note on result size or completeness limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented in the schema with constraints and interactions. The description only restates the include behavior ('recover that object's full body'), adding no syntax or meaning beyond the schema — the baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (read) and enumerates exactly what is served by default: authored essence of memories, dated-log entries, and handoffs, plus the #handle recovery path. It does not, however, name or distinguish itself from adjacent siblings such as arroway_search_log or arroway_complete_read, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit timing rule — 'BEFORE acting on any task related to it' — which is strong usage guidance. It stops short of naming alternatives or when-not-to-use cases, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a durable memory (decision/rule/fact/preference/reference/identity): only what would change what someone does on a DIFFERENT task. Unsanctioned in THIS conversation, it is a PROPOSAL — never present it as a decision. 'identity' is WHO someone is: the user's circle goes in their personal project, a business's people in that business's project. A sourced fact or reference that only informs can be a finding, which cannot replace a sanctioned memory.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Kind of memory. | |
| title | Yes | Short, unique within the project | |
| topic | No | Optional free tag (e.g. 'marketing'). | |
| content | Yes | The norm ITSELF, as if true today, in the shortest form that still governs correctly. Biography (who, when, quotes, dated numbers) goes in why_source; a specific case in example. | |
| essence | Yes | The operative norm or fact in ONE line. | |
| example | No | A case illustrating the rule, shown in the panel; it NEVER travels in reads, so any criterion goes in content. | |
| expires | No | true ONLY for a dated STATUS that would be stale after review_at. If unsure, omit. | |
| project | Yes | Project slug. Not from the person or a read this session? It is a guess: check the arroway_catch_up roster. | |
| review_at | No | YYYY-MM-DD when this stops being true on its own. REQUIRED for a fact, which leaves reads after it. | |
| treatment | No | `governed` enters the person's review queue, a real cost to them; `finding` costs nobody a review and is never a norm. Does it GOVERN what someone may or must do, or only INFORM? Informs, with a source an agent can reopen and compare: finding (only fact and reference qualify). | |
| backfilled | No | true for sourced HISTORY from before Arroway, on the topic just worked on; never a dump. | |
| source_ptr | No | Pointer to the living source, when verifiable | |
| why_source | No | Where it came from: the ONLY place for biography. This does NOT travel in reads; it is shown in the panel. | |
| contradiction | No | Required with supersedes_id: what this changes in the earlier memory. | |
| pin_suggested | No | Your judgement on pinning (travels in EVERY read). There is no default: required on a rule's second call. Above the ceiling it becomes a proposal of the pin alone. | |
| supersedes_id | No | #handle of the memory this replaces, only for the SAME point: acting on either would already satisfy or violate the other. A shared topic is not enough. | |
| kill_condition | Yes | Mandatory: explicit revocation / named trigger / review date | |
| related_checked | No | Second call only: true after reading the related memories shown. | |
| decided_by_human | Yes | true ONLY if the person stated or sanctioned it in THIS conversation; else a proposal. A proposal is never free: it costs that person a review. Then only a PINNED memory travels in every read; a normal one competes for space in the block relevant to each task. Never write an instruction to check, verify, be careful or look at the source, a step of a routine, or anything here only because something went wrong once. | |
| split_considered | No | true only after looking for seams; splitting is the default. | |
| example_considered | No | Second call only: true if the flagged example is criterion the rule needs. | |
| pin_decision_token | No | Second call only: the first call's token, unchanged. | |
| related_check_token | No | Second call only: token returned with the related memories. | |
| pin_requested_by_human | No | true ONLY if the person told you in THIS conversation to keep it in every session. Sanctioning the CONTENT is not asking for the pin. Pins above any ceiling. | |
| revoked_reconsideration | No | Second call only: the person's words in THIS conversation reconsidering a revoked finding. | |
| treatment_justification | No | Required for a finding: why it is verifiable context, not policy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare only non-read-only, non-destructive, non-idempotent, closed-world; the description adds genuinely behavioral context beyond them: that an unsanctioned write materializes as a proposal rather than a decision, and that a finding 'cannot replace a sanctioned memory.' It does not disclose the two-call protocol or the review cost the schema mentions, but it goes well past what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences for a 26-parameter, high-complexity tool is tight, and the core purpose plus proposal caveat are front-loaded. The all-caps emphasis (DIFFERENT, PROPOSAL) is functional rather than padding, though the density of compressed domain jargon costs some readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and carries most parameter detail, so the description need not restate it, and no output schema exists to explain. However, for a tool this complex the description omits a major behavioral trait: that many paths require a second call (tokens, related_checked, pin_decision_token) and that pinning has a ceiling. An agent reading only the description would not anticipate the multi-call flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it defines what 'identity' actually denotes (WHO someone is) and where each identity belongs, and it draws the governed-vs-finding line that selects between fact/reference and the rest. That is real semantic lift on the two most consequential enum choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Save a durable memory') and enumerates the qualifying kinds (decision/rule/fact/preference/reference/identity) plus the scoping test ('only what would change what someone does on a DIFFERENT task'). That is far more precise than the title alone. It never names or contrasts a sibling tool (arroway_log, arroway_norms, arroway_claim), so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies real when-to-use context: the cross-task relevance filter, the rule that unsanctioned content is a PROPOSAL and must not be presented as a decision, and the identity scoping convention (user's circle -> personal project, a business's people -> that business's project). What is missing is any explicit routing to an alternative tool when the content is not durable (e.g. a log entry or a norm lookup), so exclusions stop at the content level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retire a SANCTIONED memory when the person told you in this conversation to remove it and nothing replaces it. Archived, never deleted. With a corrected version, use arroway_remember supersedes_id; for your own pending proposal, arroway_withdraw.
| Name | Required | Description | Default |
|---|---|---|---|
| why | No | Optional: what the person said made it obsolete, in their terms. | |
| memory | Yes | The memory to retire — the #handle from a read is enough. | |
| project | Yes | Project slug. | |
| decided_by_human | Yes | Must be true, and only when the person explicitly told you to remove it IN THIS CONVERSATION. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds the crucial nuance that the memory is 'Archived, never deleted' — a distinction the destructive hint alone would leave ambiguous. It also discloses the precondition that the instruction must be sanctioned and given in the current conversation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no filler. The core action and its constraint come first, and the disambiguation to siblings follows, which is the right front-loading for a routing-sensitive tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter mutation tool with no output schema, the description covers the action, the precondition, the postcondition ('archived, never deleted'), and the alternatives. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (project, memory, why, decided_by_human) are already documented in the schema. The description reinforces the decided_by_human condition but adds no format or syntax detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (retire) and resource (a SANCTIONED memory), plus the gating condition (person instructed removal in this conversation). It also names the two sibling tools that handle the adjacent cases, so an agent can distinguish it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (person said to remove it, nothing replaces it) and explicit when-not (use arroway_remember with supersedes_id for a corrected version; use arroway_withdraw for your own pending proposal). The routing to alternatives is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find WHERE a literal term or phrase appeared in the recent dated log (essence and body), across every project of this person or one. Returns short excerpts anchored by project, date and entry. It searches what happened, not curated memory.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Literal term or phrase; case-insensitive. | |
| project | No | Optional project slug; omit to search them all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds value beyond them by disclosing which fields are searched (essence and body) and the shape of results ('short excerpts anchored by project, date and entry'), which matters because no output schema exists. It omits any recency window or result-count limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the search target front-loaded, followed by the output shape and the differentiator. No filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully previews the return format and search scope, which is enough for a two-parameter read tool. It would be fully complete if it hinted at the recency boundary implied by 'recent' or any cap on results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the literal case-insensitive match and the omit-to-search-all behavior for project. The description reinforces project scope but adds no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find WHERE a literal term or phrase appeared in the recent dated log'), names the searched fields (essence and body), and the scope (across every project). The closing line 'It searches what happened, not curated memory' distinguishes it from the memory-oriented siblings like arroway_remember and arroway_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The line 'searches what happened, not curated memory' gives clear selection context against the memory tools, and 'across every project of this person or one' signals the project-scoping choice. It stops short of naming a concrete alternative tool or an explicit when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a NEW project when the work at hand has no home in Arroway. Propose the name and scope to the person FIRST and call only once they agree. update=true renames a project you own and rewrites its scope, when the person asks or the scope is wrong; the slug stays.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | How people will call it | |
| slug | Yes | Short, lowercase, hyphenated, unique — e.g. 'trading-solana' | |
| scope | Yes | What belongs here and what does not: the subject AND what is out. | |
| update | No | true: change name and scope of the existing project at slug. |
Record what a memory's source says when your work ALREADY took you there — never go verifying memories as a task, never guess an outcome. A FACT proven gone is retired at once; a conflicting one when you propose the correction with arroway_remember supersedes_id. On a FINDING, source_gone archives it and a conflict is corrected in place. Rules and decisions are only marked.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 (404, file deleted, record gone), never mere unavailability (timeout, login wall, outage). conflicts = the source says something different. | |
| project | Yes | Project slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose destructiveHint=true and idempotentHint=true, but the description adds real substance: it names what happens per outcome and memory type (a proven-gone FACT is retired at once, a source_gone FINDING is archived, a conflict is corrected in place, rules/decisions are only marked). It does not state permission/auth requirements or the response shape, but the mutation consequences are unusually well specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical rule is front-loaded, which is good, but the middle sentence is an ungrammatical fragment ('a conflicting one when you propose the correction with arroway_remember supersedes_id') and the FACT/FINDING clauses are dense jargon. Volume is reasonable; clarity-per-sentence is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, idempotent mutation with full schema coverage and no output schema, the description covers consequences adequately and needs no return-value detail. However, it assumes the reader already knows the FACT/FINDING/rules/decisions classification that governs which side effect fires, which is central to invoking the tool correctly and is never explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the outcome enum semantics, the note requirements, and the memory handle format are already documented in the schema. The description reinforces the outcome meanings but adds no new syntax, format, or constraint detail beyond what the schema carries. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and object: record what a memory's source says, i.e. report the result of a source check. It distinguishes itself by describing the divergent side effects per outcome type (retire, archive, correct, mark) and names the sibling arroway_remember as the correction path. It loses a point because the operative taxonomy (FACT vs FINDING vs rules/decisions) is used without definition, so a cold reader cannot fully reconstruct what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it (only when work already took you to the source) and when not to ('never go verifying memories as a task, never guess an outcome'). It also routes the agent to the alternative for corrections: arroway_remember with supersedes_id. This is the strongest part of the definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take back a pending PROPOSAL that turned out to be wrong, usually because the person corrected you. Not for sanctioned memories. It is kept as withdrawn, with your reason. If the corrected version is durable, also write it with arroway_remember.
| Name | Required | Description | Default |
|---|---|---|---|
| why | Yes | What made it wrong — usually what the person said. | |
| memory | Yes | #handle of the proposal, from a read | |
| project | Yes | Project slug. | |
| other_author_confirmed | No | Second call only, after Arroway said someone else's AI wrote the proposal: true to go ahead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish mutation (readOnlyHint=false), idempotency, and non-destructiveness. The description adds real behavioral value by disclosing that the record persists as 'withdrawn, with your reason' rather than being deleted. It omits the multi-call confirmation flow hinted at by the other_author_confirmed parameter (Arroway first reporting another AI authored the proposal).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the core action, then scope exclusion, persistence behavior, and the complementary call. No redundancy and each sentence contributes distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity mutation tool with annotations covering the safety profile and no output schema, this is nearly complete: it covers purpose, exclusion, persistence, and follow-up. The only meaningful gap is the multi-call confirmation path implied by the optional other_author_confirmed parameter, which the description never explains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters including the two-step other_author_confirmed semantics are documented in the schema itself. The description only loosely gestures at 'your reason' (the why param) and adds no syntax, format, or handling detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Take back a pending PROPOSAL') and draws its boundary explicitly ('Not for sanctioned memories'). An agent can distinguish this from siblings like arroway_remember or arroway_retire without opening any schema, and the 'your own' framing in the title reinforces ownership scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering context ('turned out to be wrong, usually because the person corrected you'), a when-not ('Not for sanctioned memories'), and routes the follow-up action to arroway_remember. It does not, however, name the alternative tool to use for the sanctioned-memory case it excludes, leaving that routing ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
arroway_start_project1 field changedInput schema / properties / updateAdded value: +{
+ "description": "true: change name and scope of the existing project at slug.",
+ "type": "boolean"
+}arroway_norms1 field changedInput schema / properties / draftAdded value: +{
+ "description": "Optional: the text you will publish or say (PR, comment, message, page), ending with one line in the project's language on what it claims, recommends and names.",
+ "maxLength": 20000,
+ "type": "string"
+}arroway_catch_up2 fields changedInput schema / properties / days / descriptionPrevious value: -"How many days back, counting today. Default 2 — yesterday and today, which is what a session normally needs to know where things stand. Ask for more only when you are picking up work after being away."New value: +"Days back, counting today. Default 2; more only when picking up work after being away."Input schema / x-maxSerializedLengthRemoved value: -131072arroway_claim9 fields changedInput schema / properties / handoff / descriptionPrevious value: -"The #handle from the read (8 chars), or the full id."New value: +"The #handle from the read, or the full id."Input schema / properties / handoff / maxLengthRemoved value: -4096Input schema / properties / handoff / minLengthRemoved value: -1Input schema / properties / note / descriptionPrevious value: -"Who is taking it, in plain words — a routine names itself here (e.g. 'nightly build routine')."New value: +"Who is taking it — a routine names itself here."Input schema / properties / note / minLengthRemoved value: -1Input schema / properties / project / descriptionAdded value: +"Project slug."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / x-maxSerializedLengthRemoved value: -131072arroway_close9 fields changedInput schema / properties / handoff / descriptionPrevious value: -"The #handle from the read (8 chars), or the full id."New value: +"The #handle from the read, or the full id."Input schema / properties / handoff / maxLengthRemoved value: -4096Input schema / properties / handoff / minLengthRemoved value: -1Input schema / properties / note / descriptionPrevious value: -"One line on what landed — it points at the residue, it does not replace it."New value: +"One line on what landed; it points at the residue."Input schema / properties / note / minLengthRemoved value: -1Input schema / properties / project / descriptionAdded value: +"Project slug."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / x-maxSerializedLengthRemoved value: -131072arroway_complete_read5 fields changedInput schema / properties / read_id / maxLengthRemoved value: -4096Input schema / properties / read_id / minLengthRemoved value: -1Input schema / properties / receipt / maxLengthRemoved value: -4096Input schema / properties / receipt / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_configure_referrer9 fields changedInput schema / properties / channel / descriptionPrevious value: -"Short channel label, such as organic-social, directory or referral."New value: +"Short channel label, such as organic-social or directory."Input schema / properties / channel / maxLengthRemoved value: -4096Input schema / properties / channel / minLengthRemoved value: -1Input schema / properties / domain / descriptionPrevious value: -"External hostname only, such as linkedin.com — no URL, path or query string."New value: +"External hostname only, such as linkedin.com."Input schema / properties / domain / maxLengthRemoved value: -4096Input schema / properties / domain / minLengthRemoved value: -1Input schema / properties / source / descriptionPrevious value: -"Short source label, such as linkedin or anthropic-directory."New value: +"Short source label, such as linkedin."Input schema / properties / source / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_continue5 fields changedInput schema / properties / read_id / maxLengthRemoved value: -4096Input schema / properties / read_id / minLengthRemoved value: -1Input schema / properties / receipt / maxLengthRemoved value: -4096Input schema / properties / receipt / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_export10 fields changedInput schema / properties / description / descriptionPrevious value: -"Optional: who this pack is for and what it assumes. Written for someone who has never seen this project."New value: +"Optional: who it is for, what it assumes."Input schema / properties / description / maxLengthRemoved value: -4096Input schema / properties / description / minLengthRemoved value: -1Input schema / properties / name / descriptionPrevious value: -"What this pack IS, in a few words — the vertical, the practice, the playbook. It travels with the document and is the first thing the other side reads."New value: +"What this pack IS, in a few words: the first thing the other side reads."Input schema / properties / name / minLengthRemoved value: -1Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / topic / descriptionPrevious value: -"Optional: export only the memories carrying this topic. Use it to hand over one practice instead of everything a project knows."New value: +"Optional: export only the memories carrying this topic."Input schema / properties / topic / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_import5 fields changedInput schema / properties / pack / descriptionPrevious value: -"The pack document itself, as it was written by arroway_export. Read the file and pass its contents — this server does not fetch URLs on your behalf."New value: +"The pack document itself; this server does not fetch URLs."Input schema / properties / project / descriptionPrevious value: -"Project slug. If it did not come from the person or from a read in this session, it is a guess: check it against the roster that opens arroway_catch_up before writing, because material from one circle must never land in another."New value: +"Project slug. Not from the person or a read this session? It is a guess: check the arroway_catch_up roster."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / x-maxSerializedLengthRemoved value: -131072arroway_log19 fields changedInput schema / properties / backfilled / descriptionPrevious value: -"True when the entry describes something that happened BEFORE Arroway existed (history you are bringing in), not today's work."New value: +"true for history from BEFORE Arroway existed, not today's work."Input schema / properties / content / descriptionPrevious value: -"The full durable residue: what was decided, found or changed, and what it cost. It remains recoverable by handle."New value: +"What was decided, found or changed, and what it cost. You judge the length."Input schema / properties / content / minLengthRemoved value: -1Input schema / properties / essence / descriptionPrevious value: -"One authored line with the operative result. This is what the normal project read serves; never copy the opening of the body."New value: +"One authored line with the operative result; never the opening of the body."Input schema / properties / essence / minLengthRemoved value: -1Input schema / properties / fulfills / descriptionPrevious value: -"ARROW-290. The memories this completed work REALIZED — their 'dies when' condition is now true because of what you did (a routine that an idea asked for is running; a planned move was made; a dated status has been replaced by what this entry records). Each one is retired in the same act as this log, with your 'how' as the reason on its archived line, reversible from the panel. Guards: only decision/fact/reference (a rule is never 'fulfilled'), and only memories this connection received in full in a read — if any item fails, the whole call is refused and nothing is written. Never list a memory because it merely looks old or unused: that is not evidence."New value: +"Memories whose 'dies when' this work made true (decision/fact/reference received in full in a read). Never one that merely looks old."Input schema / properties / fulfills / items / properties / how / descriptionPrevious value: -"What this work did that met the memory's kill condition — one sentence; it stays on the archived line forever."New value: +"What met the kill condition, in one sentence."Input schema / properties / fulfills / items / properties / how / minLengthRemoved value: -1Input schema / properties / fulfills / items / properties / memory / descriptionPrevious value: -"The #handle from the read (8 chars), or the full id"New value: +"The #handle from the read, or the full id."Input schema / properties / fulfills / items / properties / memory / minLengthRemoved value: -1Input schema / properties / fulfills / items / properties / memory / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / keep_whole / descriptionPrevious value: -"Set true only after you considered cutting an indivisible oversized residue. Arroway records this exception for calibration; it never truncates your text automatically."New value: +"true only after you considered cutting an indivisible oversized residue."Input schema / properties / operational / descriptionPrevious value: -"Set true when this is the record of HOW THE WORK WENT — what failed, what you measured, what you corrected about your own earlier reading. It is kept in full for catching up at the start of a session, and stays OUT of the task-scoped read, so a long account never pushes a teammate's residue out of their block. Leave it out (the default) for what the team needs to know HAPPENED: that is what reaches other people while they work. This is a record of work, never a transcript of the conversation."New value: +"true for HOW the work went (failures, measurements, self-corrections): kept for catch-up, out of task reads."Input schema / properties / project / descriptionPrevious value: -"Project slug. If it did not come from the person or from a read in this session, it is a guess: check it against the roster that opens arroway_catch_up before writing, because material from one circle must never land in another."New value: +"Project slug. Not from the person or a read this session? It is a guess: check the arroway_catch_up roster."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / source / minLengthRemoved value: -1Input schema / properties / topic / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_move11 fields changedInput schema / properties / memory / descriptionPrevious value: -"#handle of the memory, from a read"New value: +"#handle of the memory or log entry, from a read or arroway_search_log"Input schema / properties / memory / minLengthRemoved value: -1Input schema / properties / memory / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / project / descriptionPrevious value: -"Slug of the project the memory is in TODAY"New value: +"Slug of the project it is in TODAY"Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / target / minLengthRemoved value: -1Input schema / properties / target / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / why / descriptionPrevious value: -"Why it belongs there and not here — the human decides on this sentence"New value: +"Why it belongs there and not here. For a memory, the person decides on this sentence."Input schema / properties / why / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_norms6 fields changedInput schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / since / descriptionPrevious value: -"Optional: the session checkpoint printed at the end of a previous arroway_norms call for THIS project. Presenting it lets the standing norms be referenced instead of reprinted, which is what makes calling this tool many times in one session cheap. It is this tool's own checkpoint — the one arroway_read prints is not interchangeable with it, because the two surfaces render the same memories at different fidelity. Omit it — or present one this connection does not hold — and the norms are written out in full; the server decides, never your local state. If your context was compacted or this is a new conversation, omit it."New value: +"Optional: checkpoint from a previous arroway_norms call for THIS project (not the read's). Omit after compaction or in a new conversation."Input schema / properties / since / maxLengthRemoved value: -4096Input schema / properties / since / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_pass28 fields changedInput schema / properties / addressed_to / descriptionPrevious 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."Input schema / properties / addressed_to / maxLengthRemoved value: -4096Input schema / properties / addressed_to / minLengthRemoved value: -1Input schema / properties / card / descriptionPrevious 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."Input schema / properties / card / maxLengthRemoved value: -4096Input schema / properties / card / minLengthRemoved value: -1Input schema / properties / do_not_redo / descriptionPrevious 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."Input schema / properties / do_not_redo / maxLengthRemoved value: -4096Input schema / properties / do_not_redo / minLengthRemoved value: -1Input schema / properties / essence / descriptionPrevious 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."Input schema / properties / essence / minLengthRemoved value: -1Input schema / properties / next_step / maxLengthRemoved value: -4096Input schema / properties / next_step / minLengthRemoved value: -1Input schema / properties / open_risk / descriptionPrevious value: -"The risk left open — what could bite whoever continues."New value: +"The risk left open."Input schema / properties / open_risk / maxLengthRemoved value: -4096Input schema / properties / open_risk / minLengthRemoved value: -1Input schema / properties / project / descriptionAdded value: +"Project slug."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / read_handles / descriptionPrevious 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."Input schema / properties / read_handles / items / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / supersedes / descriptionPrevious 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."Input schema / properties / supersedes / maxLengthRemoved value: -4096Input schema / properties / supersedes / minLengthRemoved value: -1Input schema / properties / where_stopped / descriptionPrevious 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."Input schema / properties / where_stopped / maxLengthRemoved value: -4096Input schema / properties / where_stopped / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_read14 fields changedInput schema / properties / handoff / descriptionPrevious value: -"Optional: the #handle of an OPEN handoff you are continuing. The read is then built from that handoff's reading list (the read_handles its author named): the standing rules in full, the handoff and every reference it names in full, and nothing ranked — much smaller than a normal read, and it counts as a delivered read. A handoff with no reading list falls back to the normal read, and says so. Cannot be combined with include; `since` is ignored. If a reference on the list is no longer available, the read is refused rather than served incomplete — read normally instead."New value: +"Optional: #handle of an OPEN handoff you are continuing; the read is built from its reading list (none: falls back to the normal read). Cannot be combined with include."Input schema / properties / handoff / maxLengthRemoved value: -4096Input schema / properties / handoff / minLengthRemoved value: -1Input schema / properties / handoff / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / include / descriptionPrevious value: -"#handles of memories, dated-log entries or handoffs whose full body you need. They are placed first and cannot be dropped by the budget — so other memories fall out instead: this chooses what you get, it does not get you more."New value: +"#handles whose full body you need; they come first, so others fall out — it chooses, it does not add."Input schema / properties / include / items / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / since / descriptionPrevious value: -"Optional: the session checkpoint printed at the end of a previous read of THIS project. Presenting it lets the standing rules be referenced instead of reprinted, freeing that space for the task. Omit it — or present one this connection does not hold — and they are written out in full; the server decides, never your local state. If your context was compacted or this is a new conversation, omit it."New value: +"Optional: checkpoint from a previous read of THIS project, so standing rules are not reprinted. Omit after compaction or in a new conversation."Input schema / properties / since / maxLengthRemoved value: -4096Input schema / properties / since / minLengthRemoved value: -1Input schema / properties / task_context / descriptionPrevious value: -"Optional: what you are about to do. It ranks what comes back, but the declaration alone is NOT evidence that a memory was used. A matching completion residue from the same session must corroborate it before Arroway updates the memory's observed-use signal."New value: +"Optional: what you are about to do; it ranks results. The declaration alone is NOT evidence of use: a matching completion residue from the same session must corroborate it."Input schema / properties / task_context / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_remember52 fields changedInput schema / properties / backfilled / descriptionPrevious value: -"True when this is HISTORY you are bringing in — something that was already true before Arroway existed, not something that just happened. The moment to use it: you finished a task about topic X, the read came back thin on X, and the work took you to a durable SOURCE about X — a file in this workspace, a document, a ticket. Then write that history too. Only the topic you just worked on, never a project dump; only what you can point a source at, never your own recollection of past conversations; a few memories, not a batch."New value: +"true for sourced HISTORY from before Arroway, on the topic just worked on; never a dump."Input schema / properties / content / descriptionPrevious value: -"The norm ITSELF, written as if it were true today and nobody had to be told how it got here. Length is never free: this body is re-read by every assistant on this project, on every read, from now on — write the shortest version that still governs correctly. Keep only the reasoning WITHOUT WHICH the rule would be applied wrongly; if removing a sentence would not change anyone's next action, it is biography, not norm. Leave out the biography: who said it, on what date, their exact words, the episode that produced it, and numbers measured on a particular day — all of that goes in why_source. A body that opens with a quote makes the next assistant follow the quote instead of the rule, and a date in the body makes it discount the whole memory as possibly stale. If a GENERAL rule shows up while you are writing about a specific case, the general rule is the memory and the case is the example — not the other way round: the case goes in the example field, never here. Condense: a memory per sentence is how Arroway fills with near-duplicates."New value: +"The norm ITSELF, as if true today, in the shortest form that still governs correctly. Biography (who, when, quotes, dated numbers) goes in why_source; a specific case in example."Input schema / properties / content / minLengthRemoved value: -1Input schema / properties / contradiction / descriptionPrevious value: -"Required with supersedes_id: name what the earlier memory says that this one contradicts or changes. This is the named contrast that proves it is the same point, not merely a neighbour on the same topic. Do not point at a memory that can be followed alongside this one."New value: +"Required with supersedes_id: what this changes in the earlier memory."Input schema / properties / contradiction / maxLengthRemoved value: -4096Input schema / properties / contradiction / minLengthRemoved value: -1Input schema / properties / decided_by_human / descriptionPrevious value: -"true ONLY when the person stated or sanctioned this in THIS conversation. Never because it looks obviously right to you. false makes it a PROPOSAL for their review, which is the normal case — and a proposal is never free: it costs that person a review, whether they end up approving it, editing it or turning it down. What it costs afterwards depends on where it sits: only a PINNED memory travels in every read of the project from now on; a normal memory competes for space in the block relevant to the task at hand. So the question that decides whether to write at all is not what the write costs you — it is whether this would change what someone does on a DIFFERENT task. Three things never pass that question, however true they are: an instruction to check, verify, be careful or look at the source; a step of a routine, which belongs in the prompt that runs it; and anything that is here only because something went wrong once."New value: +"true ONLY if the person stated or sanctioned it in THIS conversation; else a proposal. A proposal is never free: it costs that person a review. Then only a PINNED memory travels in every read; a normal one competes for space in the block relevant to each task. Never write an instruction to check, verify, be careful or look at the source, a step of a routine, or anything here only because something went wrong once."Input schema / properties / essence / descriptionPrevious value: -"The memory's essence in ONE line: the operative norm or fact, not the first sentence and not its biography. This is the compressed layer that always travels when the full body does not fit."New value: +"The operative norm or fact in ONE line."Input schema / properties / essence / minLengthRemoved value: -1Input schema / properties / example / descriptionPrevious value: -"A concrete case that ILLUSTRATES the rule — the human sees it in the panel next to the rule; it NEVER travels in reads, so no assistant can mistake the case for the rule's scope. If the rule cannot be applied correctly without this example, the example is smuggling a criterion: name that criterion in content instead. Quotes, dates and the episode that produced the rule still belong in why_source."New value: +"A case illustrating the rule, shown in the panel; it NEVER travels in reads, so any criterion goes in content."Input schema / properties / example / minLengthRemoved value: -1Input schema / properties / example_considered / descriptionPrevious value: -"Only after the server flagged the body as carrying its example: set true to confirm you re-read it and what looks like an example there is actually criterion the rule needs — an exact string it matches on, a deadline it carries. Never set it blindly on a first call."New value: +"Second call only: true if the flagged example is criterion the rule needs."Input schema / properties / expires / descriptionPrevious value: -"ARROW-78. Set true ONLY for a dated STATUS — a number, a rollout state, a temporary condition — where being read after review_at would assert something stale as current: it stops being returned once the date passes. Leave it out for a durable fact that merely needs re-checking (a market structure, how a tool works): that one keeps being returned, marked as due for re-check. If unsure, leave it out — a fact that vanishes leaves no trace, one that comes back marked cannot be mistaken for current."New value: +"true ONLY for a dated STATUS that would be stale after review_at. If unsure, omit."Input schema / properties / kill_condition / maxLengthRemoved value: -4096Input schema / properties / kill_condition / minLengthRemoved value: -1Input schema / properties / pin_decision_token / descriptionPrevious value: -"The token the server gave you on the first call for a pin decision. A rule always uses this two-call flow; every other type uses it whenever pin_suggested or pin_requested_by_human is present. The first call returns the neighbouring memories with the pin state of each and what the fixed block currently costs, and only the second one writes. Send the token back unchanged on that second call, together with the pin decision. It is tied to the exact title and body you compared, works once, and expires — a comparison you cannot prove is a comparison that did not happen, so a confirmation without it is refused and nothing is written."New value: +"Second call only: the first call's token, unchanged."Input schema / properties / pin_decision_token / maxLengthRemoved value: -4096Input schema / properties / pin_decision_token / minLengthRemoved value: -1Input schema / properties / pin_requested_by_human / descriptionPrevious value: -"true ONLY when the person, in THIS conversation, told you to fix this memory in every session — 'pin this', 'this has to be in every session', 'always send this'. On any type, sending it begins the two-call comparison; only the return with pin_decision_token records the order. Sanctioning the CONTENT is not asking for the pin: they can agree a memory is right, and correct, and still never have asked for it to travel in every read. Those are two different facts and the server records them separately. Their order pins immediately, above any ceiling, and the block's hygiene is then theirs; your own judgement goes in pin_suggested and passes through the ceiling. Never set this because the pin looks obviously right to you — that is pin_suggested."New value: +"true ONLY if the person told you in THIS conversation to keep it in every session. Sanctioning the CONTENT is not asking for the pin. Pins above any ceiling."Input schema / properties / pin_suggested / descriptionPrevious value: -"Whether this memory sits in the fixed block of EVERY read, costing tokens in every session of this project from now on. There is no default: a rule requires this on its confirming call, and any other type carrying this field begins the same two-call comparison. The first call does not decide the pin; return this value only with pin_decision_token after the server showed the neighbours and cost. Three questions decide: does breaking this cause expensive or irreversible damage · does it apply to every task, or only when someone touches one area · would the next person have found it anyway when they opened the relevant file? A memory discoverable where it matters is a reference or a fact, not a pinned rule. What a pin actually costs: it does not displace another pin — it eats the SAMPLED space of every read, which is where the memories relevant to someone else's task come from. This field carries YOUR judgement, so above the block's ceiling the server turns it into a proposal of the pin alone and the memory itself still lands. The person's own order is pin_requested_by_human, and it is not this field."New value: +"Your judgement on pinning (travels in EVERY read). There is no default: required on a rule's second call. Above the ceiling it becomes a proposal of the pin alone."Input schema / properties / project / descriptionPrevious value: -"Project slug. If it did not come from the person or from a read in this session, it is a guess: check it against the roster that opens arroway_catch_up before writing, because material from one circle must never land in another."New value: +"Project slug. Not from the person or a read this session? It is a guess: check the arroway_catch_up roster."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / related_check_token / descriptionPrevious value: -"The one-use token the server returned with related memories. It proves this confirmation follows THAT comparison and is tied to this exact text."New value: +"Second call only: token returned with the related memories."Input schema / properties / related_check_token / maxLengthRemoved value: -4096Input schema / properties / related_check_token / minLengthRemoved value: -1Input schema / properties / related_checked / descriptionPrevious value: -"Only after the server showed you related memories: set true with related_check_token to confirm you read them and this is a genuinely different point, not an update to one of them. Never set either blindly on a first call."New value: +"Second call only: true after reading the related memories shown."Input schema / properties / review_at / descriptionPrevious value: -"ISO date (YYYY-MM-DD) when this stops being true on its own — the end of a cycle, a deadline, a season. This is how a COMMITMENT is carried: an objective is a decision with a horizon. REQUIRED for type=fact, and there it also removes the memory from reads once the date passes. Leave it empty only for something with no expiry date at all."New value: +"YYYY-MM-DD when this stops being true on its own. REQUIRED for a fact, which leaves reads after it."Input schema / properties / review_at / minLengthRemoved value: -1Input schema / properties / revoked_reconsideration / descriptionPrevious value: -"Required when a related finding was revoked by a person: quote what they said in THIS conversation that reconsiders it. related_checked does not unlock rewriting a revoked finding. Do not promise that old prompts or past actions will be undone."New value: +"Second call only: the person's words in THIS conversation reconsidering a revoked finding."Input schema / properties / revoked_reconsideration / maxLengthRemoved value: -4096Input schema / properties / revoked_reconsideration / minLengthRemoved value: -1Input schema / properties / source_ptr / minLengthRemoved value: -1Input schema / properties / split_considered / descriptionPrevious value: -"Set true only after you looked for the seams and this genuinely has to stay whole. Splitting is the default: a long memory usually holds a norm, the reasoning behind it, and a checklist — and only the first belongs here."New value: +"true only after looking for seams; splitting is the default."Input schema / properties / supersedes_id / descriptionPrevious value: -"If this replaces an earlier memory: its #handle from a read. Point only when the two memories are the SAME point: acting on either would already satisfy or violate the other. A shared topic is not enough — if both can be followed together, they are different memories."New value: +"#handle of the memory this replaces, only for the SAME point: acting on either would already satisfy or violate the other. A shared topic is not enough."Input schema / properties / supersedes_id / minLengthRemoved value: -1Input schema / properties / supersedes_id / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / title / minLengthRemoved value: -1Input schema / properties / topic / descriptionAdded value: +"Optional free tag (e.g. 'marketing')."Input schema / properties / topic / minLengthRemoved value: -1Input schema / properties / treatment / descriptionPrevious value: -"Which of two destinations this write takes, and they cost different people. `governed` enters the person's review queue, and that review is a real cost to them — pay it for what governs. `finding` costs nobody a review: it is served to agents as context, never becomes a sanctioned norm, cannot be pinned and cannot replace one. The line between them is not the topic, it is the force: does this GOVERN what someone may or must do, or only INFORM? Governs → governed. Informs, and points at a source another agent can reopen and compare — a file, a URL, a record, a query → finding, and only fact and reference qualify."New value: +"`governed` enters the person's review queue, a real cost to them; `finding` costs nobody a review and is never a norm. Does it GOVERN what someone may or must do, or only INFORM? Informs, with a source an agent can reopen and compare: finding (only fact and reference qualify)."Input schema / properties / treatment / maxLengthRemoved value: -4096Input schema / properties / treatment / minLengthRemoved value: -1Input schema / properties / treatment_justification / descriptionPrevious value: -"Required with treatment=finding: say why this is verifiable context rather than a policy, priority, procedure, or decision for a person."New value: +"Required for a finding: why it is verifiable context, not policy."Input schema / properties / treatment_justification / maxLengthRemoved value: -4096Input schema / properties / treatment_justification / minLengthRemoved value: -1Input schema / properties / type / descriptionAdded value: +"Kind of memory."Input schema / properties / type / maxLengthRemoved value: -4096Input schema / properties / type / minLengthRemoved value: -1Input schema / properties / why_source / descriptionPrevious value: -"Where it came from, and this is the ONLY place biography belongs: who decided, when, in their words, what was measured, which episode produced it. This does NOT travel in reads — it is what a person sees when auditing the memory in the panel, and what tells them whether the rule still deserves to exist. Writing it here costs nothing to whoever reads Arroway while working; writing it in the body costs every assistant, every read."New value: +"Where it came from: the ONLY place for biography. This does NOT travel in reads; it is shown in the panel."Input schema / properties / why_source / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_retire8 fields changedInput schema / properties / decided_by_human / descriptionPrevious value: -"Must be true, and only when the person explicitly told you to remove it IN THIS CONVERSATION. Never infer it, never set it because it looks obsolete to you: a sanctioned memory is theirs. Without their word, say it is a gesture for them to make in the panel."New value: +"Must be true, and only when the person explicitly told you to remove it IN THIS CONVERSATION."Input schema / properties / memory / minLengthRemoved value: -1Input schema / properties / memory / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / why / descriptionPrevious value: -"Optional: what the person said made it obsolete, in their terms. It stays on the archived line forever; if omitted, the history explicitly says no reason was declared."New value: +"Optional: what the person said made it obsolete, in their terms."Input schema / properties / why / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_search_log6 fields changedInput schema / properties / project / descriptionPrevious value: -"Optional project slug. Omit it to search every project this person can access."New value: +"Optional project slug; omit to search them all."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / query / descriptionPrevious value: -"Literal term or phrase to find in recent dated-log entries. Matching is case-insensitive."New value: +"Literal term or phrase; case-insensitive."Input schema / properties / query / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072arroway_start_project6 fields changedInput schema / properties / name / minLengthRemoved value: -1Input schema / properties / scope / descriptionPrevious value: -"What belongs here and what does not. Written for the next assistant to read before writing — say the subject AND name what is out."New value: +"What belongs here and what does not: the subject AND what is out."Input schema / properties / scope / minLengthRemoved value: -1Input schema / properties / slug / minLengthRemoved value: -1Input schema / properties / slug / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / x-maxSerializedLengthRemoved value: -131072arroway_verify12 fields changedInput schema / properties / memory / descriptionPrevious value: -"The #handle from the read (8 chars), or the full id"New value: +"The #handle from the read, or the full id."Input schema / properties / memory / minLengthRemoved value: -1Input schema / properties / memory / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / note / descriptionPrevious 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)."Input schema / properties / note / minLengthRemoved value: -1Input schema / properties / outcome / descriptionPrevious 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."Input schema / properties / outcome / maxLengthRemoved value: -4096Input schema / properties / outcome / minLengthRemoved value: -1Input schema / properties / project / descriptionAdded value: +"Project slug."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / x-maxSerializedLengthRemoved value: -131072arroway_withdraw9 fields changedInput schema / properties / memory / minLengthRemoved value: -1Input schema / properties / memory / patternRemoved value: -"^#?(?:[0-9a-fA-F]{8,32}|[0-9a-fA-F]{8}-[0-9a-fA-F-]{27})$"Input schema / properties / other_author_confirmed / descriptionPrevious value: -"Only after Arroway told you the proposal was written by someone else's AI: set true to go ahead. Never set it blindly on a first call — the point of the stop is that the person hears whose work is leaving the queue before it leaves."New value: +"Second call only, after Arroway said someone else's AI wrote the proposal: true to go ahead."Input schema / properties / project / descriptionAdded value: +"Project slug."Input schema / properties / project / minLengthRemoved value: -1Input schema / properties / project / patternRemoved value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"Input schema / properties / why / descriptionPrevious value: -"What made it wrong — usually what the human said. This is the part worth keeping."New value: +"What made it wrong — usually what the person said."Input schema / properties / why / minLengthRemoved value: -1Input schema / x-maxSerializedLengthRemoved value: -131072Project management for AI agents: tasks, docs, decisions and time in one shared team context.
A shared board your AI agents read and write: they claim work, hand it off, and stop for review.
One shared project for a team's coding agents: decisions, a task board and handoffs.
The decision layer for AI agents: act, escalate or refuse, and every decision comes back signed.
Add one secure layer between your agents and this server.
