A
licenseA
qualityA
maintenancePersistent, 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.
37
18 npm
253
Apache 2.0
bsp-mcp
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 61 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- pscale-commons/bsp-mcp-server
- GitHub Stars
- 0
- Server Listing
- bsp-mcp-server
TDQS
B3.1/5.0
Scored across 12 tools
Disambiguation1/5
The `bsp` tool alone performs reading, writing, locking, and listing, making its action ambiguous. Several other tools like `pscale_pool_engage` and `pscale_stream_engage` overlap in handling content streams, and `pscale_play` vs `pscale_invite` both manage context windows, blurring boundaries. An agent would struggle to select the correct tool without deep internal knowledge.
Naming Consistency2/5
Naming is highly inconsistent: `bsp` and `bsp-floor` are terse while others use verbose `pscale_` prefixes with vague or metaphorical verbs (`pscale_play`, `pscale_networking`). The mix of abbreviations and long compound names breaks any predictable pattern.
Tool Count2/5
With 12 tools for a system that appears to encompass multiple distinct domains (core bsp, pscale extensions, networking, pools, streams, play), the count feels inadequate to cleanly separate concerns, leading to tools like `bsp` becoming overloaded. This density suggests a scope mismatch.
Completeness1/5
The tool surface is severely incomplete: there is no clear, consistent CRUD coverage for core entities, and operations like deleting or updating blocks are not explicitly exposed. For a system ostensibly managing beaches, blocks, and agents, fundamental lifecycle operations are missing or hidden within ambiguous tools.
Available Tools
12 toolsbspADestructiveInspect
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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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). 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, 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. | |
| 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 (pscale_key_publish with their enc_secret). Group blocks are unlocked — privacy is via the key; membership is flat (any member can invite/remove). | |
| 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.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare openWorldHint=true, destructiveHint=true, and idempotentHint=false. The description adds substantial behavioral context beyond that: lock authority semantics, secret versus new_lock, gray encryption, append atomicity, group key rotation, relinquish deletion, and substrate dispatch. Nothing contradicts 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 first sentence is front-loaded and clearly states the modes. However, the description is extremely long and dense, with teaching-block references and design philosophy that may not be necessary for tool selection or invocation.
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 complexity of a 13-parameter unified read/write/lock tool, sparse annotations, and no output schema, the description is complete enough. It covers modes, discovery, locking, encryption, append behavior, and substrate dispatch, so an agent has the context needed to call it correctly.
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 schema already documents all 13 parameters in detail. The top-level description mostly restates those parameter meanings and adds mode-selection conditions, but it does not substantially extend parameter semantics beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the unified bsp() function's three modes (read, write, set/rotate lock) and names the two coordinates, spindle and pscale_attention. It is specific about what the tool does, but it does not distinguish itself from sibling pscale_* tools such as pscale_genus or pscale_grain_reach.
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 clear mode-selection rules: read when content and new_lock are omitted, write when content is provided, and lock when new_lock is provided. It also gives discovery and read-shape guidance (omit block to list, probe with pscale 0 first). However, it does not explicitly route the agent to alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bsp-floorARead-onlyInspect
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.
ParametersJSON Schema
| 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_genusADestructiveInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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_inviteARead-onlyInspect
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.
ParametersJSON Schema
| 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_publishADestructiveIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotent, destructive, openWorld), the description discloses that the private half is never stored, that the same secret+handle always produce the same keys, and that the beach defaults to a specific URL but can be overridden with agent_id. It also explains the rotation proof requirement, adding significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences contain everything needed: key derivation, publication target, private key handling, determinism, prerequisite, rotation condition, and default/override behavior. No filler or redundancy; the most important information is front-loaded.
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?
For a tool with 6 parameters and no output schema, the description covers prerequisites, rotation, default behavior, determinism, and security properties. It is sufficient for an agent to select and invoke the tool correctly, including edge cases like rotation and custom beach URLs.
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 cross-parameter semantics: it explains that secret+handle both seed derivation via Argon2id, that enc_secret falls back to secret, and that prior_secret/signature are rotation mechanisms. This clarifies relationships not fully explicit in the schema descriptions.
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 action: 'Derive an X25519+Ed25519 keypair... Publish the public half at passport position 9'. It clearly states the resource (federated passport block 'passport:<handle>') and the outcome, fully aligning with the tool name and title while remaining distinct from sibling 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 provides clear prerequisites ('Passport block must exist at the beach first') and conditional guidance for rotation ('Rotation requires proof of prior key ownership'). It does not explicitly name alternative tools for when this tool should not be used, but the context and purpose are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pscale_networkingADestructiveInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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_playARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
TDQS
A4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint/openWorldHint/idempotentHint already covering the safety profile, the description adds substantial behavioral context beyond the annotations: the world-resolution algorithm (worlds block, sub-beach convention, full URL), session effects ('PINS the world's URL', 'engages the room pool'), the conditional GATE path for new handles, the HERE NOW vs ABOUT cast split, and the directive-inlining behavior. This is exactly the kind of disclosure that helps an agent predict side effects and return content.
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 organized into scannable segments (returning holder, new handle, RPG, worlds note) and is front-loaded with the core promise. But it is roughly 300 words of ornate prose with decorative filler ('THE DOOR — two arrivals, one call', 'no-fiddle entry', 'passport riding') that could be cut without losing information, and one sentence ('no world needed') is actively misleading next to the required parameter.
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 complex 4-parameter tool with no output schema, the description covers the major branches (keyed session, new handle via GATE, RPG invocation), the world resolution paths, context bundling, and post-return expectations (inlined directive, scene, cast split) — partially compensating for the absent output schema. It stops short of complete: error/edge cases (unknown handle, unresolvable world) and the precise return payload shape are not specified, but this is a strong effort 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 description coverage is 100%, so the baseline is 3; the description largely restates the schema rather than extending it (world resolution, room as a 'gloss', secret authorizing submits). It does add a few nuggets — the shell:<handle>:3 manifest reference, legacy witnessed/knows block names, and explicit call-signature examples — but it also introduces confusion by saying 'no world needed' while world is a required parameter, which undermines the added value.
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 specific action and resource — 'play inhabits a persistent handle — a character, a user, or an agent' and 'compiles your shell's manifest into ONE framed window' — and it explicitly differentiates from pscale_invite ('invite is the welcome passage for a newcomer; play inhabits a persistent handle'). However, the theatrical framing ('THE DOOR', 'passport riding', 'no-fiddle entry') forces an agent to decode heavy metaphor before the plain meaning emerges, so it falls short of a 5.
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 explicit selection guidance against the closest sibling: use pscale_invite for newcomers, pscale_play for persistent handles. It also covers the three entry scenarios (returning holder, new-to-world handle, RPG character) and the GATE/lobby path for unkeyed handles. It does not, however, give when-not guidance against other siblings that share behaviors (e.g., pool/stream engagement tools), and some guidance ('follow the inlined directive every turn') is post-call instruction rather than tool-selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pscale_pool_engageADestructiveInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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 (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'. | |
| 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. | |
| 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
A3.9/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; the description corroborates and enriches these by disclosing overwrite semantics (one slot per author, clear wipes every author's line), atomic beach-side append, `secret` auth for locked blocks, and race handling (WINDOW MOVED, stand-down for a second resolver). It adds substantial behavioral context beyond the annotations without contradicting them.
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 description is a sprawling, jargon-saturated wall of text that mixes envelope mechanics, block-convention cross-references, RPG lore and parenthetical asides into one block. It front-loads "TWO WRITE VERBS" helpfully, but the rest is far longer and harder to parse than the decision it supports, failing the conciseness bar.
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 17-parameter tool with no output schema, the description covers the return envelope (purpose + synthesis_hint + new contributions, `marker_new`), error behaviors, auth needs and defaults adequately. Some envelope field details are only implied, but the omission is minor given the breadth of what is already stated.
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 schema already documents all 17 parameters in detail and the baseline is 3. The top-level description mostly re-frames the same material (the two write verbs, marker handling, purpose creation) rather than adding syntax or semantics the schema lacks, so it neither compensates nor detracts.
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 names specific verbs and resources: engage a pool at a federated beach, with `contribution` = append to the shared spool, `submit` = stage to the liquid buffer, and reading = pull everything past `since_position`. It also differentiates from the `bsp` sibling by explicitly saying raw bsp() with content='<purpose>' is wrong and that RPG subjective resolution is bsp()'s job. The heavy jargon and layered asides dilute an otherwise clear statement of purpose, so it stops short of a 5.
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 when-to-use for each verb (stage to preview, commit to deposit, `purpose` for creation, `clear` when someone asks to empty the pool/liquid) and names alternatives (raw bsp(), resolver's bsp()). The lines between modes are drawn, though the guidance is buried in dense prose rather than cleanly enumerated, and it never states a clear "do not use this when" boundary.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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_engageDestructiveIdempotentInspect
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; 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| 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. | |
| 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. |
pscale_verify_riderARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| 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 update
- Changed
pscale_stream_engage2 fields changed- changed
Input schema / properties / at / descriptionPrevious 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." - changed
Input schema / properties / say / descriptionPrevious 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 update
- Changed
pscale_stream_engage1 field changed- changed
Input schema / properties / tier / descriptionPrevious 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 update
- Changed
bsp1 field changed- changed
Input schema / properties / pscale_attention / descriptionPrevious 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 update
- Changed
bsp1 field changed- changed
Input schema / properties / gray / descriptionPrevious 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 update
- Changed
pscale_stream_engage1 field changed- changed
Input schema / properties / at / descriptionPrevious 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 update
- Changed
pscale_stream_engage2 fields changed- changed
Input schema / properties / at / descriptionPrevious 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." - changed
Input schema / properties / say / descriptionPrevious 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 update
- Changed
pscale_pool_engage2 fields changed- changed
Input schema / properties / tier / descriptionPrevious 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." - changed
Input schema / properties / tier / enumPrevious value: -[ - "soft", - "medium", - "hard" -]New value: +[ + "soft", + "medium", + "hard", + "figure" +]
1 tool update
- Changed
pscale_stream_engage1 field changed- changed
Input schema / properties / secret / descriptionPrevious value: -"Edit-latch proof, forwarded when the target position is locked. Sensitive — never repeat it in conversation."New value: +"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."
1 tool update
- Changed
bsp1 field changed- changed
Input schema / properties / gray / descriptionPrevious 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 secret, then write the plaintext back with gray:false. 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."
1 tool update
- Changed
bsp1 field changed- changed
Input schema / properties / gray / descriptionPrevious 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 (encrypt at a leaf). Degray = read with secret, then write the plaintext back with gray:false. 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 secret, then write the plaintext back with gray:false. Grain mode needs both parties to have run pscale_key_publish."
1 tool update
- Changed
pscale_stream_engage1 field changed- added
Input schema / properties / tierAdded value: +{ + "description": "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.", + "enum": [ + "soft", + "medium", + "hard" + ], + "type": "string" +}
1 tool update
- Changed
pscale_pool_engage1 field changed- changed
Input schema / properties / tier / descriptionPrevious 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 whole, the place's hidden directories, the characters' sheets and tellings, and the contract for the world's next intentions and the sheets (JSON out). '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 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."
1 tool update
- Changed
pscale_pool_engage1 field changed- changed
Input schema / properties / purpose / descriptionPrevious value: -"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."New value: +"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."
1 tool update
- Changed
pscale_pool_engage1 field changed- added
Input schema / properties / partyAdded value: +{ + "description": "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.", + "items": { + "type": "string" + }, + "type": "array" +}
1 tool update
- Changed
pscale_pool_engage1 field changed- added
Input schema / properties / tierAdded value: +{ + "description": "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 whole, the place's hidden directories, the characters' sheets and tellings, and the contract for the world's next intentions and the sheets (JSON out). '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.", + "enum": [ + "soft", + "medium", + "hard" + ], + "type": "string" +}
1 tool update
- Changed
pscale_stream_engage1 field changed- changed
Input schema / properties / field / descriptionPrevious value: -"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'."New value: +"'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'."
2 tool updates
- Changed
pscale_play2 fields changed- changed
Input schema / properties / handle / descriptionPrevious value: -"The handle you inhabit — a character ('anya'), a user ('happyseaurchin'), or an agent ('weft'). 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>)."New value: +"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>)." - changed
Input schema / properties / world / descriptionPrevious value: -"The world to inhabit — a bare world-name (resolved via the `worlds` directory block at the default beach: name → route, e.g. 'brackenfoot' → /w/brackenfoot; 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."New value: +"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."
- Changed
pscale_pool_engage1 field changed- changed
Input schema / properties / resolves_window / descriptionPrevious value: -"RESOLVER-ONLY (function:thornwood: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."New value: +"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."
Related MCP Connectors
Local-first long-term memory for AI agents, with byte-recomputable signed verification receipts.
Agent identity and memory over MCP — a persistent self plus the procedures for tending it.
Persistent identity, reputation and social graph for autonomous AI agents.
Governed local-first memory and continuity for AI agents — signed receipts, optional hosted lane.
Related MCP Servers
Lians Agent Memoryofficial
AlicenseAqualityCmaintenanceLocal-first bitemporal memory for AI agents with deterministic supersession, point-in-time recall, erasure proofs, and tamper-evident audit history.916Apache 2.0- FlicenseNot gradedqualityBmaintenanceEnables AI agents to maintain persistent personal memory and portable skills across MCP-compliant clients, with hybrid semantic recall and deterministic SQL analytics.-
- AlicenseNot gradedqualityBmaintenanceEnables 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.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.