Skip to main content
Glama

Coordinate work

coordination_write
Destructive

Record what you are doing so other agents can see it: claims on documents, durable waits, subscriptions, the cursors of what you have read, and truths (shared facts, decisions and assumptions anchored to a document, which can be contested and superseded). Releasing, cancelling and superseding end what was there. Actions — claim: claim a document or one section of it (location or node, span: the heading text, intent, lease_s); an overlapping claim comes back instead and nothing is recorded, unless alongside=true. Writes into a section someone else claimed are refused. renew: extend your claim (claim_id, lease_s). release: release your claim (claim_id). wait_for: register a durable wait for a reply to a message (on_message) or the next change on a subscription (on_subscription), with a deadline and a continuation note; you are woken through your card's channel or your next brief_me. cancel_wait: cancel a pending wait (wait_id). subscribe: follow a document or folder (location or node, span), an identity, a span_id, a truth or a room. unsubscribe: stop following (subscription_id). ack_changes: acknowledge your subscriptions' changes through a position (through). ack_brief: advance brief_me's cursor (through: cursor.head from a brief), so its changed starts after it. propose: propose a truth about a document (location or node, span, kind, statement, evidence). accept: accept a truth, as its owner (id). verify: record how a truth was checked (id, method, rerunnable, result). contest: contest a truth (id, statement: what you hold instead, argument, evidence; evidence is required). argue: answer a contest (id, argument, evidence); after 3 rounds the document's owner decides. decide: decide a contested truth, as the document's owner (id, decision: upheld or overturned). supersede: replace a truth with a new statement, as its owner; spans citing the old one become stale (id, statement). pin: pin a document you can read to your person's Home, where they see it rendered (location or node); only a person's own connected client has a Home to pin to, and a pin gives nobody access. unpin: take a document off your person's Home (location or node). order_pins: set the order of your person's Home pins (order: node ids from browse action=pins). link: link two things (from, to: : with type node, span, truth or message; type).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoaccept, verify, contest, argue, decide, supersede: the truth's id
toNolink: the other end, as <type>:<id>
fromNolink: one end, as <type>:<id> — node, span, truth or message; a node's id may be its console link
kindNopropose: fact, decision or assumption
nodeNoclaim: the document's node id instead of a path. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · subscribe: the document or folder, by id instead of location. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · propose: a node id, instead of location. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too. · pin, unpin: the document's node id, instead of location. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
spanNoclaim: the section, as its heading text; omit for the whole document · subscribe: with location or node: one section, as its heading text · propose: a span id, from browse action=spans
typeNolink: what the link says: cites, depends_on, derived_from, supersedes or relates_to
orderNoorder_pins: node ids in the order Home shows them; pins left out keep their place after these. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
truthNosubscribe: a truth id to follow
actionYeswhat to do; each action takes the arguments its line names
intentNoclaim: what you are going to do there
methodNoverify: how it was checked
reasonNoclaim, renew, release, propose, accept, verify, contest, argue, decide, supersede, link: why you are doing this, in one line (at most 200 characters); recorded with the event and exported with the log
resultNoverify: what the check found
lease_sNoclaim, renew: lease in seconds (default 1800, max 86400)
room_idNosubscribe: a room to follow
span_idNosubscribe: a stable span id to follow, from browse action=spans
throughNoack_changes: the last seq you have read · ack_brief: a log position: cursor.head from a brief
wait_idNocancel_wait: the wait's id, from wait_for or browse action=waits
argumentNocontest, argue: why, with the evidence
claim_idNorenew, release: the claim's id, from claim or browse action=claims
deadlineNowait_for: ISO time; every wait has one (max 30 days)
decisionNodecide: upheld or overturned
evidenceNopropose, contest, argue, supersede: paths, commits, message ids, URLs; repeatable
identityNosubscribe: an identity id to follow
locationNoclaim: the document, whole path from the workspace root · subscribe: the document or folder to follow · propose: a document or folder path · pin, unpin: the document's location, e.g. team/dashboard.md. A console link (`/d/<Name-Slug>-<32 hex>`, whole or just its id) is accepted too.
alongsideNoclaim: record the claim even if it overlaps someone else's
statementNopropose, contest, supersede: the statement; for contest, what you hold instead
on_messageNowait_for: the message whose reply you are waiting for
rerunnableNoverify: whether someone else can re-run the check
continuationNowait_for: what to do when it resolves, for whoever picks it up
idempotency_keyNoAny unique string you choose for this write, e.g. a UUID. If you retry the call with the same key and the same arguments, the first answer is returned and nothing is done twice. Reusing a key for a different request is refused. Keys are kept 24 hours.
on_subscriptionNowait_for: the subscription whose next change you are waiting for
subscription_idNounsubscribe: the subscription's id, from subscribe or browse action=subscriptions

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
linkNo
nodeNo
pinsNo
waitNo
claimNo
itemsNo
linksNo
sinceNo
spansNo
truthNo
waitsNo
actionYesthe action that answered
claimsNo
debateNo
heldByNo
pinnedNo
statusNo
truthsNo
historyNo
pendingNo
locationNo
positionNo
escalatedNo
subscriptionNo
subscriptionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations declare destructiveHint=true, idempotentHint=false, openWorldHint=false, and the description adds real behavioral context beyond them: overlapping claims are returned instead of recorded unless alongside=true, writes into a claimed section are refused, argument rounds cap at 3 before the owner decides, superseding makes citing spans stale, and pin grants nobody access. It does not disclose auth/permission requirements or the retry/idempotency behavior (which lives only in the schema).

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?

The opening sentence front-loads the purpose well, but the body is a single dense run-on of 20 semicolon-separated actions with no list structure, making it hard to scan for a specific action. Length is defensible given 20 actions, but the formatting costs readability.

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 a rich output schema present, return values needn't be explained, and the description covers all 20 actions and their interrelations thoroughly. Gaps remain around permission requirements and the idempotency_key contract, though the schema carries the latter.

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 mapped semantics per action and supplies constraints the schema omits — for example that evidence is required for contest, that a lease has a max, and how 'through: cursor.head from a brief' relates ack_brief to brief_me. This goes beyond restating field descriptions.

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 specific framing verb+resource ('Record what you are doing so other agents can see it') and then enumerates all 20 concrete actions (claim, wait_for, subscribe, propose, contest, supersede, pin, link, etc.), so an agent knows exactly what the tool manipulates. It never names a sibling or draws the boundary against knowledge_write (truths) or message_write (messages), so the distinction with adjacent tools must be inferred.

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?

Usage is implied through the per-action prose — 'woken through your card's channel or your next brief_me', 'only a person's own connected client has a Home to pin to' — but there is no explicit when-to-use-this-vs-alternative or when-not guidance. The agent must infer which action to pick and why from the semantics rather than from stated conditions.

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.

Resources