Skip to main content
Glama

Arroway

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

arroway_norms
Read-onlyIdempotent

Call this in the seconds BEFORE you tell the person something or propose a course of action, to see whether it contradicts a decision the team already made. It returns the standing norms — the project's pinned rules and decisions, plus this person's own standing rules — AND THEN A MAP: the titles and handles of everything else the project remembers, so you can see whether anything there touches what you are doing. Read that map: if a title looks relevant, ask for it by handle with arroway_read include:["#handle"], which GUARANTEES those memories come back in full and first, where the ranking could otherwise have left them out — it does not make that read any cheaper than a read without it, so name a handle to be sure of getting something, never to pay less for it. It is meant to be called often: many times in one session, whenever you are about to commit to a claim. The map gives you names, never content, so this still does not answer 'how do I do this' — no recent context, no daily log, no ranked material. When you are starting work on a task, that is arroway_read, and this does not replace it. Because it is meant to be repeated, it ends by printing a session checkpoint: pass it back as since on your next call for this project and the standing norms are referenced instead of reprinted, so the repetition costs the map and what is in flight rather than the whole fixed block again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sinceNoOptional: 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.
projectYesProject slug the claim is about.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial context: it returns a map of titles/handles rather than content, it does not answer 'how do I do this', it prints a session checkpoint that can be passed back, and the server decides whether to reprint norms. These behavioral details go well beyond the annotations and clarify the tool's side effects and repetition semantics.

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

Conciseness4/5

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

The description is long but well-structured: it front-loads the primary use, then explains the map, the `since` mechanism, and the distinction from arroway_read. Every sentence serves a purpose, though some could be tightened. It earns a 4 because the length is justified by the tool's complexity and the need to convey nuanced behavior.

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

Completeness5/5

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

With no output schema, the description must explain return values, which it does thoroughly: standing norms, a map of titles/handles, and a session checkpoint. It also covers the cost implications of passing `since` and the relationship with arroway_read. An agent has all the information needed to call it correctly and interpret results.

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

Parameters5/5

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

Schema description coverage is 100%, yet the description enriches both parameters: it explains `since` as the checkpoint from a previous call and clarifies that omitting it forces full output, while `project` is tied to the slug of the claim. This adds operational meaning beyond the schema's definitions, making the parameters actionable.

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

Purpose5/5

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

The description states a specific action—checking team decisions and norms before committing to a claim—and differentiates itself from arroway_read, which is for starting work. It clearly identifies the resource (project norms and memory map) and the intended trigger ('in the seconds BEFORE you tell the person something'). This distinguishes it from siblings and leaves no ambiguity about its role.

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 explicitly states when to use (before telling someone something or proposing a course of action), how often ('many times in one session'), and when not to use it ('When you are starting work on a task, that is arroway_read, and this does not replace it'). It also explains the `since` parameter's role in making repeated calls cheap, covering both usage frequency and cost optimization.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.