Skip to main content
Glama
Sign In

Arroway

by app.arroway
OverviewDiscussionsAdmin

Export this project's norms as a memory pack

arroway_export
Read-only

Export what a project has DECIDED, as a pack for another project. Only sanctioned, live memories travel: a FINDING never was one, so findings stay and the answer tells you how many did.

Input Schema

NameRequiredDescriptionDefault
nameYesWhat this pack IS, in a few words: the first thing the other side reads.
topicNoOptional: export only the memories carrying this topic.
projectYesSlug of the project whose norms you are exporting
descriptionNoOptional: who it is for, what it assumes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed10 schema fields changed
    • changedInput schema / properties / description / description
      Previous 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."
    • removedInput schema / properties / description / maxLength
      Removed value: -4096
    • removedInput schema / properties / description / minLength
      Removed value: -1
    • changedInput schema / properties / name / description
      Previous 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."
    • removedInput schema / properties / name / minLength
      Removed value: -1
    • removedInput schema / properties / project / minLength
      Removed value: -1
    • removedInput schema / properties / project / pattern
      Removed value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"
    • changedInput schema / properties / topic / description
      Previous 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."
    • removedInput schema / properties / topic / minLength
      Removed value: -1
    • removedInput schema / x-maxSerializedLength
      Removed value: -131072
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare the read-only, non-destructive profile, so the description doesn't need to repeat it. It does add real behavioral content beyond them: only sanctioned, live memories are included, FINDINGS are excluded by rule, and the response reports how many findings stayed behind — useful for predicting the result of the call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the purpose, no filler. The second sentence is slightly riddling ('a FINDING never was one, so findings stay and the answer tells you how many did') but it still carries the exclusion rule and the return hint compactly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Read-only annotations plus full schema coverage carry most of the burden, and the description hints the response reports excluded findings. What remains unclear is the shape of the pack itself — whether it is returned inline or materialized, and what fields it contains — which matters for an export tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each of the four parameters is already documented (name, topic filter, project slug, description). The description adds conceptual context about what is exported but does not clarify how 'topic' narrows the set or what the pack-level 'name'/'description' fields control, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Export what a project has DECIDED, as a pack for another project') and narrows scope to decided/sanctioned memories rather than all content. It never names the obvious sibling arroway_import as its counterpart, so the differentiation is implied rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'As a pack for another project' implies the transfer-between-projects scenario, which gives the agent a usable trigger. There is no explicit when-not guidance, no mention of arroway_import as the reverse operation, and no stated prerequisites (e.g. project must exist, must have sanctioned memories).

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

All Arroway toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources