Skip to main content
Glama

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

arroway_norms
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
draftNoOptional: 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.
sinceNoOptional: checkpoint from a previous arroway_norms call for THIS project (not the read's). Omit after compaction or in a new conversation.
projectYesProject slug the claim is about.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
      +}
  2. 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
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavior beyond that: the returned map is titles/handles only, arroway_read does not make the read cheaper, and passing draft returns whatever it touches in full. It stops short of describing pagination or response shape.

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 key trigger is front-loaded and each sentence carries distinct information (what it returns, how it differs from arroway_read, the draft use case). The all-caps 'AND THEN A MAP' and dash-heavy phrasing make it denser and harder to scan than it needs to be.

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

Completeness4/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 correctly carries the return explanation: decisions plus a map, and full content for anything a draft touches. It covers all three parameters' intent and the sibling trade-off, leaving only minor gaps like map format or result limits.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning for draft that the schema does not: what the draft touches comes back in full, which explains why you would pass it. It also reinforces the checkpoint semantics of since by warning to omit after compaction or in a new conversation.

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 the resource concretely: it returns what is already decided (the project's and this person's own) plus a map of titles and handles of everything else. It distinguishes itself from arroway_read by noting that read only guarantees a mapped item in full. The verb is diffuse ('call in the seconds BEFORE...') and the name 'norms' is opaque, but the returned content is unambiguous.

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 triggers ('before you tell the person something or propose a course of action', 'before publishing text for others, pass it as draft') and names the alternative (arroway_read include) with the exact decision rule: use it to be sure, never to pay less. That is when-to-use plus alternative plus trade-off, so the agent can route without guessing.

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.