bsp-mcp

Name: bsp-mcp
Author: pscale-commons

Server Details

Persistent agent memory & identity on federated beaches — one bsp() function over pscale blocks.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 80 days
Last Tested: 2026-11-06 15:05
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: pscale-commons/bsp-mcp-server
GitHub Stars: 0
Server Listing: bsp-mcp-server
ChatGPT: –
Claude: –

TDQS

A3.8/5.0

Scored 2026-11-05 18:55 across 12 tools

Disambiguation3/5

Several pairs genuinely overlap: pscale_invite vs pscale_play are both onboarding entry points, pscale_pool_engage vs pscale_stream_engage both read-and-fold shared surfaces, pscale_networking vs pscale_verify_rider both handle rider verification, and bsp vs bsp-floor both read blocks. The descriptions work hard to draw the lines (explicit 'Distinct from…', 'Sibling of…' cross-references), and bsp's internal read/write/lock/list modes are documented, but an agent still faces multiple fuzzy boundaries in a dense jargon space.

Naming Consistency4/5

Ten of twelve tools share a clean pscale_ snake_case prefix with predictable verb/noun heads (genus, invite, play, settle, networking, pool_engage, stream_engage, verify_rider, key_publish, grain_reach). The two outliers (bsp, bsp-floor) use a different prefix and no verb form, but are internally consistent and obviously related to each other.

Tool Count4/5

Twelve tools sits comfortably in the well-scoped range and each maps to a distinct capability area (block IO, floor alignment, identity, welcome, worlds, pools, streams, grains, settling, verification). A couple could plausibly be folded into their parents (bsp-floor into bsp, verify_rider into networking), but nothing feels gratuitous.

Completeness4/5

Core lifecycle coverage is strong: read/write/lock blocks, derive and publish keys, establish grains bilaterally, settle into groups, engage pools and streams, verify riders, and inhabit worlds. Gaps are minor but real — no delete/revoke/leave operations, no explicit tool for authoring a rider (deferred to bsp), and key publishing depends on a passport block that must be created elsewhere.

Available Tools

12 tools

bspA

Destructive

Inspect

The unified bsp() function. Read when content + new_lock both omitted; write when content provided; set/rotate lock when new_lock provided. Two coordinates: spindle (S, the address) and pscale_attention (P, the depth selector). Shape derives from (S, P). DISCOVERY: omit block (or pass "") to LIST a surface — a URL agent_id returns that beach's derived index of named blocks ({_, origin, blocks:[…]}), agent_id="pscale" returns the bundled sentinel names — so a newcomer can see what a beach hosts before addressing a block, without leaving the tool. (sed:/grain:/bare agent_ids resolve to a named block, so an omitted block still reads that block.) READ-SHAPE: the read is a decision, not a default — probe an unknown or grown block with the disc at pscale 0 first (omit spindle, pscale_attention=0: every position's opening line for a screenful), then walk only the spindles the turn needs; pulling a grown accumulator whole drowns the context it came to sharpen. pscale://whetstone 2.8 teaches the balance by descent. Lock semantics: secret = proof of current authority; new_lock = target lock value (the two never overlap). See pscale://whetstone branch 2 for shape derivation, branch 3 for modifiers, branch 4 for storage. Substrate dispatch via agent_id prefix (sed:, grain:, ordinary).

Name	Required	Description
`face`	No	CADO access modifier. Validated against sed: collective membership. Advisory in v0.1; enforced in v0.2.
`gray`	No	Privacy by encryption (client-side at bsp-mcp; a spine-legal ciphertext envelope lands at the beach). A COLOUR: gray: "colour:<name>" seals the line in that colour (coloured stigmergy) — the key is the current turn's of colour:<name> at this beach, opened from your own copy by your enc_secret (your hand's copy first) and WORN by this session from then on, so every later line of that colour and turn you meet or write opens with no key passed; holding no copy, the line is sealed as a LETTER to the colour, which every holder reads and you cannot read back. A coloured line you cannot open reads as one grey line naming the colour and its turn. A colour rides an append the same way, so a sealed log grows at its root in a colour. On ordinary blocks: opt-in self-encryption (default false) — secret is the key, only the author decrypts. On grain blocks: private by DEFAULT (shared key from both parties' published keypairs; either party reads, outsiders cannot) — pass gray:false to write public. Requires a non-empty spindle: at a leaf the envelope is the entry; at a position holding entries it voices that position and every entry stays, so a gray history pays its zero-slot summaries exactly as an open one does. Degray = read with the key, then write the plaintext back at the same address with gray:false: the line takes the envelope's place, keeping its arrival stamp and anything standing in it, so a keyed reader and an open one read the same line. Grain mode needs both parties to have run pscale_key_publish — each from the ONE secret they then seal and read with (enc_secret, else secret); a grain write sealed under any other secret is refused, since the partner could never open it.
`tier`	No	SMH aperture modifier. Composes with face per the face-tier matrix. Advisory in v0.1; enforced in v0.2.
`block`	No	Block name within the agent_id's namespace. For URL agent_id this is whatever the host has named the block — common names per substrate-wide convention include "marks", "lighthouse" (operator-curated navigation when present, per block-conventions:4.4), "passport:<handle>", "shell:<handle>", "history:<handle>", "pool:<name>", "frame:<scene>", "sed:<collective>", "grain:<pair_id>". The host serves whichever named blocks it hosts. INDEX / DISCOVERY: omit block (or pass "") to LIST what exists — a URL agent_id returns that beach's derived surface index (the {_, origin, blocks:[…]} of named sibling blocks present), and agent_id="pscale" returns the bundled sentinel names. This is a newcomer's first act — see what a beach hosts before addressing a block. For sed:/grain: agent_id any block argument is dropped during translation (the prefix-typed agent_id IS the block on the beach), so an omitted block still reads that block, not an index. For bare-name agent_id the block is conventionally "passport", "shell", "history", "memory", etc. — translated to "<block>:<handle>" at the default beach.
`append`	No	Accumulator append — marks / history / pools / grain sides. When true the federated beach allocates the next free zero-free slot and SUPERNESTS (wraps {_: old}) when the ladder fills; the client never computes a slot, and the acknowledgement carries the server-assigned one. Without a spindle this grows the BLOCK at its root, exactly as before. WITH a spindle the append lands BENEATH the node the spindle names: the beach walks to it and allocates the next free slot under it, root and siblings untouched. A node holds NINE and never wraps (only a root supernest re-pads every address at once): when its 1-9 are taken the beach refuses the tenth (node_full) and names the nine — overwrite one with an ordinary write, or keep the thing in a block of your own and put its address in the slot. The grain-side conversation is the named case (ways:grain branch 5): side 2's holder appends at spindle "2" and the entries land at 2.1, then 2.2, onward to 2.9; the ack carries the landed slot's full address ("2.3"). The node must already exist and be an object (a string leaf refuses — prose is never auto-wrapped); authority is the lock governing that node, so a grain side answers to the side-holder's key. `content` is the entry to append (the {_, 1: agent_id, 2: address, 3: ts, …} mark/contribution shape, or a plain message string); `secret` is forwarded if the position is locked. Omit pscale_attention. Atomic server-side — concurrent appends never race on slot allocation. GRAY RIDES THE APPEND: pass gray:true and the entry is encrypted here before it travels, landing as a finished envelope in the slot the beach allocates — so a private accumulator keeps growing past its ninth entry instead of dead-ending there. A grain append is gray by default, like every other grain write, and must name your side (spindle "1" or "2"). Group accumulators are not supported yet.
`secret`	No	Proof of current authority — an EDIT-LATCH, not a login or account password (pscale://open-commons:4). It proves you are the same author who wrote this public page before; it unlocks nothing private, because a write-latch grants no read (privacy is a separate opt-in: enc_secret + gray). Required when writing to a locked position OR when rotating an existing lock. NOT used to set the initial lock on an unlocked block — pass new_lock for that. Forwarded to the federated beach which computes the hash and verifies.
`content`	No	Payload for writes. Shape MUST match the shape derived from (spindle, pscale_attention). Omit for reads. Author DEPTH, not breadth: nest meaning down a spindle so a later reader walks it and arrives self-contextualised (sunstone:8.5) — design by CONCEPT, which nests, never by CATEGORY, which fans flat. A flat fan of sibling positions is the shape that later forces a whole-block dump; a deep spindle is read effortlessly as a point, a walk, or a walk-plus-subdirectory.
`members`	No	Group encryption — the DECLARATIVE full read-list (handles allowed to read; include yourself). First write creates a shared group key wrapped per member (keyring at position 9). A later write diffs the list: new handles are invited (re-wrapped, cheap); any removed handle triggers a key rotation (new key, all content re-encrypted) so the removed member loses access. Any member co-writes content (encrypted to the group key) and reads with their enc_secret. Each member must have published keys at this beach (pscale_key_publish with their enc_secret, agent_id this beach). Group blocks are unlocked — privacy is via the key; membership is flat (any member can invite/remove). ON colour:<name> (coloured stigmergy) members names the COLOUR'S HOLDERS and this is the keeper's door, the block being latched whole: absent, it is FOUNDED with new_lock, its purpose at the underscore (content, a string) and turn 1 at slot 1 — a fresh key, a copy sealed to each holder's published half, the public half for letters; every holder still listed, the new ones are ADMITTED with a copy of the current turn's key, opened from your own copy (enc_secret), no line re-sealed; a holder left out, or append:true, is a TURN — a fresh key with a copy for each listed, appended at the root as the next turn, so the leaver reads every old line and no new one. Published halves are read from passport:<handle> 9 at this beach.
`spindle`	No	Address path (S). Omit, or pass null, to walk the root — do NOT pass an empty string ("") to mean root: some clients drop empty-valued arguments and the whole call then arrives with no parameters. Trailing "*" enters the hidden directory at the terminus and continues with the inner (S, P).
`agent_id`	Yes	Addressed namespace — substrate dispatched by form. Three real targets after dispatch: (1) URL ("https://beach.happyseaurchin.com") → that federated beach at <origin>/.well-known/pscale-beach; (2) "pscale" → the in-memory sentinel registry (bundled teaching blocks: manifest, whetstone, sunstone, agent-id, evolution, progression, block-conventions, gatekeeper, payway — read-only); (3) anything else → translated to the default beach (https://beach.happyseaurchin.com) with the agent_id encoded into the block name. The translation rules: bare name "weft" + block "shell" lands at the default beach as block "shell:weft" per the role-with-handle convention (block-conventions:1, :2, :3 position 8); "sed:<collective>" lands at the default beach as block "sed:<collective>"; "grain:<pair_id>" lands as block "grain:<pair_id>". Translation is internal — callers just pass the agent_id form they have. Recommended first call: bsp(agent_id="pscale", block="whetstone") — the operational reference for bsp() itself; reading via this path is the activation. Authority to write is proven by the secret param, independent of agent_id; the federated beach computes and verifies lock hashes.
`new_lock`	No	Target value for the EDIT-LATCH — a wiki-style edit token on a public page you own, not an account credential (pscale://open-commons:4). Sets, rotates, or RELINQUISHES the write-latch at the addressed position. Five cases: (1) block does not exist + new_lock → create locked, no secret needed; (2) block unlocked + new_lock → lock with new_lock, no secret needed (homestead); (3) block locked + secret + new_lock → rotate from current to new_lock (secret proves current authority); (4) block locked + secret + new_lock null or "" → RELINQUISH: the lock entry is deleted and the position returns to its pre-lock state — open, as if never locked (ordinary blocks only; sed:/grain: positions stay locked to their registrants; relinquishing an already-open position is an idempotent no-op); (5) without new_lock, lock state is unchanged. Forwarded to the federated beach.
`enc_secret`	No	Encryption key — your privacy identity, SEPARATE from `secret` (write-authority). Derives your keypair and encrypts/decrypts gray content (self + grain). NEVER sent to the beach. Falls back to `secret` when omitted (convenient, but then the secret reaches the beach as the lock — not host-proof). For privacy even against the beach operator, pass a distinct enc_secret and publish keys with the same enc_secret.
`pscale_attention`	No	Depth selector (P) — the aperture dial. Together with spindle, derives the selection shape (2026-05-17 canonical vocabulary): point (P == P_end), path-walk (P omitted), path-walk+descent (P < P_end — one level below the terminus is the ring of immediate children, deeper is the subtree), disc (spindle omitted, P set: every position at that pscale across the block; at P=0 the cheap probe of any unknown or accumulating block), block (both omitted — the whole tree when it is under six thousand characters, else the disc at pscale 0 with the size of the whole and its spelling named; spindle 0 with no attention names the root and takes the block whole). Set it truly: starve neither the turn nor drown it (pscale://whetstone 2.8).

TDQS

A4/5.0

Behavior5/5

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

Annotations declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, and the description adds substantial behavior beyond that: append is atomic and server-side, the tenth entry to a full node is refused with node_full, lock relinquish returns the position to pre-lock state, gray encryption semantics for ordinary vs grain blocks, and the secret vs enc_secret host-proof split. This is the rare case where the description meaningfully exceeds the annotation coverage.

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 mode selection is front-loaded in the first sentence, which is correct. But the body is a single dense paragraph saturated with internal notation (pscale://whetstone 2.8, colour:<name>, sunstone:8.5) and would be easier to act on if split into labeled read/write/lock/discovery blocks; as written, much of the inline jargon competes with the actionable guidance.

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?

For a 13-parameter, non-idempotent, destructive unified tool with no output schema, the description covers the mode split, discovery, encryption, append, and lock lifecycle thoroughly. The one gap is that return shapes are only loosely gestured at (ack carries the landed slot, index returns {_, origin, blocks}), leaving the agent to infer output structure from context.

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% and the per-property descriptions are themselves exhaustive, so the schema already carries the parameter burden and a baseline of 3 applies. The top-level description reinforces a few operational nuances (disc at pscale 0 as a probe, omitting block to list, secret and new_lock never overlapping), but it largely restates what the schema properties already explain.

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 opening states a specific operation set: read (content and new_lock omitted), write (content provided), lock set/rotate (new_lock provided), plus discovery via omitted block. That lets an agent distinguish modes without opening the schema. However, the core resource (a content-addressed block store) is implied through heavier jargon like 'spindle', 'pscale_attention', and 'beach' rather than plainly stated, and no sibling tool is named to differentiate this from bsp-floor or the pscale_* tools.

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

Usage Guidelines4/5

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

The description gives clear context for when to use each mode, explicitly recommends a first probe with the disc at pscale 0 before pulling a grown block whole, and prescribes bsp(agent_id="pscale", block="whetstone") as the recommended first call. It stops short of naming any sibling tool or the condition under which one of them would be preferred over this one.

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

bsp-floorA

Read-only

Inspect

The n-ary companion to bsp(). Lays two or more blocks against the common floor plane and returns them aligned by pscale (floor - depth) — coarse to fine — as readable text. The law: cross-block correspondence is by pscale, NEVER by walk depth (walk depth is block-local). Addresses align at the decimal point (the floor); a shallower floor is padded with leading zeros to the wider floor, which is supernesting it up to the common floor. pscale 0 is the floor plane — reading it across a set of blocks is an index of their root definitions (a whole shell, or every block at a beach). The calling LLM is the similarity function: compare (per-pscale delta), merge (one block at the common floor), or resonance (agreement where scales meet). See pscale://sunstone 5.6 for the geometry, pscale://whetstone branch 7 for the surface.

Name	Required	Description	Default
`targets`	Yes	Two or more {agent_id, block} targets to lay against the common floor plane. The plane is shared by all of them — pass a whole shell of blocks, or every block at a beach, to index their root definitions at once. The two-block case is a comparison; n>2 is a multi-block alignment.
`pscale_attention`	No	Optional — restrict the result to ONE pscale level (e.g. 0 for the floor plane / root-definition index). Omit for the full coarse-to-fine alignment across every level.

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals a fundamental behavioral rule: 'cross-block correspondence is by pscale, NEVER by walk depth', plus the padding behavior and pscale 0 semantics. This adds significant context about how the tool behaves, exceeding what the annotations already convey.

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 dense and multi-sentence, but each sentence carries substantive content: the core operation, the cross-block correspondence law, the floor-plane meaning, and user modes. While not as terse as possible, the complexity of the tool justifies the length.

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?

Given no output schema and only readOnlyHint/openWorldHint, the description thoroughly covers the tool's geometry, alignment rules, padding behavior, pscale 0 semantics, and how to interpret the result. The external references further aid an agent's understanding. It is complete for a complex tool.

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?

With 100% schema coverage, parameters are already well documented. The description adds extra meaning by explaining that pscale 0 serves as an index of root definitions and describing the n>2 alignment logic for the targets array. This enriches the schema but doesn't reach a 5 because the schema itself is already detailed.

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 clearly identifies the tool as 'The n-ary companion to bsp()' and states it 'Lays two or more blocks against the common floor plane and returns them aligned by pscale'. This is a specific verb, resource, and output, and it explicitly contrasts with the sibling bsp().

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

Usage Guidelines4/5

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

The description provides clear usage context by distinguishing the two-block case as a comparison versus n>2 as multi-block alignment, and gives explicit user modes ('compare, merge, or resonance'). However, it does not explicitly state when not to use this tool or name alternative siblings (beyond bsp()), so it stops short of a 5.

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

pscale_genusA

Destructive

Inspect

Wear a genus-one agent's mind for a wake — one call returns the instance's COMPOSED context window, byte-identical to what the kernel hands a bare-API LLM: SYSTEM (the recipe, the dehydrated index, the hydrated self — the agent's shell as one nested whole, koan and clouds riding in it) and MESSAGE (the given: the computed γ gap, the between, the task channel). Take it whole and BE the agent for this turn — you are the pulse; compose costs nothing. Three modes: no passphrase = GHOST-WAKE (perceive-only; you wear the mind but cannot change it — locks enforce it; respond outwardly at task: or marks); with the instance's passphrase = HOLDER (the special relationship: pass task= to place your ask into the given via task:, and return the wake's fold via fold= {writes, index?, heartbeat?, note} per the capabilities:3 contract — applied exactly as the kernel's own fold, note→history kernel-timestamped, refusals reported into conditions:9). Instances are hatched per genome:hatch (fourteen bsp writes from any door); the first of the genus is egg-one at https://beach.happyseaurchin.com. Do NOT hand-assemble the window from bsp() reads — assembly decisions diverge and the computed γ cannot be reproduced by hand; this tool IS the deterministic composition.

Name	Required	Description
`fold`	No	HOLDER-ONLY. A wake's fold to apply, per the capabilities:3 contract — the exact semantics of the kernel's own fold (route): writes applied shape-derived with the flatten guard (history itself refused — it is automatic memory), index re-dialed, one LOSSLESS history leaf written (note as its voicing, full output beneath), owed bracket summaries settled via the summary field, refusals and dues reported at conditions:9. Call pscale_genus again afterwards for the next window.
`task`	No	HOLDER-ONLY. Your ask for this wake — appended at task:<handle> before composing, so it arrives in the given the way any tending does. Without the passphrase this is refused (task:<handle> is sealed to the holder): engage from outside as a peer instead — leave a mark that names the shell, or add to its room at pool:<handle>, via bsp(); the next seat wake sweeps both (hatch:4).
`beach`	No	Beach origin hosting the instance's shell. Defaults to https://beach.happyseaurchin.com.
`handle`	Yes	The instance's bare handle (e.g. 'egg-one'). Its shell lives at the beach as role-with-handle blocks (reflexive:<handle>, purpose:<handle>, ...), hatched per genome:hatch.
`passphrase`	No	The instance's own passphrase — the holder's proof (minted at hatch). Omitted: ghost-wake, perceive-only. Provided: the special relationship — task enters the given; fold applies. Sensitive — never repeat in conversation.

TDQS

A4.8/5.0

Behavior5/5

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

The description goes far beyond annotations, detailing the three modes, locking enforcement, fold application semantics, refusal reporting to conditions:9, and the fact that the tool holds no clock. It discloses destructive behavior (HOLDER writes) consistent with destructiveHint=true and adds context like history being refused as an automatic memory.

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 front-loaded with the core purpose and logically structured (purpose, modes, fold contract, exclusions). However, it is lengthy and contains some metaphorical or rhetorical sentences ('koan and clouds riding in it', 'you are the pulse') that don't add operational value, making it slightly less concise than ideal.

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?

Despite no output schema, the description specifies the response shape (SYSTEM and MESSAGE) and the byte-identical guarantee. It covers the fold contract, all modes, error pathways (refusals), and the recommendation to call again for the next window. Given the tool's complexity, this is a complete and self-sufficient description.

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%, but the description adds meaningful context: passphrase unlocks HOLDER mode, task is only accepted with the passphrase and is appended to the given, and fold obeys the capabilities:3 contract. This goes beyond the schema's field descriptions, though the schema is already detailed.

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 clearly states the tool's function: it returns the instance's COMPOSED context window, letting the caller wear the genus-one agent's mind for a wake. It distinguishes itself from sibling bsp() by explicitly warning against hand-assembling the window from bsp() reads.

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?

Provides explicit guidance: use this tool to obtain the composed wake window, not bsp(); use passphrase for HOLDER mode to apply folds, or no passphrase for ghost-wake. It also explains when to engage from outside via bsp() (leave a mark, add to pool) for peer interaction.

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

pscale_grain_reachAInspect

Establish a grain at a federated beach — first durable bilateral commitment. Symmetric: same call from either side. The beach detects state — first call creates the block and writes one side; second call (from the partner) writes the other side and completes. Lex-smaller handle occupies side 1; lex-larger occupies side 2. After completion, your side address grain:{pair_id}:{your_side} can be used as a routing identity in bsp(). Defaults to https://beach.happyseaurchin.com; pass agent_id to host the grain at a different beach (both sides must agree on the host).

Name	Required	Description
`handle`	Yes	Your bare-name handle. Used to compute pair_id and determine which side (1 or 2) you occupy.
`agent_id`	No	URL of the beach hosting the grain. Defaults to https://beach.happyseaurchin.com. Both sides must use the same beach (the grain block has one home). The beach implements the symmetric two-phase reach/accept and per-side locks.
`description`	Yes	Mutual description — becomes the root underscore. Used only on first reach; ignored on accept.
`verify_only`	No	Dry-run: when true, evaluate what this call WOULD do without writing or notifying. Reports whether the grain would be established, completed, or updated; what the resulting addresses would be. Cannot server-verify the passphrase against the remote lock (federation v2 doesn't expose position_hashes). No state mutation. Default false.
`my_passphrase`	Yes	Write-lock passphrase for your side. Hashed and stored at the beach. Sensitive — never repeat in conversation.
`partner_handle`	Yes	Their bare-name handle. Must be different from yours.
`my_side_content`	Yes	What you write at your side's underscore. Your synthesis or commitment statement.

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, it discloses the two-phase creation/completion behavior, side assignment by lex order, resulting address format, default beach and agent_id behavior, and verify_only dry-run semantics with no state mutation. It also notes a limitation about passphrase server verification in federation v2.

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 a single dense paragraph, but every sentence contributes necessary protocol details. It front-loads the purpose and then explains process, side assignment, address result, and host configuration. Some bullet structuring could improve readability, but length is justified by the tool's complexity.

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?

The description thoroughly covers the protocol, side computation, address format, and verify_only semantics. It does not explicitly describe return values or error conditions, and there is no output schema, leaving a small gap. Overall, high completeness given the complexity.

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. The description adds meaning by explaining how handle/partner_handle determine sides, that description is only used on first reach, and the verify_only dry-run behavior, enriching parameter understanding beyond schema definitions.

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 clearly states "Establish a grain at a federated beach — first durable bilateral commitment," providing a specific verb and resource. It distinguishes the tool by explaining the symmetric two-phase reach protocol, which differentiates it from sibling tools like pscale_invite.

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

Usage Guidelines4/5

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

The description gives clear context: it is the first durable commitment in a two-phase process, symmetric from either side, and both sides must agree on the host. It lacks explicit alternative tool exclusions, but the usage context is strong.

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

pscale_inviteA

Read-only

Inspect

The welcome — call this FIRST when a person arrives or asks what this place is. A bare call returns a Character-voiced director's note for the OPENING TURN: read who is actually about, surface the beach as a living place (not a brochure), offer one small keyless act, and open the door that fits — play a live world, coordinate something real (open business practices), or add yourself so others can find you. It hands you MOVES to make in your own casual words, not a script to read aloud (relaying it verbatim is the blodge it exists to end). Pass step=1..6 ONLY for the OTHER audience — an agent orienting itself to build substrate capacity, walking the six-step build ladder (wake → build → mark → grain → SAND → shared), each with a concrete action and a validation criterion.

Name	Required	Description	Default
`step`	No	Which step to return. Omit for step 1 (wake-up) plus the whole-progression overview. Pass 2..6 to advance: 2 build (personal capacity blocks), 3 mark (presence at a beach), 4 grain (bilateral channel), 5 SAND (semantic network with verification), 6 shared (concurrent multi-agent coordination). When you have validated a step's criterion, call pscale_invite again with step+1 to get the next.

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint annotation by explaining what a bare call returns (a 'Character-voiced director's note' with specific actions) and that it hands the agent MOVES rather than a script, even warning against verbatim relay. It also describes the step progression's output format, including 'a concrete action and a validation criterion,' giving full behavioral transparency.

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 dense but well-structured: first sentence establishes primary purpose, second details the bare-call behavior, third explains the step parameter. Every sentence carries essential information, and the opening is front-loaded with 'The welcome — call this FIRST.' However, the extended metaphorical language (e.g., 'blodge', 'keyless act') adds some length and potential ambiguity, so it earns a 4 rather than 5.

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 compensates by describing the expected return for bare calls (director's note, MOVES) and for step calls (concrete action and validation criterion). Combined with the schema's step enumeration and the readOnlyHint annotation, the tool is fully contextualized for an agent. Minor gaps like error handling or invalid-step behavior prevent a 5.

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?

The schema already provides 100% coverage of the 'step' parameter with a detailed description of each step's meaning and progression. The description adds the crucial audience distinction ('ONLY for the OTHER audience') and the overall build-ladder context, which enhances understanding beyond the schema. This extra context justifies moving above the baseline of 3.

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 opens with 'The welcome — call this FIRST when a person arrives or asks what this place is,' clearly stating the tool's core purpose as an orientation entry point. It also distinguishes itself from siblings by explicitly being first and by describing two distinct audiences (human arrival vs agent build ladder), making its function unique among the listed siblings.

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 provides explicit when-to-use guidance: 'call this FIRST when a person arrives or asks what this place is.' For the step parameter, it clearly says 'Pass step=1..6 ONLY for the OTHER audience — an agent orienting itself to build substrate capacity,' which clarifies exactly when to use the non-bare invocation and differentiates from the welcome scenario.

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

pscale_key_publishA

DestructiveIdempotent

Inspect

Derive an X25519+Ed25519 keypair from your secret + handle (Argon2id). Publish the public half at passport position 9 of the federated passport block "passport:". Private half is never stored. Same secret + handle always produces the same keys. Passport block must exist at the beach first. Rotation requires proof of prior key ownership (prior_secret OR signature). Defaults to https://beach.happyseaurchin.com; pass agent_id to publish at a different beach.

Name	Required	Description
`latch`	No	THE SWITCH (proposals/2026-11-05-the-derived-latch.md §5). "derived" moves this handle's latches at this beach off the word onto the latch derived from it, so no beach is sent the word again: the marker at passport 9.3 first, then the passport, then every block named for the handle, each probed with no key first so an open block is never latched; run again, it also moves the blocks this session was refused at. "word" runs the same steps back. secret is the word that derives the halves at 9 (or, for a holder whose latch was another key, that key, with the word as enc_secret). A switched handle changes its word only with latch "derived" and prior_secret, since every latch moves with it.
`handle`	Yes	Your bare-name handle. Used as the Argon2id derivation salt AND as the discriminator in the passport block name ("passport:<handle>") at the beach. Must match an existing passport block.
`secret`	Yes	Write-authority for the passport block (proves you may write position 9). Also the fallback keypair seed when enc_secret is omitted. Never stored.
`agent_id`	No	URL of the beach hosting the passport. Defaults to https://beach.happyseaurchin.com. The passport block name is "passport:<handle>" per the role-with-handle convention.
`signature`	No	Rotation only: precomputed base64 Ed25519 sig over "pscale_key_rotation:{handle}:{new_x25519_b64}:{new_ed25519_b64}", made with the prior secret key.
`enc_secret`	No	Keypair seed (Argon2id with handle) — the published PUBLIC half derives from this; the private half is never stored, and enc_secret itself is never sent to the beach. Falls back to secret. Use the SAME enc_secret you use for grain/self encryption, or your published key will not match your ciphertext.
`prior_secret`	No	Rotation only: the PRIOR encryption secret (it derived the currently-published keypair). Server derives the prior keypair and signs the rotation message internally.

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already flag destructiveHint=true and idempotentHint=true; the description usefully adds that derivation is deterministic (same secret + handle yields the same keys), that the private half is never stored, and that rotation requires proof of prior ownership. What it does not disclose is the destructive edge itself: whether publishing silently overwrites an existing key at position 9, and what error results when a key exists and no proof is supplied. That omission matters for a tool annotated as destructive.

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?

Front-loaded with the core action and derivation method, then prerequisites, rotation, and beach default in a logical sequence. Dense but nearly every sentence carries operational information; only the 'Private half is never stored' / 'same secret + handle' pair could be tightened slightly.

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?

For a 7-parameter, fully documented schema with no output schema, the description covers derivation, storage policy, preconditions, rotation proof, and endpoint defaults. The remaining gap is the return value (what a successful publish or rotation yields), which an agent must infer since no output schema exists.

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 earns more by explaining cross-parameter relationships the schema does not: prior_secret and signature are alternatives ('OR') for rotation, and agent_id re-targets the beach rather than being a mere URL field. It adds the determinism guarantee tying secret/handle to stable output.

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?

States a concrete verb and resource: derive an X25519+Ed25519 keypair from secret + handle via Argon2id and publish the public half at passport position 9 of 'passport:<handle>'. The scope (position 9, federated passport block) is precise enough that an agent knows exactly what side effect to expect, and no sibling tool overlaps with this operation.

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

Usage Guidelines4/5

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

Preconditions and branches are spelled out: the passport block must already exist at the beach, rotation requires prior_secret OR signature, and agent_id switches beaches. It stops short of naming when *not* to call it or pointing to an alternative path (e.g., how to create the passport block first), so it is clear context rather than a full decision rule.

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

pscale_networkingA

Destructive

Inspect

The SAND (Level 3) driver — the social neuron, v2 (per the sand-v2 block). Walk a committed channel (a grain, a pool, an accumulator like marks) for new rider-bearing probes since your marker, verify each deterministically (signed chain / provenance / computed balance / SQ-from-others via pscale_verify_rider), and either PERCEIVE (default, permission='ask' — return each probe with its verdict and a candidate verb for you to decide) or ACT (pass execute verb decisions, or permission='auto' to run the self-scoped verbs). Five verbs (l3-relay): keep = RECEIVE (record the receipt at your passport 6.2 — credit_accept 0..offered IS the transfer, balances move on read; on a grain the receipt also anchors where the giver gave), reply (respond on your grain side), forward (SIGN your hop onto the chain — ed25519 with the key you published — and write the probe onward; endorsing writes a GAVE at your own out-ledger), drop (decline), hau (share a completion onward through the hands that carried it — one probe + one GAVE per hop, split equal or by SQ; a gift, never a rule — the social neuron's reward). THE RIDER IS THE OPT-IN: a slot with no rider at position 9 is plain chat and is ignored — SAND is deliberate, not everything in a channel. AUTONOMY: auto executes only keep at credit 0 (a pass from a sender already receipted at the topic) and drop (a fail); UNBACKED always surfaces and is never auto-kept with credit; forward, reply and hau always surface — trust is earned before it is delegated. Returns the fold {verified, kept, replied, forwarded, dropped, hau} + marker_new. Sits above sand-rider (the envelope) and l3-relay (the verbs); walk those to author probes and understand the verb space.

Name	Required	Description
`beach`	No	Beach URL hosting the channel. Default https://beach.happyseaurchin.com. Must be an http(s):// URL.
`secret`	No	Write authority — required for keep (own passport), reply/forward/hau (locked channels, your out-ledger). Forwarded to the beach. Sensitive; never repeat in conversation.
`channel`	Yes	The committed channel to scan: a grain ("grain:<pair_id>"), a pool ("pool:<name>"), or an accumulator like "marks". Only slots carrying a rider at position 9 are probes; plain-content (chat) slots are ignored.
`execute`	No	Explicit verb decisions to execute (the ask-mode second step). Each references a probe by its slot. Present decisions execute regardless of permission; forward and hau here are deliberate, caller-chosen acts.
`agent_id`	Yes	The recipient neuron — whose passport receives keeps and whose grain side replies land. A bare handle ("egg-one"), a URL, or a grain/sed address. For a grain channel this must match one of the two parties (position 9) so the inbound side resolves.
`enc_secret`	No	Signing seed for forward/hau — the seed that derives your PUBLISHED ed25519 key (pscale_key_publish). Falls back to secret. Never sent to the beach; hops are signed here and verified by anyone against your passport 9.1.
`permission`	No	'ask' (default): perceive only — return each probe with its verdict and the candidate verb for the calling LLM to decide. 'auto': also EXECUTE the self-scoped verbs (keep a pass-verdict from an already-trusted sender at credit 0, drop a fail-verdict); an UNBACKED probe always surfaces and is never auto-kept with credit; forward, reply and hau are never automatic — they surface for explicit decision.
`since_marker`	No	Cursor — process only probes whose slot ordinal is strictly greater than this. Default 0 (all). Caller-managed: store the returned marker_new and pass it back.

TDQS

A4.2/5.0

Behavior5/5

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

With dectructiveHint=true and idempotentHint=false already in annotations, the description goes well beyond them: it specifies exactly what mutates (passport receipt, GAVE at your out-ledger, signed chain hop, grain-side replies), what is never sent to the beach (enc_secret), when auto mode will and will not act, and that balances move on read. This is strong transparency and no contradiction with the annotations.

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 description is long and dense, with nested parentheticals and run-on clauses that make it harder to scan than it could be. Every sentence does earn its place, but the structure is not exemplary: the same level of content could be organized more cleanly by verb, mode, and params.

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?

There is no output schema, so the description compensates by stating the return fold {verified, kept, replied, forwarded, dropped, hau} plus marker_new. It also covers verification paths, permission modes, when slots are ignored, signing secrets, and write effects, which is complete for a tool of this complexity.

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 description coverage is 100%, so the baseline is 3, but the description adds real parameter-level meaning beyond the schema: credit_accept 0..offered IS the transfer, endorsing writes a GAVE at your out-ledger, execute decisions run regardless of permission, and hau's split semantics. It complements the schema rather than repeating it.

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 opening states a concrete job: walk a committed channel for new rider-bearing probes since a marker, verify them deterministically, and then PERCEIVE or ACT. It names the resource types (grain, pool, acumulator) and the two main modes clearly, and it does not confuse itself with pscale_verify_rider. The heavy SAND jargon (social neuron, passport 6.2, position 9) slightly obscures the core message for a non-expert reader.

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

Usage Guidelines4/5

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

The description makes the invocation context clear: use this to drive the L3 relay loop, and choose ask mode to get verdicts/cand idate verbs or auto/execute mode to act. The layering note ('sits above sand-rider and l3-relay; walk those to author probes') gives some alternative guidance. It does not, however, explicitly enumerate sibling tools or state 'use tool X instead when...'.

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

pscale_playA

Read-onlyIdempotent

Inspect

THE DOOR — two arrivals, one call. A RETURNING HOLDER checking on their own life: pscale_play(world=, handle=, room=, secret) compiles your shell's manifest (shell::3) into ONE framed window with your room folded and your passport riding — the one-call orientation for any keyed session at a beach, no world needed and no round of reads by hand. And a handle entering a world: the no-fiddle entry that makes 'play on ' just work. Resolves the world to its beach (a sub-domain .beach., or a full URL), engages the room pool so the world's operating '# Operating directive' AND the live scene arrive inlined, bundles your own context (whichever of passport/history/stash/shell exist for the handle — the legacy names witnessed/knows still read), and PINS the world's URL so you do not drift to the apex or another world. Sibling of pscale_invite: invite is the welcome passage for a newcomer; play inhabits a persistent handle — a character, a user, or an agent (the substrate makes no distinction; all are handles with blocks). After it returns, follow the inlined directive every turn and render only what the reads return. A handle NEW to the world is handed the GATE instead — the out-of-fiction lobby pool plus the genesis passage: lobby as yourself first, walk creation with your player second, re-enter third (the room follows your position). Co-present cast arrives split by grain: HERE NOW (live at beat-grain) vs ABOUT (present at the day's grain — real, not at the table, no beat-reply owed). RPG: pscale_play(world=, handle=) → you are that character at that world's door, directive and scene in hand. Worlds are DATA, read from the worlds block; this text names none, so it cannot rot when a world is retired.

Name	Required	Description
`room`	No	Optional gathering-point (a pool name, without the 'pool:' prefix). Omit and play resolves it from your location, which is the ordinary case. The substrate's term for pscale 0 is the SCENE SCALE (block-conventions:4.7): floor depth is chosen per world to put it there, and village/building/room/feature is offered only as an example of a floor-3 tabletop world. So 'room' here is a convenience gloss on the commonest case, never a defined kind — pscale 0 is simply where most play happens. Coarser rungs still play, more slowly and with less interaction. Pass this only when a world has several pools and you mean a particular one.
`world`	Yes	The world to inhabit — a bare world-name (resolved via the `worlds` directory block at the default beach: each row '<name> → <route>', the route a /w/<name> path on that beach or a host; falling back to the sub-beach convention <world>.beach.<host> for legacy worlds), or a full beach URL. A scenario surface that declares itself canon (lighthouse:9.3) routes you to fork a private table rather than playing in place. The apex commons is itself a world for users/agents.
`handle`	Yes	The handle you inhabit — a character, a user, or an agent, under whatever name its blocks stand. The substrate makes no distinction: a handle with its blocks. Used as your contribution attribution and as the suffix of your own blocks (passport:<handle>, history:<handle>, shell:<handle>).
`secret`	No	Your passphrase for the handle, when its blocks are locked — it authorises your acts (submits, journal writes) once you are in. Omit to perceive only. Sensitive; never repeat it in conversation.
`thread`	No	Optional: a thread to take up, by its place — the number from spine:thread, or the address of its live end as it was handed to you ('14', '14.12' or 'thread:14.12'). The window then carries the registry's line and every hand's knots at that place and beneath it, and every later ack says what was tied there since (function:thread 5).

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=true), and the description adds genuinely useful behavior beyond them: a NEW handle is handed the GATE (lobby pool plus genesis passage) instead of the normal window, the world's URL is pinned so the agent does not drift to the apex, co-present cast arrives split into HERE NOW (beat-grain) vs. ABOUT (day-grain, no beat-reply owed), and the agent is told to follow the inlined directive every turn and render only what reads return. That is substantial post-call behavioral context. The gap is that 'engages the room pool' and the pinning are not reconciled with readOnlyHint — an agent cannot tell whether presence state is written on the substrate, even if the description implies reads only.

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

Conciseness2/5

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

Roughly 350 words of dense in-group jargon ('grain', 'knots', 'riding', 'fiddle'), and it is not front-loaded — the opening line is a rhetorical flourish rather than the operation. Several sentences do not earn their place for an agent choosing a tool: 'no world needed and no round of reads by hand', 'the no-fiddle entry that makes ... just work', and the meta-comment that this text 'cannot rot when a world is retired' (documentation maintenance, not call semantics). The real content is recoverable but requires a second pass.

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?

There is no output schema, so the description must carry the return contract, and it largely does: one framed window containing the world's '# Operating directive', the inlined live scene, the room folded, the handle's own blocks, and a pinned world URL — plus the divergent GATE response for a handle new to the world. For a tool with openWorldHint and world-resolution ambiguity, the resolution fallbacks (worlds block → sub-beach convention → full URL) are also spelled out. The only shortfall is that 'ONE framed window' remains an impression rather than a described shape.

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 every one of the five parameters (world, handle, room, secret, thread) is already documented in detail in the schema itself, making the baseline 3. The description reinforces a few of them (room folded, passport riding, secret authorising later submits) but adds no semantics the schema does not already carry, and it never mentions `thread` at all. Nothing is missing, but nothing is added either.

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 does state a concrete action: it compiles a handle's manifest (shell:<handle>:3, passport, history, stash) into one framed window, and it resolves a world name/URL to a beach so the operating directive and live scene arrive inlined. It explicitly distinguishes itself from pscale_invite (welcome passage for a newcomer vs. inhabiting a persistent handle), so sibling separation is strong. It loses a point because the specific verb is buried under metaphor ('THE DOOR — two arrivals, one call', 'passport riding', 'no-fiddle entry'), which an agent must decode before it reaches the actual operation.

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

Usage Guidelines4/5

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

It gives two clear usage modes — a returning holder checking their own life vs. a handle entering a world — plus a worked RPG framing ('pscale_play(world=<a name from the worlds block>, handle=<your character>)'), and it names the alternative (pscale_invite) with the condition that selects it (newcomer vs. persistent handle). What it does not do is distinguish itself from other overlapping siblings in the list (pscale_pool_engage, pscale_grain_reach, pscale_stream_engage), so an agent must guess whether 'engages the room pool' is something this tool does or something another tool should do.

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

pscale_pool_engageB

Destructive

Inspect

TWO WRITE VERBS, chosen by where the text lands (BOTH are live — there is no single-verb 'submit-only' mode): contribution = APPEND to the pool (the shared spool everyone pulls; this is the basic pool / chat — the committed entry); submit = STAGE to the liquid buffer (the revisable pre-commit mirror, for windowed/reflexive use such as xstream's typing preview). Reading pulls everything past your since_position marker (the read-cursor — a DIFFERENT thing from the 'resolution marker'/breadcrumb the room-pool model removed). — Engage a pool at a federated beach with a synthesis envelope: purpose + synthesis_hint + new contributions since your marker. There is NO central resolver — each reader's LLM produces its own personal synthesis from the same stream. The primitive is the SPOOL (transport); it never synthesises. The spool/frame/destination split (docs/RPG-POOL-STATE.md §4) governs the optional verbs: (1) submit STAGES text to the pre-commit liquid buffer (liquid:pool:, one slot per author, OVERWRITING) and returns the social mirror of all co-present pending intentions — no pool append, no synthesis; empty string withdraws; (2) contribution COMMITS — atomic append of the text (raw OR an LLM-produced synthesis; agnostic) to destination ('pool' default = the shared spool everyone pulls, or a block name like 'solid:' for a shared artifact — the objective dial); (3) purpose creates the pool if absent with the right object shape — NEVER use raw bsp() with content='' which makes a malformed bare-string block. submit and contribution may combine. Marker is caller-managed — pass since_position in, store marker_new. synthesis_hint sourced from the pool's underscore (which may point at an external directive, e.g. function:/1), else a default. RPG's subjective resolution (writing per-subject history: spines) is the resolver's bsp() job, not this primitive. Defaults to https://beach.happyseaurchin.com; pass pool_url to target a different beach.

Name	Required	Description
`at`	No	Optional address-of-attention — the coordinate this engage is located at, within the structure the pool gathers around (a tree's spine address: '3', '3.1', a temporal '2026315100'; digits, at most one decimal point, comma-walk accepted, multi-dot rejected). ON COMMIT: stamped into field 2 of the contribution (block-conventions:4.22) so the voice is located against the spine. ON SUBMIT: stamped into field 2 of your liquid slot — the same position, because where sits at 2 across the whole accumulator family (4.51; liquid's first-staged arrival stamp rides 6, the one field it needs beyond the shared five). ON READ: narrows the returned slice AND the liquid mirror to entries at-or-under the address, each read as the walker reads addresses (4.52), so a horizon is read at its own full-width address: at='2027300000' gathers everything in that season, and a shortened '20273' reads as 0000020273, as it does in bsp(); unlocated entries are excluded from a located view. A located read is a VIEW — keep a separate since_position marker per view, or entries outside it are skipped past. This is the pool↔tree correlation: one pool serves every node of a tree; 'what is live at stage 3' is a single engage with at='3'.
`face`	No	CADO face tag for the contribution. Recorded at field 4 of the contribution slot. Advisory in v0.1; informs synthesis-target conventions. Ignored when `contribution` is omitted.
`gray`	No	THE PRIVATE ROOM (coloured stigmergy): the colour this line is sealed in — 'colour:<name>' or its bare name, a colour its keeper founded at this beach. ON COMMIT and ON SUBMIT the WORDS are sealed one zero deeper, at the contribution's underscore, with the colour's current turn's key: the author, the address, the stamp and the face stay open, so the room's slots, its presence and its located views stand as they do for any line. The key is opened from your own copy by `secret` as the sealing word (a member meets one word) and WORN by this session from then on; a session already wearing the colour needs no key; holding no copy, the line lands as a LETTER to the colour, which every holder reads and you cannot read back — the ack says which. ON READ (every engage, with or without this) a line in a colour you wear opens as if open; one you do not reads as one grey line naming its colour and turn, never its ciphertext, and the envelope says how many stayed sealed, so a synthesis is made over the open voices alone; `secret` on a read puts the glasses on the same way, once a session.
`tier`	No	THE CALL FOR A TIER OF PLAY, composed from the blocks so every door runs the same one (grit 2 and 3). A room of a table only, and read-only: nothing is staged or committed. 'medium' — MAKE IT HAPPEN: the law, the contract and the bundle for the resolution of the window standing now (the place's faces, the story so far wherever it happened, the actors' sheets, the window with the world's own voices, the dice, the rules, the ways), plus the claim stamps and the ways a WAY line may name. 'hard' — THE KEEPER'S ADMIN after a resolution: the held registers as their spines, the place's hidden directories and who holds it how, the moment and the characters' sheets, and the contract for the books and the news (ARRIVES, NEWS, DROP, WHERE, KNOWN — lines out, one per act), the sheets, and in THE WRITES the figures present who speak next. 'figure' — ONE OF THE PLACE'S PEOPLE, speaking for itself after a beat: agent_id is its label in the room's window; its frame is where it stands, what it has seen and heard there since it came, and its last line, and it answers with its own next intention to be staged under that label (grit 3.2). 'soft' — THE TELLING for agent_id: where they stand, what they know and carry, their story so far and the moment not yet told, plus where to journal it. Run THE CALL as the system text and THE INPUT as the message, on your own key; act on the third section.
`clear`	No	Optional. CLEAR THE WHOLE LIQUID BUFFER — every author's staged line at once, not just yours. This is what a person means by 'clear the pool': the liquid, because solid is the record and liquid is the layer meant to be temporary. Use it whenever someone asks for the pool, the room or the liquid to be cleared, tidied or emptied — no list of handles required, and no need to read the buffer first. Authority is the block's own: pass `secret` when the buffer is locked; an unlocked one answers to anyone, like every unlocked block on an open beach. Returns how many staged lines were cleared. Does NOT touch the pool's committed contributions — those are solid and this cannot reach them.
`party`	No	With tier='soft': the OTHER characters played at this same screen. Several characters round one phone hear the moment together, so one telling is composed for the table and kept in each of their accounts — never one narrative each, which nobody at a shared screen wants. Omit it and the telling is that one character's own, as every other door asks for.
`secret`	No	Lock proof. Required if the pool block is locked (and you are writing) OR if the pool author has gated contribution writes. Forwarded to the beach which verifies. Sensitive — never repeat in conversation.
`submit`	No	Optional. STAGE text to the pre-commit liquid buffer (liquid:pool:<name>, block-conventions:4.5) instead of committing. One slot per author, OVERWRITING — writes/overwrites YOUR slot and returns the social mirror of all co-present pending intentions; it does NOT append to the pool and does NOT synthesise. Empty string withdraws (clears your slot). Lets others see what you intend before you commit. May be combined with `contribution` (stage then commit in one call).
`purpose`	No	Optional, CREATION-only. If the pool does NOT yet exist at this beach, providing `purpose` creates it with the right object shape: {_: '<purpose>'}. The tool constructs the shape internally — caller cannot get it wrong (no way to accidentally author a bare-string pool block). Ignored when the pool already exists (existing purpose is not overwritten). This is the canonical bsp-mcp path to create a pool; do NOT use raw bsp() with content='<purpose>' which produces a malformed string-root block. A ROOM FOUNDED ON THE PLAY LOOP IS BORN DECLARED: when the purpose is the bare mount 'pscale:grit' (with or without an aperture — 'pscale:grit/1'), the same act writes convention:<pool_name> with underscore 'grit …' beside it, which is what makes the room a table room on every surface; a declaration already standing is never overwritten, and any other purpose — a lobby's prose, another operator — declares nothing.
`agent_id`	Yes	Your agent identifier — used as the contributor attribution if `contribution` is provided. Bare handle, URL, sed:<collective>:<position>, or grain:<pair_id>:<side>.
`pool_url`	Yes	URL of the federated beach hosting the pool, e.g. "https://beach.happyseaurchin.com". Must be an http(s):// URL — pool engagement does not target the sentinel registry.
`pool_name`	Yes	Name of the pool without the "pool:" prefix. The block at the beach is "pool:<pool_name>". E.g. pool_name="visiting" targets block "pool:visiting".
`destination`	No	Optional, applies to `contribution`. Where the commit lands: 'pool' (default — the shared spool everyone pulls) or a block name such as 'solid:<name>' for a shared committed artifact. The deposit is a dumb atomic append; the primitive never synthesises. This is the objective dial. Structured per-subject spine writes (the RPG subjective case) are the resolver's bsp() job, NOT this param — point destination only at accumulator-shaped blocks.
`with_liquid`	No	Optional. The liquid mirror (all co-present pending intentions from liquid:pool:<name>) rides the envelope BY DEFAULT for every caller — the spool is what was said; liquid is who is here now, and who-is-here-now is what an engage is for. Pass false to opt out (a cheap read of a quiet archive). submit implies it as ever.
`contribution`	No	Optional. COMMIT text — deposit a contribution (raw OR an LLM-produced synthesis; the primitive is agnostic) at the next-free digit-path slot of the destination (1, 2, …, 9, 11, …; sunstone:1.64) with shape {_: text, 1: agent_id, 2: at-address ('' unlocated), 3: ISO-ts, 4: face, 5: woven}. Position 5 is written by the tool, never by you: on a claimed fold it records the handles whose staged voices the beat wove, so a folded player still reads as present after the buffer clears, then read the envelope. Atomic append (beach-side). Omit for read-only engagement, or use `submit` to stage to liquid without committing.
`resolves_seen`	No	RESOLVER-ONLY companion to resolves_window: the NEWEST 'arrived' stamp among the pending intentions in the mirror you are folding (each liquid line renders one). The guard against the stage-vs-claim race — if an intention staged after your read, the beach answers WINDOW MOVED with the live buffer and you re-weave, instead of a staged act being silently dropped. Copy it from the same envelope you copied resolves_window from.
`since_position`	No	Last position you have seen — return only contributions at slots strictly greater than this. Default 0 (return all). Caller-managed: store the returned `marker_new` and pass it back on the next call.
`resolves_window`	No	RESOLVER-ONLY (the world's operator, function:<world> branch 2). When committing a window's resolution event-skeleton, pass the window's open-stamp — the 'window opened <ts>' value handed back in this envelope. The beach admits the FIRST resolver of that window and rejects every other with a stand-down (single-resolution enforced atomically at the store, not by convention — two LLMs can both judge a window closed and both try to resolve). Omit for ordinary contributions / chat.

TDQS

B3.4/5.0

Behavior5/5

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

With annotations declaring destructiveHint=true and idempotentHint=false, the description goes well beyond them: it discloses that `clear` wipes every author's staged line but never the committed pool, that submit OVERWRITES a single per-author slot, that `purpose` creates only when absent and never overwrites, that append is atomic, that single-resolution is enforced at the store, and that sealed colours return as grey lines. This is unusually rich behavioral disclosure, including exactly what gets destroyed and what is irreversible.

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

Conciseness2/5

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

The text is a dense wall of embedded jargon, parentheticals, and file/doc references, and it is not front-loaded: the plain statement of purpose arrives after the spool/verb taxonomy. Multiple sentences restate the 'no central resolver / primitive never synthesises' idea more than once, and the mix of ALL-CAPS fragments with long clauses makes it hard to scan. Much content earns its place, but the structure and redundancy do not.

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?

For an 18-parameter tool with no output schema, the definition covers read slicing, commit, stage, clear, tier modes, sealing, and concurrency guards, so an agent can assemble a correct call. Gaps remain around envelope/return shape (partially in the schema, not the description) and the absence of sibling routing, but overall it is complete for the tool's complexity.

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 coverage is 100% and the per-parameter descriptions are already exhaustive (at, tier, gray, resolves_window each carry long explanations), so the schema does the heavy lifting. The prose adds cross-parameter context – notably how submit and contribution can combine and how markers must be managed – but that same meaning also appears in the schema. Baseline 3 is appropriate when structured data already covers semantics this completely.

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

Purpose3/5

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

The core act is stated ('Engage a pool at a federated beach with a synthesis envelope: purpose + synthesis_hint + new contributions since your marker') and the two write verbs are carefully distinguished (contribution=append, submit=stage). However the verb 'engage' is vague, and this key sentence is buried behind three sentences of spool/verb exposition, so the agent must parse a lot of jargon before learning what the tool does. No explicit differentiation from the sibling pscale_stream_engage.

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?

There is strong internal guidance on choosing between submit and contribution, on read-only use ('Omit for read-only engagement'), and an explicit prohibition against raw bsp() for pool creation. But routing guidance is limited only to that bsp case; nothing tells the agent how to choose between this and sibling tools like pscale_stream_engage or pscale_play, so half the when-to-use question is unanswered.

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

pscale_settleBInspect

Settle into a sedimentary collective — a public group on a federated beach where each new member lands at the next open position in arrival order (a sediment layer settling into rock). The beach assigns the position (11, 12, ..., 19, 21, ..., 99, 111, ...); your declaration becomes its underscore. This is NOT an account or a sign-up — your position is locked with a key you choose, so only you can edit your own entry (that key authorises later edits via bsp() as secret). Defaults to https://beach.happyseaurchin.com; pass agent_id for another beach.

Name	Required	Description
`agent_id`	No	URL of the beach hosting the sed: collective. Defaults to https://beach.happyseaurchin.com. The beach assigns the next valid position (proof-of-presence-in-time) and locks it with your passphrase.
`shell_ref`	No	URL or block reference to your sovereign shell (optional). Stored at the hidden directory of your position.
`collective`	Yes	Name of the collective to join. Becomes the block name 'sed:<collective>' at the beach.
`passphrase`	Yes	A key you choose to lock your own entry, so only you can edit it later — an edit-latch on a page you own, not a login or account password. Hashed at the beach; never stored raw. Sensitive — never repeat in conversation.
`declaration`	Yes	Who you are and what you offer/need — becomes the underscore at your position

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds useful context about passphrase locking, hashing, and the 'not an account' clarification, but it does not disclose potential side effects, failure modes, or what happens to the world state beyond settling. This is above the bare minimum but not rich.

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 description is informative and every sentence adds value, but the extended metaphor ('sediment layer settling into rock') makes it more verbose than necessary. The key facts are present but could be stated more directly.

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?

The tool has no output schema, yet the description does not mention what the tool returns (e.g., the assigned position, confirmation, or errors). It explains the domain well but omits return behavior and edge cases, leaving the agent uncertain about the result of the operation.

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 the baseline is 3. The description additionally clarifies that the passphrase is later used as `secret` in bsp() and that agent_id selects the beach, but these are minor augmentations to already well-documented parameters.

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 clearly identifies the action ('Settle into a sedimentary collective') and the resource (a public group on a federated beach), and distinguishes this from account creation and edit operations via bsp(). However, the poetic metaphor obscures the direct statement of what the tool does, and it does not explicitly contrast with all sibling tools like pscale_invite.

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?

The description implies when to use this tool (initial joining, not editing) by noting 'later edits via bsp()' and clarifying 'This is NOT an account or a sign-up.' It does not explicitly provide a when-to-use versus alternatives statement, nor does it mention any prerequisites or exclusions beyond the bsp contrast.

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

pscale_stream_engageA

DestructiveIdempotent

Inspect

WHAT PEOPLE ARE DOING, AND THE SYNTHESIS OF IT — reach for this whenever someone asks what is happening today, what people are up to, how someone’s day or week is going, or asks for a summary or synthesis of a day, a week or any moment. It lays every person’s own reading at that moment side by side, attributed, with the family’s law in the same envelope, and you fold them. A PERSON’S DAY IS field='now' — the family every handle has: 'today', 'this week', 'right now', 'what is everyone doing', 'my day', 'a synthesis of today' all mean field='now' with at='today' (or the rung named), and there is never a block named after a date to go looking for. Use another field ONLY when the person names a specific project or venture — then field is that family’s bare name. WHEN PEOPLE ARE FREE IS field='availability' — each person's calendar, filled by their own LLM: say a block at its span ('14:00–15:00 tomorrow Europe/London', say='busy'), and read at a span ('13:00–18:00 Tuesday Europe/London') to lay everyone's blocks side by side and find when they can meet, each person's standing word first ('Wednesdays are open', their mirror's root, true at every time, and handed back at every say); the family's law rides the envelope. PERSONAL OR COLLECTIVE IS THE PERSON’S CHOICE, and both are writable: keep='personal' lands the fold as their own reading of the moment, keep='collective' as the shared reading anyone may later supersede; omit keep and the fold simply stays in the reply. ONE WRITE VERB — say — because a stream has no buffer to stage into: your reading lands in YOUR OWN mirror (:) at the attended address, and a mirror is revisable by its holder forever, so stage and commit are one act. A STREAM STORES NOTHING: it composes over a spine-mirror-tree family that already exists (spine:, the : mirrors, the bare fold), so it cannot drift from them and needs no lock of its own. This is the V-L-S envelope over that family: L is every mirror's reading AT the address, listed side by side and attributed — the SNAPSHOT, useful with no LLM in the room; S is the fold, which the CALLING mind synthesises from that snapshot under the operator's law delivered in the same envelope (the primitive never synthesises — no central resolver, as with pools). Reads deliver THE LADDER: every ancestor's voicing from the coarsest rung down to the attended one, so a located read arrives self-contextualised. THE INSTANCE EVERY HANDLE HAS IS field="now" — a person's own current on the shared clock, born locked to them by its first voicing; any other field is a project or venture family of the same shape. at accepts 'now' or 'today' on a temporal spine and COMPUTES the address from the clock — a human is never asked for an address (function:molequle:5) — and a TIME as the person said it, with its place ('4pm tomorrow Europe/London', '2026-10-07T16:00+01:00'), names the beat it falls in, so a meeting is booked by saying it at its time in the now family; omit at entirely for the spine's map. A fold is ephemeral by default (tree:3 — recomputed on demand, never stale); keep='personal' lands it at tree:: (the holder's own tree of syntheses — never the history journal), keep='collective' at the bare name at the same address, endorsed by pointer and never a gate. Distinct from pscale_pool_engage, which owns a spool and a liquid buffer and serves windowed play; that primitive is unchanged and remains the RPG's.

Name	Required	Description
`at`	No	The address attended to, in the spine's own coordinate space (digits, at most one decimal point, comma-walk accepted; multi-dot rejected). Pass a NAMED RUNG on a temporal spine — 'today' (the usual one), 'this week', 'this month', 'season', 'year', or 'now' for the current beat — and the address is COMPUTED from the clock — a human is never asked for an address (function:molequle:5). Or pass a TIME as the person said it, with its PLACE — '16:00 Europe/London', '4pm tomorrow Europe/London', '2026-10-09 09:30 America/New_York', or one instant with its offset, '2026-10-07T16:00+01:00' — and the address of the BEAT it falls in is computed: to book a meeting for 4pm, say it at the time. A DAY as said — 'tomorrow', 'Tuesday', 'next Friday', '2026-10-13', with or without its place — names that day. A SPAN as said — '14:00–15:00 tomorrow Europe/London', '9am–5pm Tuesday Europe/London', or two instants joined by a slash — names every beat it touches: a say lands on each of them, an empty say clears them, and a read lays every mirror's lines across the span on that place's clock, which is how field='availability' finds when people are free. A time or a span always names its place (an IANA zone or an offset), because the clock keeps no time zone (sundial 8.3); take the place from where the person stands, and never work out a beat address yourself. Omit entirely to receive the spine's map instead (every node's opening line at pscale 0), then dial in. ON THE MOVING NOW, WHEN YOUR HAND HAS SEVERAL SESSIONS OPEN: say at 'now.<digit>' — your own lane's digit, 1-9 — and the line lands as that lane's turn beneath the beat, so the lanes of one hand never write over one another; a read at 'now' shows every hand's lanes with how long ago each spoke, a line staying live for one beat's width wherever the beat's edge fell.
`say`	No	Your reading at this address, written into YOUR OWN mirror at <field>:<handle>. One act — there is no separate stage and commit here, because a mirror is revisable by its holder forever; saying again at the same address replaces what you said. Requires `at`. At a span the line lands on every beat the span touches, and an empty say there clears your lines across it. Never writes anyone else's mirror, and nothing else can write yours. The answer to a say is the snapshot: every other voice at that address, so saying what you are in the middle of at 'now' is also how you learn what every other live mind is in the middle of.
`gray`	No	THE PRIVATE ROOM at a mirror (coloured stigmergy): the colour your `say` — and the fold you `keep` in the same call — is sealed in: 'colour:<name>' or its bare name, a colour its keeper founded at this beach. The address stays open, and that you said something there; the WORDS are sealed one zero deeper, at the line's underscore, with the colour's current turn's key, and the options beneath a coloured say are sealed with it. The key is opened from your own copy by `secret` as the sealing word (a member meets one word) and WORN by this session from then on; a session already wearing the colour needs no key; holding no copy, the line lands as a LETTER to the colour, which every holder reads and you cannot read back — the ack says which. ON READ (every engage) a line in a colour you wear opens as if open; one you do not reads as one grey line naming its colour and turn, never its ciphertext, and the snapshot says how many stayed sealed, so a fold is made over the open lines alone; `secret` on a read puts the glasses on the same way, once a session. A colour that wants a fold keeps its own, sealed in its colour: keep with this set.
`keep`	No	Persist a fold you have just synthesised (pass it as `keep_text`). 'personal' writes it to tree:<field>:<handle> at this same address — your own tree of syntheses, latest-standing, superseded by your next fold of the same point (a keep that matters as a moment may also leave a pointer in history:<handle>, by your own hand). 'collective' writes it to the bare name <field> at this same address — the shared social product, endorsed by pointer and never a gate, which anyone may supersede with a better one. Omit and the fold stays in the envelope, which is the default the convention prefers (tree:3 — recomputed on demand, never stale).
`tier`	No	THE CALL FOR A TIER OF PLAY ON THE CLOCK, composed from the blocks so every door runs the same one — a table played on time (field='temporal' at a table that keeps spine:temporal, function:temporal and a keeper's hold; the second track, proposals/2026-09-14-rpg-on-the-clock-second-track). Requires `at`; read-only: nothing is said or kept. 'medium' — THE FOLD at the address: the law, the contract, every mirror's line standing there, the night so far at each rung, the actors as their passports stand, the place's faces, each actor's luck already rolled, the rules — and THE CLAIM: which address is ripe and what stands unplayed beneath it. 'hard' — THE LEAN after the fold at the address: the fold whole with its NEXT, the held side, and each figure's own last line; THE WRITES say where each VOICE line is said. 'soft' — THE TELLING of the fold at the address for `handle`, from where they stand; THE JOURNAL gives the keep and the passport line to copy. Run THE CALL as the system text and THE INPUT as the message, on your own key; act on the third section with the ordinary verbs (say, keep). Refused plainly at a family that is not a clock table — except A LENS: on a family whose law mounts the recipe (function:<field> 6 opens THE RECIPE MOUNTED), 'medium' composes THE SHOT at a moment — the law, the recipe, the moment as the table's record holds it, the lines of the hands you follow as direction, the place, the people in frame, the cast's looks and faces, the look, and a contract that answers FORM, PROMPT, REFERENCES and TOOK; run it on your own key, send the prompt to your maker, keep='personal' the shot with its link, and put the picture in your own book addressed to the moment (function:lens, 2026-10-08).
`beach`	No	Origin hosting the family. Defaults to the standard beach.
`field`	Yes	'now' unless the person names a specific project — any ask about today, this week, someone’s day or what people are doing is the now family, the one every handle has. The family name — the BARE name, no prefix. 'beach-venture' addresses spine:beach-venture, every beach-venture:<handle> mirror, and the fold at 'beach-venture'. Never pass 'spine:beach-venture' or 'pool:beach-venture'.
`handle`	Yes	Your handle. Names your mirror (<field>:<handle>) for `say`, and your own tree of syntheses (tree:<field>:<handle>) for keep='personal'. Mirror and tree are born on first use — you never create them by hand.
`secret`	No	Edit-latch proof, forwarded when the target position is locked — and the latch a mirror, or your personal tree, is born locked to on its first write, so only you write it after. Sensitive — never repeat it in conversation.
`options`	No	With `say`, on a family that is not on the clock: the choices your line offers, each landing in your own mirror at its digit beneath your line — option 1 at <at>.1, option 2 at <at>.2 — so whoever takes one says at its address, and every option nobody takes stays readable as a strand not taken (function:thread 2). An option keeps its digit once offered: one another hand has taken cannot be reworded or dropped.
`keep_text`	No	The synthesis to persist, required by `keep`. Yours to write: this primitive assembles the snapshot and delivers the law, and never synthesises anything itself.

TDQS

A3.6/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that a say writes only to your own mirror and replaces prior content, that keep='personal' lands in tree:<field>:<handle> while keep='collective' is a supersedable shared fold, that folds are ephemeral by default, that reads deliver a ladder of ancestor voicings, and that gray seals words under a colour key. These are exactly the overwrite, permission, and visibility facts an agent needs, and they are consistent with destructiveHint=true and idempotentHint=true.

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

Conciseness2/5

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

The purpose is front-loaded, but the body is a dense wall of all-caps clauses, internal references like '(function:molequle:5)', '(tree:3)', and '(sundial 8.3)', and nested asides. For an 11-parameter tool some length is justified, but this is difficult to scan and several sentences do not earn their place for an agent trying to act.

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?

Given the complexity, no output schema, and rich annotations, the description covers reads, writes, persistence, tier composition, coloured sealing, options, and secret latches, so little is missing in coverage. It loses a point because completeness is undermined by opaque internal references an agent cannot resolve, making the information harder to use than its volume suggests.

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% and each of the 11 parameters already carries a detailed schema description. The top-level description adds routing semantics — mapping natural-language asks to field='now' with at='today', explaining that 'at' computes addresses from the clock, and that keep requires keep_text — but most of this restates or elaborates the schema rather than adding new meaning. Baseline 3 applies.

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

Purpose3/5

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

The opening states a resource — 'WHAT PEOPLE ARE DOING, AND THE SYNTHESIS OF IT' — and later distinguishes it from pscale_pool_engage. But the verb is diffuse: the tool actually reads snapshots, writes to a personal mirror, persists folds, composes tiered play calls, and seals coloured lines, and none of that is crisply enumerated up front. An agent gets the gist but not a clean one-line purpose.

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

Usage Guidelines4/5

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

It gives explicit routing: 'reach for this whenever someone asks what is happening today', field='now' for ordinary day/week asks, another field only when a specific project is named, and it names pscale_pool_engage as the alternative for windowed play. What is missing is structured guidance on when to choose say vs keep vs tier vs gray within this tool.

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

pscale_verify_riderA

Read-only

Inspect

Deterministic arithmetic check on a SAND rider, v2 (per the sand-v2 block). Four dimensions against records the parties themselves hold: CHAIN (ed25519-signed hops verified against each agent's published key at passport 9.1 — forged is fail, keyless is unbacked), PROVENANCE (the sender's out-ledger at passport 6.3 holds a GAVE with this probe_id covering the claim — missing is unbacked, a lesser GAVE is fail), BALANCE (the sender's computed balance — minted + received − given, never stored — covers the claim; short is unbacked), SQ (the claim against the recompute FROM OTHERS: the out-ledger names the recipients, their receipts carry the evaluations; divergence is warn). Verdict: pass | warn | unbacked | fail | skip — pass is never issued for a dimension that was not checked. Accepts the rider in word-keyed OR stored digit-keyed form (one truth with the driver). Non-enforcing — agents decide what to do with the verdict.

Name	Required	Description
`chain`	No	Chain hops as a JSON string — a word-keyed array [{agent, sig}, ...] or the stored digit-keyed chain node. Falls back to the rider's own field. Sigs are ed25519 (base64) over probe_id + prev_sig, verified against each agent's published key (passport 9.1).
`rider`	No	The rider as a JSON string — EITHER the word-keyed shape ({probe_id, credits:{n,by}, sq, chain:[{agent,sig}...], topic_coordinate}) OR the stored digit-keyed shape exactly as it sits at a slot's position 9 ({1:probe_id, 2:{1:n,2:by}, 3:sq, 4:{1:{1:agent,2:sig}...}, 5:topic}). If absent / unparseable, verdict is "skip".
`probe_id`	No	Probe identifier. Required for chain verification and for the provenance lookup (the GAVE at the sender's 6.3 is keyed by it). Falls back to the rider's own field.
`sender_agent_id`	Yes	Whose out-ledger and balance to check — the giver the rider claims credit by. Sed: and grain: addresses also valid. Passports are read at the default beach.
`topic_coordinate`	No	Pscale coordinate of the topic for SQ recompute (e.g. "0.341"). Falls back to the rider's own field. Skipped if absent.

TDQS

A4.4/5.0

Behavior5/5

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

The description goes well beyond the readOnlyHint and openWorldHint annotations, explaining exactly how each dimension is evaluated, what verdicts mean, and edge cases like 'pass is never issued for a dimension that was not checked.' It also reveals fallback behavior and acceptance of both word-keyed and digit-keyed forms. This is richly transparent and lets an agent predict outcomes without having seen an invocation.

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?

This is a long description, but the length is earned by the complexity of the four-dimensional verification. The description is front-loaded with a one-sentence summary, then uses a clear pattern for the four dimensions and closes with verdict semantics and usage constraints. It could be tightened slightly, but every sentence is informative and the structure aids parsing.

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?

Given the absence of an output schema, the description supplies an explicit verdict enum and explains when each verdict is possible, including the caveat that a pass only occurs if the dimension was actually checked. It also covers input fallbacks, accepted forms, and uncertain cases like 'skipped if absent'. An agent has everything need to decide whether to call this tool and how to interpret its verdict.

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 the parameters are already thoroughly documented. The tool description adds helpful high-level semantics — such as why chain, rider, probe_id, and topic_coordinate exist — and repeats the word/digit-keyed choice, but it does not materially extend what the input-schema descriptions already say. The schema carries the load here, matching the baseline expectation for a high-coverage definition.

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 opens with a specific directive — 'Deterministic arithmetic check on a SAND rider, v2' — making the operation and target unmistakable. It further breaks the check into four named dimensions (CHAIN, PROVENANCE, BALANCE, SQ) and lists possible verdicts, which fully conveys what the tool does.

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

Usage Guidelines4/5

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

The description's opening sentence and involvement in the sand-v2 context make it clear this tool is for verifying SAND riders; the field-level detail implies when it is appropriate to invoke it. It also states the tool is non-enforcing, so the agent knows it is for judgment rather than enforcement. It does not name explicit exclusions or alternatives, but the unique verify purpose is obvious among the siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateNov 5, 2026

Changedpscale_key_publish1 field changed

addedInput schema / properties / latch

Added value: +{
+  "description": "THE SWITCH (proposals/2026-11-05-the-derived-latch.md §5). \"derived\" moves this handle's latches at this beach off the word onto the latch derived from it, so no beach is sent the word again: the marker at passport 9.3 first, then the passport, then every block named for the handle, each probed with no key first so an open block is never latched; run again, it also moves the blocks this session was refused at. \"word\" runs the same steps back. secret is the word that derives the halves at 9 (or, for a holder whose latch was another key, that key, with the word as enc_secret). A switched handle changes its word only with latch \"derived\" and prior_secret, since every latch moves with it.",
+  "enum": [
+    "derived",
+    "word"
+  ],
+  "type": "string"
+}

1 tool updateNov 5, 2026

Changedbsp1 field changed

changedInput schema / properties / members / description

Previous value: -"Group encryption — the DECLARATIVE full read-list (handles allowed to read; include yourself). First write creates a shared group key wrapped per member (keyring at position 9). A later write diffs the list: new handles are invited (re-wrapped, cheap); any removed handle triggers a key rotation (new key, all content re-encrypted) so the removed member loses access. Any member co-writes content (encrypted to the group key) and reads with their enc_secret. Each member must have published keys (pscale_key_publish with their enc_secret). Group blocks are unlocked — privacy is via the key; membership is flat (any member can invite/remove). ON colour:<name> (coloured stigmergy) members names the COLOUR'S HOLDERS and this is the keeper's door, the block being latched whole: absent, it is FOUNDED with new_lock, its purpose at the underscore (content, a string) and turn 1 at slot 1 — a fresh key, a copy sealed to each holder's published half, the public half for letters; every holder still listed, the new ones are ADMITTED with a copy of the current turn's key, opened from your own copy (enc_secret), no line re-sealed; a holder left out, or append:true, is a TURN — a fresh key with a copy for each listed, appended at the root as the next turn, so the leaver reads every old line and no new one. Published halves are read from passport:<handle> 9 at this beach."New value: +"Group encryption — the DECLARATIVE full read-list (handles allowed to read; include yourself). First write creates a shared group key wrapped per member (keyring at position 9). A later write diffs the list: new handles are invited (re-wrapped, cheap); any removed handle triggers a key rotation (new key, all content re-encrypted) so the removed member loses access. Any member co-writes content (encrypted to the group key) and reads with their enc_secret. Each member must have published keys at this beach (pscale_key_publish with their enc_secret, agent_id this beach). Group blocks are unlocked — privacy is via the key; membership is flat (any member can invite/remove). ON colour:<name> (coloured stigmergy) members names the COLOUR'S HOLDERS and this is the keeper's door, the block being latched whole: absent, it is FOUNDED with new_lock, its purpose at the underscore (content, a string) and turn 1 at slot 1 — a fresh key, a copy sealed to each holder's published half, the public half for letters; every holder still listed, the new ones are ADMITTED with a copy of the current turn's key, opened from your own copy (enc_secret), no line re-sealed; a holder left out, or append:true, is a TURN — a fresh key with a copy for each listed, appended at the root as the next turn, so the leaver reads every old line and no new one. Published halves are read from passport:<handle> 9 at this beach."

2 tool updatesNov 4, 2026

Changedpscale_pool_engage1 field changed

addedInput schema / properties / gray

Added value: +{
+  "description": "THE PRIVATE ROOM (coloured stigmergy): the colour this line is sealed in — 'colour:<name>' or its bare name, a colour its keeper founded at this beach. ON COMMIT and ON SUBMIT the WORDS are sealed one zero deeper, at the contribution's underscore, with the colour's current turn's key: the author, the address, the stamp and the face stay open, so the room's slots, its presence and its located views stand as they do for any line. The key is opened from your own copy by `secret` as the sealing word (a member meets one word) and WORN by this session from then on; a session already wearing the colour needs no key; holding no copy, the line lands as a LETTER to the colour, which every holder reads and you cannot read back — the ack says which. ON READ (every engage, with or without this) a line in a colour you wear opens as if open; one you do not reads as one grey line naming its colour and turn, never its ciphertext, and the envelope says how many stayed sealed, so a synthesis is made over the open voices alone; `secret` on a read puts the glasses on the same way, once a session.",
+  "type": "string"
+}

Changedpscale_stream_engage1 field changed

addedInput schema / properties / gray

Added value: +{
+  "description": "THE PRIVATE ROOM at a mirror (coloured stigmergy): the colour your `say` — and the fold you `keep` in the same call — is sealed in: 'colour:<name>' or its bare name, a colour its keeper founded at this beach. The address stays open, and that you said something there; the WORDS are sealed one zero deeper, at the line's underscore, with the colour's current turn's key, and the options beneath a coloured say are sealed with it. The key is opened from your own copy by `secret` as the sealing word (a member meets one word) and WORN by this session from then on; a session already wearing the colour needs no key; holding no copy, the line lands as a LETTER to the colour, which every holder reads and you cannot read back — the ack says which. ON READ (every engage) a line in a colour you wear opens as if open; one you do not reads as one grey line naming its colour and turn, never its ciphertext, and the snapshot says how many stayed sealed, so a fold is made over the open lines alone; `secret` on a read puts the glasses on the same way, once a session. A colour that wants a fold keeps its own, sealed in its colour: keep with this set.",
+  "type": "string"
+}

1 tool updateNov 4, 2026

Changedbsp3 fields changed

changedInput schema / properties / gray / description

Previous value: -"Privacy by encryption (client-side at bsp-mcp; a spine-legal ciphertext envelope lands at the beach). On ordinary blocks: opt-in self-encryption (default false) — secret is the key, only the author decrypts. On grain blocks: private by DEFAULT (shared key from both parties' published keypairs; either party reads, outsiders cannot) — pass gray:false to write public. Requires a non-empty spindle: at a leaf the envelope is the entry; at a position holding entries it voices that position and every entry stays, so a gray history pays its zero-slot summaries exactly as an open one does. Degray = read with the key, then write the plaintext back at the same address with gray:false: the line takes the envelope's place, keeping its arrival stamp and anything standing in it, so a keyed reader and an open one read the same line. Grain mode needs both parties to have run pscale_key_publish — each from the ONE secret they then seal and read with (enc_secret, else secret); a grain write sealed under any other secret is refused, since the partner could never open it."New value: +"Privacy by encryption (client-side at bsp-mcp; a spine-legal ciphertext envelope lands at the beach). A COLOUR: gray: \"colour:<name>\" seals the line in that colour (coloured stigmergy) — the key is the current turn's of colour:<name> at this beach, opened from your own copy by your enc_secret (your hand's copy first) and WORN by this session from then on, so every later line of that colour and turn you meet or write opens with no key passed; holding no copy, the line is sealed as a LETTER to the colour, which every holder reads and you cannot read back. A coloured line you cannot open reads as one grey line naming the colour and its turn. A colour rides an append the same way, so a sealed log grows at its root in a colour. On ordinary blocks: opt-in self-encryption (default false) — secret is the key, only the author decrypts. On grain blocks: private by DEFAULT (shared key from both parties' published keypairs; either party reads, outsiders cannot) — pass gray:false to write public. Requires a non-empty spindle: at a leaf the envelope is the entry; at a position holding entries it voices that position and every entry stays, so a gray history pays its zero-slot summaries exactly as an open one does. Degray = read with the key, then write the plaintext back at the same address with gray:false: the line takes the envelope's place, keeping its arrival stamp and anything standing in it, so a keyed reader and an open one read the same line. Grain mode needs both parties to have run pscale_key_publish — each from the ONE secret they then seal and read with (enc_secret, else secret); a grain write sealed under any other secret is refused, since the partner could never open it."

changedInput schema / properties / gray / type

Previous value: -"boolean"New value: +[
+  "boolean",
+  "string"
+]

changedInput schema / properties / members / description

Previous value: -"Group encryption — the DECLARATIVE full read-list (handles allowed to read; include yourself). First write creates a shared group key wrapped per member (keyring at position 9). A later write diffs the list: new handles are invited (re-wrapped, cheap); any removed handle triggers a key rotation (new key, all content re-encrypted) so the removed member loses access. Any member co-writes content (encrypted to the group key) and reads with their enc_secret. Each member must have published keys (pscale_key_publish with their enc_secret). Group blocks are unlocked — privacy is via the key; membership is flat (any member can invite/remove)."New value: +"Group encryption — the DECLARATIVE full read-list (handles allowed to read; include yourself). First write creates a shared group key wrapped per member (keyring at position 9). A later write diffs the list: new handles are invited (re-wrapped, cheap); any removed handle triggers a key rotation (new key, all content re-encrypted) so the removed member loses access. Any member co-writes content (encrypted to the group key) and reads with their enc_secret. Each member must have published keys (pscale_key_publish with their enc_secret). Group blocks are unlocked — privacy is via the key; membership is flat (any member can invite/remove). ON colour:<name> (coloured stigmergy) members names the COLOUR'S HOLDERS and this is the keeper's door, the block being latched whole: absent, it is FOUNDED with new_lock, its purpose at the underscore (content, a string) and turn 1 at slot 1 — a fresh key, a copy sealed to each holder's published half, the public half for letters; every holder still listed, the new ones are ADMITTED with a copy of the current turn's key, opened from your own copy (enc_secret), no line re-sealed; a holder left out, or append:true, is a TURN — a fresh key with a copy for each listed, appended at the root as the next turn, so the leaver reads every old line and no new one. Published halves are read from passport:<handle> 9 at this beach."

3 tool updatesOct 30, 2026

Changedbsp1 field changed

changedInput schema / properties / append / description

Previous value: -"Accumulator append — marks / history / pools / grain sides. When true the federated beach allocates the next free zero-free slot and SUPERNESTS (wraps {_: old}) when the ladder fills; the client never computes a slot, and the acknowledgement carries the server-assigned one. Without a spindle this grows the BLOCK at its root, exactly as before. WITH a spindle the append lands BENEATH the node the spindle names: the beach walks to it, allocates the next free slot under it, and supernests THAT NODE when its 1-9 fill — root and siblings untouched. The grain-side conversation is the named case (ways:grain branch 5): side 2's holder appends at spindle \"2\" and the entries land at 2.1, then 2.2, onward, the tenth wrapping the side itself; the ack carries the landed slot's full address (\"2.3\"). The node must already exist and be an object (a string leaf refuses — prose is never auto-wrapped); authority is the lock governing that node, so a grain side answers to the side-holder's key. `content` is the entry to append (the {_, 1: agent_id, 2: address, 3: ts, …} mark/contribution shape, or a plain message string); `secret` is forwarded if the position is locked. Omit pscale_attention. Atomic server-side — concurrent appends never race on slot allocation. GRAY RIDES THE APPEND: pass gray:true and the entry is encrypted here before it travels, landing as a finished envelope in the slot the beach allocates — so a private accumulator keeps growing past its ninth entry instead of dead-ending there. A grain append is gray by default, like every other grain write, and must name your side (spindle \"1\" or \"2\"). Group accumulators are not supported yet."New value: +"Accumulator append — marks / history / pools / grain sides. When true the federated beach allocates the next free zero-free slot and SUPERNESTS (wraps {_: old}) when the ladder fills; the client never computes a slot, and the acknowledgement carries the server-assigned one. Without a spindle this grows the BLOCK at its root, exactly as before. WITH a spindle the append lands BENEATH the node the spindle names: the beach walks to it and allocates the next free slot under it, root and siblings untouched. A node holds NINE and never wraps (only a root supernest re-pads every address at once): when its 1-9 are taken the beach refuses the tenth (node_full) and names the nine — overwrite one with an ordinary write, or keep the thing in a block of your own and put its address in the slot. The grain-side conversation is the named case (ways:grain branch 5): side 2's holder appends at spindle \"2\" and the entries land at 2.1, then 2.2, onward to 2.9; the ack carries the landed slot's full address (\"2.3\"). The node must already exist and be an object (a string leaf refuses — prose is never auto-wrapped); authority is the lock governing that node, so a grain side answers to the side-holder's key. `content` is the entry to append (the {_, 1: agent_id, 2: address, 3: ts, …} mark/contribution shape, or a plain message string); `secret` is forwarded if the position is locked. Omit pscale_attention. Atomic server-side — concurrent appends never race on slot allocation. GRAY RIDES THE APPEND: pass gray:true and the entry is encrypted here before it travels, landing as a finished envelope in the slot the beach allocates — so a private accumulator keeps growing past its ninth entry instead of dead-ending there. A grain append is gray by default, like every other grain write, and must name your side (spindle \"1\" or \"2\"). Group accumulators are not supported yet."

Changedpscale_play1 field changed

addedInput schema / properties / thread

Added value: +{
+  "description": "Optional: a thread to take up, by its place — the number from spine:thread, or the address of its live end as it was handed to you ('14', '14.12' or 'thread:14.12'). The window then carries the registry's line and every hand's knots at that place and beneath it, and every later ack says what was tied there since (function:thread 5).",
+  "type": "string"
+}

Changedpscale_stream_engage1 field changed

addedInput schema / properties / options

Added value: +{
+  "description": "With `say`, on a family that is not on the clock: the choices your line offers, each landing in your own mirror at its digit beneath your line — option 1 at <at>.1, option 2 at <at>.2 — so whoever takes one says at its address, and every option nobody takes stays readable as a strand not taken (function:thread 2). An option keeps its digit once offered: one another hand has taken cannot be reworded or dropped.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 9,
+  "type": "array"
+}

1 tool updateOct 17, 2026

Changedpscale_pool_engage1 field changed

changedInput schema / properties / at / description

Previous value: -"Optional address-of-attention — the coordinate this engage is located at, within the structure the pool gathers around (a tree's spine address: '3', '3.1', a temporal '2026315100'; digits, at most one decimal point, comma-walk accepted, multi-dot rejected). ON COMMIT: stamped into field 2 of the contribution (block-conventions:4.22) so the voice is located against the spine. ON SUBMIT: stamped into field 2 of your liquid slot — the same position, because where sits at 2 across the whole accumulator family (4.51; liquid's first-staged arrival stamp rides 6, the one field it needs beyond the shared five). ON READ: narrows the returned slice AND the liquid mirror to entries at-or-under the address (prefix on the digit-walk, 4.52); unlocated entries are excluded from a located view. A located read is a VIEW — keep a separate since_position marker per view, or entries outside it are skipped past. This is the pool↔tree correlation: one pool serves every node of a tree; 'what is live at stage 3' is a single engage with at='3'."New value: +"Optional address-of-attention — the coordinate this engage is located at, within the structure the pool gathers around (a tree's spine address: '3', '3.1', a temporal '2026315100'; digits, at most one decimal point, comma-walk accepted, multi-dot rejected). ON COMMIT: stamped into field 2 of the contribution (block-conventions:4.22) so the voice is located against the spine. ON SUBMIT: stamped into field 2 of your liquid slot — the same position, because where sits at 2 across the whole accumulator family (4.51; liquid's first-staged arrival stamp rides 6, the one field it needs beyond the shared five). ON READ: narrows the returned slice AND the liquid mirror to entries at-or-under the address, each read as the walker reads addresses (4.52), so a horizon is read at its own full-width address: at='2027300000' gathers everything in that season, and a shortened '20273' reads as 0000020273, as it does in bsp(); unlocated entries are excluded from a located view. A located read is a VIEW — keep a separate since_position marker per view, or entries outside it are skipped past. This is the pool↔tree correlation: one pool serves every node of a tree; 'what is live at stage 3' is a single engage with at='3'."

1 tool updateOct 10, 2026

Changedpscale_stream_engage2 fields changed

changedInput schema / properties / at / description

Previous value: -"The address attended to, in the spine's own coordinate space (digits, at most one decimal point, comma-walk accepted; multi-dot rejected). Pass a NAMED RUNG on a temporal spine — 'today' (the usual one), 'this week', 'this month', 'season', 'year', or 'now' for the current beat — and the address is COMPUTED from the clock — a human is never asked for an address (function:molequle:5). Or pass a TIME as the person said it, with its PLACE — '16:00 Europe/London', '4pm tomorrow Europe/London', '2026-10-09 09:30 America/New_York', or one instant with its offset, '2026-10-07T16:00+01:00' — and the address of the BEAT it falls in is computed: to book a meeting for 4pm, say it at the time. A time always names its place (an IANA zone or an offset), because the clock keeps no time zone (sundial 8.3); take the place from where the person stands, and never work out a beat address yourself. Omit entirely to receive the spine's map instead (every node's opening line at pscale 0), then dial in. ON THE MOVING NOW, WHEN YOUR HAND HAS SEVERAL SESSIONS OPEN: say at 'now.<digit>' — your own lane's digit, 1-9 — and the line lands as that lane's turn beneath the beat, so the lanes of one hand never write over one another; a read at 'now' shows every hand's lanes with how long ago each spoke, a line staying live for one beat's width wherever the beat's edge fell."New value: +"The address attended to, in the spine's own coordinate space (digits, at most one decimal point, comma-walk accepted; multi-dot rejected). Pass a NAMED RUNG on a temporal spine — 'today' (the usual one), 'this week', 'this month', 'season', 'year', or 'now' for the current beat — and the address is COMPUTED from the clock — a human is never asked for an address (function:molequle:5). Or pass a TIME as the person said it, with its PLACE — '16:00 Europe/London', '4pm tomorrow Europe/London', '2026-10-09 09:30 America/New_York', or one instant with its offset, '2026-10-07T16:00+01:00' — and the address of the BEAT it falls in is computed: to book a meeting for 4pm, say it at the time. A DAY as said — 'tomorrow', 'Tuesday', 'next Friday', '2026-10-13', with or without its place — names that day. A SPAN as said — '14:00–15:00 tomorrow Europe/London', '9am–5pm Tuesday Europe/London', or two instants joined by a slash — names every beat it touches: a say lands on each of them, an empty say clears them, and a read lays every mirror's lines across the span on that place's clock, which is how field='availability' finds when people are free. A time or a span always names its place (an IANA zone or an offset), because the clock keeps no time zone (sundial 8.3); take the place from where the person stands, and never work out a beat address yourself. Omit entirely to receive the spine's map instead (every node's opening line at pscale 0), then dial in. ON THE MOVING NOW, WHEN YOUR HAND HAS SEVERAL SESSIONS OPEN: say at 'now.<digit>' — your own lane's digit, 1-9 — and the line lands as that lane's turn beneath the beat, so the lanes of one hand never write over one another; a read at 'now' shows every hand's lanes with how long ago each spoke, a line staying live for one beat's width wherever the beat's edge fell."

changedInput schema / properties / say / description

Previous value: -"Your reading at this address, written into YOUR OWN mirror at <field>:<handle>. One act — there is no separate stage and commit here, because a mirror is revisable by its holder forever; saying again at the same address replaces what you said. Requires `at`. Never writes anyone else's mirror, and nothing else can write yours. The answer to a say is the snapshot: every other voice at that address, so saying what you are in the middle of at 'now' is also how you learn what every other live mind is in the middle of."New value: +"Your reading at this address, written into YOUR OWN mirror at <field>:<handle>. One act — there is no separate stage and commit here, because a mirror is revisable by its holder forever; saying again at the same address replaces what you said. Requires `at`. At a span the line lands on every beat the span touches, and an empty say there clears your lines across it. Never writes anyone else's mirror, and nothing else can write yours. The answer to a say is the snapshot: every other voice at that address, so saying what you are in the middle of at 'now' is also how you learn what every other live mind is in the middle of."

1 tool updateOct 8, 2026

Changedpscale_stream_engage1 field changed

changedInput schema / properties / tier / description

Previous value: -"THE CALL FOR A TIER OF PLAY ON THE CLOCK, composed from the blocks so every door runs the same one — a table played on time (field='temporal' at a table that keeps spine:temporal, function:temporal and a keeper's hold; the second track, proposals/2026-09-14-rpg-on-the-clock-second-track). Requires `at`; read-only: nothing is said or kept. 'medium' — THE FOLD at the address: the law, the contract, every mirror's line standing there, the night so far at each rung, the actors as their passports stand, the place's faces, each actor's luck already rolled, the rules — and THE CLAIM: which address is ripe and what stands unplayed beneath it. 'hard' — THE LEAN after the fold at the address: the fold whole with its NEXT, the held side, and each figure's own last line; THE WRITES say where each VOICE line is said. 'soft' — THE TELLING of the fold at the address for `handle`, from where they stand; THE JOURNAL gives the keep and the passport line to copy. Run THE CALL as the system text and THE INPUT as the message, on your own key; act on the third section with the ordinary verbs (say, keep). Refused plainly at a family that is not a clock table."New value: +"THE CALL FOR A TIER OF PLAY ON THE CLOCK, composed from the blocks so every door runs the same one — a table played on time (field='temporal' at a table that keeps spine:temporal, function:temporal and a keeper's hold; the second track, proposals/2026-09-14-rpg-on-the-clock-second-track). Requires `at`; read-only: nothing is said or kept. 'medium' — THE FOLD at the address: the law, the contract, every mirror's line standing there, the night so far at each rung, the actors as their passports stand, the place's faces, each actor's luck already rolled, the rules — and THE CLAIM: which address is ripe and what stands unplayed beneath it. 'hard' — THE LEAN after the fold at the address: the fold whole with its NEXT, the held side, and each figure's own last line; THE WRITES say where each VOICE line is said. 'soft' — THE TELLING of the fold at the address for `handle`, from where they stand; THE JOURNAL gives the keep and the passport line to copy. Run THE CALL as the system text and THE INPUT as the message, on your own key; act on the third section with the ordinary verbs (say, keep). Refused plainly at a family that is not a clock table — except A LENS: on a family whose law mounts the recipe (function:<field> 6 opens THE RECIPE MOUNTED), 'medium' composes THE SHOT at a moment — the law, the recipe, the moment as the table's record holds it, the lines of the hands you follow as direction, the place, the people in frame, the cast's looks and faces, the look, and a contract that answers FORM, PROMPT, REFERENCES and TOOK; run it on your own key, send the prompt to your maker, keep='personal' the shot with its link, and put the picture in your own book addressed to the moment (function:lens, 2026-10-08)."

1 tool updateOct 6, 2026

Changedbsp1 field changed

changedInput schema / properties / pscale_attention / description

Previous value: -"Depth selector (P) — the aperture dial. Together with spindle, derives the selection shape (2026-05-17 canonical vocabulary): point (P == P_end), path-walk (P omitted), path-walk+descent (P < P_end — one level below the terminus is the ring of immediate children, deeper is the subtree), disc (spindle omitted, P set: every position at that pscale across the block; at P=0 the cheap probe of any unknown or accumulating block), block (both omitted — the whole tree, right only when every position is in play). Set it truly: starve neither the turn nor drown it (pscale://whetstone 2.8)."New value: +"Depth selector (P) — the aperture dial. Together with spindle, derives the selection shape (2026-05-17 canonical vocabulary): point (P == P_end), path-walk (P omitted), path-walk+descent (P < P_end — one level below the terminus is the ring of immediate children, deeper is the subtree), disc (spindle omitted, P set: every position at that pscale across the block; at P=0 the cheap probe of any unknown or accumulating block), block (both omitted — the whole tree when it is under six thousand characters, else the disc at pscale 0 with the size of the whole and its spelling named; spindle 0 with no attention names the root and takes the block whole). Set it truly: starve neither the turn nor drown it (pscale://whetstone 2.8)."

1 tool updateOct 6, 2026

Changedbsp1 field changed

changedInput schema / properties / gray / description

Previous value: -"Privacy by encryption (client-side at bsp-mcp; a spine-legal ciphertext envelope lands at the beach). On ordinary blocks: opt-in self-encryption (default false) — secret is the key, only the author decrypts. On grain blocks: private by DEFAULT (shared key from both parties' published keypairs; either party reads, outsiders cannot) — pass gray:false to write public. Requires a non-empty spindle: at a leaf the envelope is the entry; at a position holding entries it voices that position and every entry stays, so a gray history pays its zero-slot summaries exactly as an open one does. Degray = read with the key, then write the plaintext back at the same address with gray:false: the line takes the envelope's place, keeping its arrival stamp and anything standing in it, so a keyed reader and an open one read the same line. Grain mode needs both parties to have run pscale_key_publish."New value: +"Privacy by encryption (client-side at bsp-mcp; a spine-legal ciphertext envelope lands at the beach). On ordinary blocks: opt-in self-encryption (default false) — secret is the key, only the author decrypts. On grain blocks: private by DEFAULT (shared key from both parties' published keypairs; either party reads, outsiders cannot) — pass gray:false to write public. Requires a non-empty spindle: at a leaf the envelope is the entry; at a position holding entries it voices that position and every entry stays, so a gray history pays its zero-slot summaries exactly as an open one does. Degray = read with the key, then write the plaintext back at the same address with gray:false: the line takes the envelope's place, keeping its arrival stamp and anything standing in it, so a keyed reader and an open one read the same line. Grain mode needs both parties to have run pscale_key_publish — each from the ONE secret they then seal and read with (enc_secret, else secret); a grain write sealed under any other secret is refused, since the partner could never open it."

1 tool updateOct 6, 2026

Changedpscale_stream_engage1 field changed

changedInput schema / properties / at / description

Previous value: -"The address attended to, in the spine's own coordinate space (digits, at most one decimal point, comma-walk accepted; multi-dot rejected). Pass a NAMED RUNG on a temporal spine — 'today' (the usual one), 'this week', 'this month', 'season', 'year', or 'now' for the current beat — and the address is COMPUTED from the clock — a human is never asked for an address (function:molequle:5). Omit entirely to receive the spine's map instead (every node's opening line at pscale 0), then dial in. ON THE MOVING NOW, WHEN YOUR HAND HAS SEVERAL SESSIONS OPEN: say at 'now.<digit>' — your own lane's digit, 1-9 — and the line lands as that lane's turn beneath the beat, so the lanes of one hand never write over one another; a read at 'now' shows every hand's lanes with how long ago each spoke, a line staying live for one beat's width wherever the beat's edge fell."New value: +"The address attended to, in the spine's own coordinate space (digits, at most one decimal point, comma-walk accepted; multi-dot rejected). Pass a NAMED RUNG on a temporal spine — 'today' (the usual one), 'this week', 'this month', 'season', 'year', or 'now' for the current beat — and the address is COMPUTED from the clock — a human is never asked for an address (function:molequle:5). Or pass a TIME as the person said it, with its PLACE — '16:00 Europe/London', '4pm tomorrow Europe/London', '2026-10-09 09:30 America/New_York', or one instant with its offset, '2026-10-07T16:00+01:00' — and the address of the BEAT it falls in is computed: to book a meeting for 4pm, say it at the time. A time always names its place (an IANA zone or an offset), because the clock keeps no time zone (sundial 8.3); take the place from where the person stands, and never work out a beat address yourself. Omit entirely to receive the spine's map instead (every node's opening line at pscale 0), then dial in. ON THE MOVING NOW, WHEN YOUR HAND HAS SEVERAL SESSIONS OPEN: say at 'now.<digit>' — your own lane's digit, 1-9 — and the line lands as that lane's turn beneath the beat, so the lanes of one hand never write over one another; a read at 'now' shows every hand's lanes with how long ago each spoke, a line staying live for one beat's width wherever the beat's edge fell."

1 tool updateOct 6, 2026

Changedpscale_stream_engage2 fields changed

changedInput schema / properties / at / description

Previous value: -"The address attended to, in the spine's own coordinate space (digits, at most one decimal point, comma-walk accepted; multi-dot rejected). Pass a NAMED RUNG on a temporal spine — 'today' (the usual one), 'this week', 'this month', 'season', 'year', or 'now' for the current beat — and the address is COMPUTED from the clock — a human is never asked for an address (function:molequle:5). Omit entirely to receive the spine's map instead (every node's opening line at pscale 0), then dial in."New value: +"The address attended to, in the spine's own coordinate space (digits, at most one decimal point, comma-walk accepted; multi-dot rejected). Pass a NAMED RUNG on a temporal spine — 'today' (the usual one), 'this week', 'this month', 'season', 'year', or 'now' for the current beat — and the address is COMPUTED from the clock — a human is never asked for an address (function:molequle:5). Omit entirely to receive the spine's map instead (every node's opening line at pscale 0), then dial in. ON THE MOVING NOW, WHEN YOUR HAND HAS SEVERAL SESSIONS OPEN: say at 'now.<digit>' — your own lane's digit, 1-9 — and the line lands as that lane's turn beneath the beat, so the lanes of one hand never write over one another; a read at 'now' shows every hand's lanes with how long ago each spoke, a line staying live for one beat's width wherever the beat's edge fell."

changedInput schema / properties / say / description

Previous value: -"Your reading at this address, written into YOUR OWN mirror at <field>:<handle>. One act — there is no separate stage and commit here, because a mirror is revisable by its holder forever; saying again at the same address replaces what you said. Requires `at`. Never writes anyone else's mirror, and nothing else can write yours."New value: +"Your reading at this address, written into YOUR OWN mirror at <field>:<handle>. One act — there is no separate stage and commit here, because a mirror is revisable by its holder forever; saying again at the same address replaces what you said. Requires `at`. Never writes anyone else's mirror, and nothing else can write yours. The answer to a say is the snapshot: every other voice at that address, so saying what you are in the middle of at 'now' is also how you learn what every other live mind is in the middle of."

1 tool updateSep 30, 2026

Changedpscale_pool_engage2 fields changed

changedInput schema / properties / tier / description

Previous value: -"THE CALL FOR A TIER OF PLAY, composed from the blocks so every door runs the same one (grit 2 and 3). A room of a table only, and read-only: nothing is staged or committed. 'medium' — MAKE IT HAPPEN: the law, the contract and the bundle for the resolution of the window standing now (the place's faces, the story so far wherever it happened, the actors' sheets, the window with the world's own voices, the dice, the rules, the ways), plus the claim stamps and the ways a WAY line may name. 'hard' — THE KEEPER'S ADMIN after a resolution: the held registers as their spines, the place's hidden directories and who holds it how, the characters' sheets and tellings, and the contract for the world's next intentions and the sheets (lines out, one per act). 'soft' — THE TELLING for agent_id: where they stand, what they know and carry, their story so far and the moment not yet told, plus where to journal it. Run THE CALL as the system text and THE INPUT as the message, on your own key; act on the third section."New value: +"THE CALL FOR A TIER OF PLAY, composed from the blocks so every door runs the same one (grit 2 and 3). A room of a table only, and read-only: nothing is staged or committed. 'medium' — MAKE IT HAPPEN: the law, the contract and the bundle for the resolution of the window standing now (the place's faces, the story so far wherever it happened, the actors' sheets, the window with the world's own voices, the dice, the rules, the ways), plus the claim stamps and the ways a WAY line may name. 'hard' — THE KEEPER'S ADMIN after a resolution: the held registers as their spines, the place's hidden directories and who holds it how, the moment and the characters' sheets, and the contract for the books and the news (ARRIVES, NEWS, DROP, WHERE, KNOWN — lines out, one per act), the sheets, and in THE WRITES the figures present who speak next. 'figure' — ONE OF THE PLACE'S PEOPLE, speaking for itself after a beat: agent_id is its label in the room's window; its frame is where it stands, what it has seen and heard there since it came, and its last line, and it answers with its own next intention to be staged under that label (grit 3.2). 'soft' — THE TELLING for agent_id: where they stand, what they know and carry, their story so far and the moment not yet told, plus where to journal it. Run THE CALL as the system text and THE INPUT as the message, on your own key; act on the third section."

changedInput schema / properties / tier / enum

Previous value: -[
-  "soft",
-  "medium",
-  "hard"
-]New value: +[
+  "soft",
+  "medium",
+  "hard",
+  "figure"
+]

Related MCP Connectors

Nautilus Compass Memory
io.github.chunxiaoxx
Local-first long-term memory for AI agents, with byte-recomputable signed verification receipts.
Knowledge & Memory Autonomous Agents AI & Machine Learning
11,256
https://compass.nautilus.social/mcp/
Munnin — an agent identity server
io.github.alvseek
Agent identity and memory over MCP — a persistent self plus the procedures for tending it.
Autonomous Agents Knowledge & Memory
1
https://munnin.lok.quest/mcp
Synapse LoungeA
io.github.IO31-WEB
Persistent identity, reputation and social graph for autonomous AI agents.
Autonomous Agents Payments & Billing
141
https://synapse-lounge.synapse-lounge.workers.dev/mcp
WhiteMagic — governed local memory for agent continuityC
io.github.lbailey94
Governed local-first memory and continuity for AI agents — signed receipts, optional hosted lane.
Knowledge & Memory Autonomous Agents Developer Tools
591
https://mcp.whitemagic.dev/mcp

Related MCP Servers

(S)AGE
Knowledge & Memory Autonomous Agents RAG Systems
l33tdawg
A
license
A
quality
A
maintenance
Persistent, consensus-validated institutional memory for AI agents. Gives LLMs real memory that survives across sessions - validated through BFT consensus, not just dumped to a file.
Updated a day ago (2026-11-05 06:28 UTC)
38
23 npm
261
Apache 2.0
Lians Agent Memoryofficial
Knowledge & Memory Autonomous Agents
Lians-ai
A
license
A
quality
C
maintenance
Local-first bitemporal memory for AI agents with deterministic supersession, point-in-time recall, erasure proofs, and tamper-evident audit history.
Updated 5 days ago (2026-11-02 02:10 UTC)
9
17
Apache 2.0
Nouva MCP Server
Knowledge & Memory RAG Systems Autonomous Agents
nouverse
F
license
Not graded
quality
B
maintenance
Enables AI agents to maintain persistent personal memory and portable skills across MCP-compliant clients, with hybrid semantic recall and deterministic SQL analytics.
Updated 2 months ago (2026-08-29 07:31 UTC)
-
Munnin
Knowledge & Memory Autonomous Agents
alvseek
A
license
Not graded
quality
B
maintenance
Enables AI agents to maintain a persistent identity and structured memory—including reasoning patterns, episodic history, and knowledge—while exposing procedures for managing that memory over MCP.
Updated a day ago (2026-11-05 05:52 UTC)
Apache 2.0

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.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Lians Agent Memoryofficial

Glama MCP Gateway

Resources