arroway_importBring 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. |
Changes observed during successful MCP inspections.
Input schema / additionalPropertiesRemoved value: -falseInput 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: -131072Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations by disclosing two real behavioral traits: every imported item is downgraded to a proposal regardless of what the pack asserts, and the import is atomic — any malformed part aborts the whole thing. It stops short of noting permission requirements, pack size limits, or how proposals are surfaced afterward.
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 short sentences, front-loaded with the action, then the proposal guarantee, then the failure mode. No filler and the emphasis caps land on the two facts an agent must not get wrong.
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 tool with a nested pack object and no output schema, the description covers origin, side effects, and failure semantics adequately. It could say what an agent gets back (created proposal count or identifiers) so it can confirm the import, but nothing essential 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% and the schema already explains that `pack` is the document itself (no URL fetching) and that `project` should be checked against the `arroway_catch_up` roster if guessed. The description adds nothing param-specific, 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 (import a memory pack into a project) and names its sibling `arroway_export` as the producing counterpart, so the round-trip pairing is unambiguous. The caps on INTO and PROPOSAL frame the scope immediately.
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 link to `arroway_export` tells the agent where packs come from, and the proposal framing tells it this is the ingestion path rather than `arroway_remember`. It never states when NOT to use it, e.g. that single memories should go through `arroway_remember` or that existing pinned items are untouched by this route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.