Skip to main content
Glama
Sign In

Arroway

by app.arroway
OverviewDiscussionsAdmin

What the team already decided, and a map of what else it knows

arroway_norms
Read-only

Call in the seconds BEFORE you tell the person something or propose a course of action: returns what is already decided AND THEN A MAP of the titles and handles. 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.

Input Schema

NameRequiredDescriptionDefault
draftNoText you will publish, ending with one line in the project's language on what it claims, recommends and names.
sinceNoCheckpoint from a previous arroway_norms call for THIS project, so standing rules are not reprinted.
projectYesProject slug the claim is about.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / draft / description
      Previous value: -"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."New value: +"Text you will publish, ending with one line in the project's language on what it claims, recommends and names."
    • changedInput schema / properties / since / description
      Previous value: -"Optional: checkpoint from a previous arroway_norms call for THIS project (not the read's). Omit after compaction or in a new conversation."New value: +"Checkpoint from a previous arroway_norms call for THIS project, so standing rules are not reprinted."
  2. Changed1 schema field changed
    • addedInput schema / properties / draft
      Added 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"
+}
  3. Changed6 schema fields changed
    • removedInput schema / properties / project / minLength
      Removed value: -1
    • removedInput schema / properties / project / pattern
      Removed value: -"^[a-z0-9]+(?:-[a-z0-9]+)*$"
    • changedInput schema / properties / since / description
      Previous 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."
    • removedInput schema / properties / since / maxLength
      Removed value: -4096
    • removedInput schema / properties / since / minLength
      Removed value: -1
    • removedInput schema / x-maxSerializedLength
      Removed value: -131072
  4. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare this is a safe read (readOnlyHint true, destructiveHint false), so the bar is lower. The description does add non-obvious context: that it returns an index/map rather than full content, and that a follow-up arroway_read does not get cheaper. However, the shape of the returned map is left opaque, and 'in the project's language' handling is only implied.

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

Conciseness3/5

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

It is short, but front-loading is muddled: the imperative 'Call in the seconds BEFORE...' delays the actual return statement, and the ALL-CAPS 'AND THEN A MAP' interrupt reads as emphasis rather than structure. The sentences are compressed to the point of ambiguity.

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?

There is no output schema, so the description must carry return semantics; it says decisions plus a map of titles and handles but never explains what a handle is or how to use the map afterwards. For a read tool with three parameters it is workable but leaves the agent guessing about the response layout.

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 all three parameters are already documented, and the baseline is 3. The description adds one genuine usage cue for `draft` (pass text you intend to publish), but says nothing extra about `since` beyond what the schema states about checkpoints and suppressed standing rules.

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

Purpose4/5

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

The description states a concrete return: what is already decided plus 'a MAP of the titles and handles'. That is specific enough to tell it apart from arroway_read, which is explicitly described as returning a mapped item 'in full'. The phrasing is idiosyncratic ('Call in the seconds', 'A MAP') but the resource and output are identifiable.

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

Usage Guidelines5/5

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

It gives explicit timing ('BEFORE you tell the person something or propose a course of action') and a separate trigger ('Before publishing text for others, pass it as draft'). It also names the alternative arroway_read and states the exact selection rule: use it 'to be sure, never to pay less'.

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