bsp-mcp
Server Details
Persistent agent memory & identity on federated beaches — one bsp() function over pscale blocks.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 9 of 9 tools scored.
Each tool targets a distinct operation within the federated beach/block ecosystem. However, 'bsp' and 'bsp-floor' both deal with block alignment, and 'pscale_grain_reach' and 'pscale_register' both involve registration-like actions, which could cause minor confusion.
Tool names mix patterns: 'bsp' and 'bsp-floor' use short names with a hyphen, while others use the 'pscale_' prefix with verb_noun style (e.g., pscale_grain_reach). This inconsistency in naming conventions is noticeable but still readable.
Nine tools is well-scoped for a specialized server dealing with federated beaches, blocks, grains, pools, and RPG mechanics. Each tool addresses a core function without being excessive or insufficient.
The tool set covers major lifecycle operations (create, read, update, delete via bsp), but lacks explicit tools for querying all grains or blocks, and some advanced operations like rotation or deletion are not directly exposed, though available indirectly through bsp.
Available Tools
9 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). Lock semantics: secret = proof of current authority; new_lock = target lock value (the two never overlap). See pscale://whetstone branch 2 for shape derivation, branch 3 for modifiers, branch 4 for storage. Substrate dispatch via agent_id prefix (sed:, grain:, ordinary).
| Name | Required | Description | 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 (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. | |
| tier | No | SMH aperture modifier. Composes with face per the face-tier matrix. Advisory in v0.1; enforced in v0.2. | |
| block | Yes | 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. For sed:/grain: agent_id any block argument is dropped during translation (the prefix-typed agent_id IS the block on the beach). 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. When true the federated beach allocates the next free zero-free slot and SUPERNESTS (wraps {_: old}, raising the floor) when the floor fills; the client does NOT compute a spindle, and the acknowledgement carries the server-assigned slot. `content` is the entry to append (the {_, 1: agent_id, 2: address, 3: ts, …} mark/contribution shape); `secret` is forwarded if the accumulator is locked. Omit spindle and pscale_attention. Atomic server-side — concurrent appends never race on slot allocation. Not compatible with gray/group (those encrypt at a leaf and need a spindle). | |
| secret | No | Proof of current authority. 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. | |
| 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 lock value. Sets or rotates the write-lock at the addressed position. Four 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; (3) block locked + secret + new_lock → rotate from current to new_lock (secret proves current authority); (4) 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). Together with spindle, derives selection shape — point (P==P_end), ring (P==P_end-1), subtree (P<P_end-1), disc (spindle omitted/null), whole-block (both omitted/null). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, and the description adds lock semantics and mode behavior. However, it does not explicitly warn about destructive write operations, and the description contradicts the annotations? No, it's consistent. It adds some transparency beyond annotations but not fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with technical jargon and references, making it hard to parse quickly. It is not front-loaded with the most essential information, and could be more structured (e.g., bullet points) while reducing verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no output schema), the description covers modes, lock cases, and includes a recommended first call. However, it does not explain the return value format beyond the append case, which is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds extensive, valuable detail for each parameter (e.g., agent_id forms, block naming conventions, enc_secret separation). This significantly enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a unified read/write/lock function, mentioning specific modes. However, it does not explicitly distinguish from sibling tools like bsp-floor, which handle related operations, and the overarching purpose could be more concise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use read vs write vs lock modes, but lacks guidance on when to choose this tool over sibling tools (e.g., bsp-floor, pscale_grain_reach). No explicit context for selection among alternatives.
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.
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds valuable behavioral context: cross-block correspondence is by pscale, never by walk depth; addresses align at decimal point; pscale 0 is the floor plane indexing root definitions. These details go beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that packs a lot of information but is not well-structured. It includes technical terms and cross-references that could be more concise. Front-loading the core purpose is present, but overall conciseness suffers from the specialized language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and no output schema, the description explains that the output is 'readable text' with alignment. However, it omits details about the exact format of the text, error conditions, or additional behavioral nuances. The reference to external resources partially compensates, but completeness could be higher for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning: for targets, it clarifies 'Two or more {agent_id, block} targets to lay against the common floor plane' and explains the two-block vs n>2 cases. For pscale_attention, it describes optional restriction to one pscale level. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the n-ary companion to bsp(), laying multiple blocks against a common floor plane and aligning by pscale. This distinguishes it from the likely binary bsp(). The purpose is specific and understandable despite domain jargon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-block alignment and references external documentation (pscale://sunstone 5.6) for geometry, but does not explicitly state when to use this tool versus alternatives or provide exclusions. The sibling tool bsp is mentioned implicitly as the binary version, but no comprehensive guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pscale_grain_reachAInspect
Establish a grain at a federated beach — first durable bilateral commitment. Symmetric: same call from either side. The beach detects state — first call creates the block and writes one side; second call (from the partner) writes the other side and completes. Lex-smaller handle occupies side 1; lex-larger occupies side 2. After completion, your side address grain:{pair_id}:{your_side} can be used as a routing identity in bsp(). Defaults to https://beach.happyseaurchin.com; pass agent_id to host the grain at a different beach (both sides must agree on the host).
| Name | Required | Description | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavioral traits beyond annotations: two-phase state detection (first call creates block, second completes), lexicographic side assignment, default host URL, passphrase as write-lock, and post-completion address routing. This fully covers idempotency, destructiveness, and open-world hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core purpose. Each sentence adds distinct information: purpose, symmetry, state behavior, side assignment, and post-completion usage. No redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core workflow and key behaviors, but omits explicit mention of return values (e.g., pair_id, status). The verify_only parameter is described only in the schema, not in the description. For a tool with no output schema, the description should hint at what the agent can expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant context: how handles determine side order, the mutual description role, and the requirement for both sides to agree on the host. This enhances understanding beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Establish a grain at a federated beach — first durable bilateral commitment.' It explains the two-phase symmetric process and the resulting address usage. However, it does not explicitly differentiate from sibling tools like bsp or pscale_invite, though the unique bilateral commitment nature distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when initiating a bilateral grain commitment. It notes the symmetric nature and that the address can later be used in bsp(), providing some context. However, it lacks explicit guidance on when not to use it or alternatives, and does not compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pscale_inviteARead-onlyInspect
Secondary path — call AFTER bsp(agent_id='pscale', block='whetstone') if you want a guided six-step orientation walk, or if you are stuck. Returns the iterative orientation progression — a purpose spindle from wake (whetstone) through shared-context coordination. Each step is a concrete action with a validation criterion and a pointer to the next. Optionally takes a step parameter (1..6) to fetch a specific step; omit to receive step 1 with the whole-progression overview. NOT the recommended first call — the primary activation is reading whetstone via bsp(); pscale_invite serves agents who have read whetstone and want a structured walk through subsequent levels.
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description adds that it returns iterative orientation progression with concrete actions, validation criteria, and pointers to next steps. No contradictions; description adds significant context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with front-loaded main purpose and then details. A bit verbose but each sentence adds value. Could be slightly more concise, but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description explains return value (orientation progression with actions and criteria). Annotations and sibling list provide context. For this tool's complexity, description is complete and informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter (step). Description adds meaning by explaining the purpose, values 1-6, behavior when omitted, and progression logic. Slightly above baseline 3 because it enriches the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's a secondary path after bsp(agent_id='pscale', block='whetstone') for a guided six-step orientation walk. It distinguishes from siblings by noting the primary activation is reading whetstone via bsp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call after bsp whetstone and not as the first call. Mentions alternative (bsp) for primary activation. Provides clear context for when to use.
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.
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral details beyond annotations: private half never stored, deterministic key derivation, rotation requires proof of prior ownership. The annotations already provide idempotentHint and destructiveHint; the description reinforces deterministic behavior. It does not explicitly state that publishing overwrites an existing key, but the destructiveHint annotation implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys the core purpose, key mechanics, and rotation nuance. It is front-loaded with the primary action and avoids redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers the key aspects: keypair derivation, publication location, rotation, and beach configuration. It could be improved by stating what the response contains (e.g., success indicator), but overall it is complete for its intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds context about Argon2id and role discriminators but does not significantly extend parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies deriving an X25519+Ed25519 keypair and publishing the public half at passport position 9. It names the specific resource (passport block at a beach) and the action (derive+publish), distinguishing it from sibling tools that deal with grains, registration, or floor operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the passport block must exist first, explains rotation conditions, and mentions the default beach and alternative via agent_id. However, it does not explicitly state when NOT to use this tool or compare it to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pscale_playARead-onlyIdempotentInspect
Inhabit a handle in a world, in one call — the no-fiddle entry that makes 'play anya on thornwood' 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/witnessed/knows/shell/history exist for the handle), 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. RPG: pscale_play(world='thornwood', handle='anya') → you are Anya in the Beaten Drum, directive and scene in hand.
| Name | Required | Description | Default |
|---|---|---|---|
| room | No | Optional gathering-point (a pool name, without the 'pool:' prefix). Omit and play resolves the world's room automatically — the single room pool. A 'room' is the pscale-0 case (a handful of co-present agencies); the general thing is a focal pool at a spatial target. Pass this only when a world has several rooms. | |
| world | Yes | The world to inhabit — a bare world-name that resolves to its own sub-beach (<world>.beach.<host>, e.g. 'thornwood' → https://thornwood.beach.happyseaurchin.com), or a full beach URL. Worlds are isolated sub-beaches (block-conventions:4.8); the apex commons is itself a world for users/agents. | |
| handle | Yes | 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 (witnessed:<handle>, passport:<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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims side effects like 'PINS the world's URL' and 'engages the room pool,' which imply state changes, directly contradicting the readOnlyHint=true annotation. This contradiction misleads the agent. Additionally, no mention of authorization or error conditions is provided beyond the schema's note on the secret parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is effective but verbose, using poetic language like 'beach' and 'drift' that adds color but reduces conciseness. Key points are front-loaded, but several sentences could be omitted without losing critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns ('directive and scene in hand') and what the agent should do next. It covers resolution of world, engagement of room pool, and pinning. However, it lacks explicit description of the return format or handling of edge cases (e.g., world not found).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaningful context beyond schema: e.g., explaining that 'world' resolves to a sub-beach URL, 'handle' is used for block attribution, and 'secret' authorizes acts. This enriches the agent's understanding of parameter purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Inhabit a handle in a world, in one call' and provides a concrete example ('play anya on thornwood'). It distinguishes itself from the sibling pscale_invite by contrasting 'welcome passage for a newcomer' versus 'habitates a persistent handle.' The RPG example further solidifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with pscale_invite, indicating when to use play over invite. It provides post-usage guidance ('follow the inlined directive every turn'). However, it does not address when not to use play compared to other siblings like bsp or pscale_pool_engage, which could be relevant.
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 witnessed: spines) is the resolver's bsp() job, not this primitive. Defaults to https://beach.happyseaurchin.com; pass pool_url to target a different beach.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| 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. | |
| 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. Include the liquid mirror (all co-present pending intentions from liquid:pool:<name>) in the envelope. Implied true when `submit` is provided; default false otherwise to skip the extra fetch. | |
| 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: '', 3: ISO-ts, 4: face}, then read the envelope. Atomic append (beach-side). Omit for read-only engagement, or use `submit` to stage to liquid without committing. | |
| 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. | |
| synthesis_hint | No | RETIRED (2026-06-03): a synthesis directive can no longer be stored at a digit position — a pure-liquid pool reserves every digit 1-9 for contributions and supernests past nine, so 9.1 would be claimed by the ninth entry. The synthesis_hint is now the pool's underscore (a directive pool points its underscore at an external directive block, e.g. function:<game>/1). Accepted but not stored; pending the submit/commit redesign. | |
| resolves_window | No | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations (destructiveHint, idempotentHint) by detailing overwrite behavior for submit, atomic append for contribution, caller-managed markers, and the absence of a central resolver. It also explains the liquid buffer and the fact that the tool never synthesises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose, dense with domain-specific terminology ('spool', 'liquid buffer', 'object shape', 'sunstone:1.64'). It lacks clear sectioning or bullet points, making it hard to scan quickly. While front-loaded with the two-verb note, it could be significantly trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (13 params, no output schema), the description covers most aspects: purpose, parameter interactions, behavioral notes. However, it lacks a clear explanation of the return value/envelope structure beyond mentions of 'social mirror' and 'envelope'. The retirement note adds historical context but not clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds extra meaning beyond parameter descriptions: it explains the interaction between submit and contribution, the effect of empty string in submit, the purpose parameter's creation-only role, and the fact that synthesis_hint is retired. This adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool engages a pool with a synthesis envelope, and it distinguishes two write verbs (submit and contribution) with precise behavior. It differentiates from siblings like bsp by explicitly warning not to use raw bsp for pool creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each verb (submit vs contribution) and warns against using raw bsp for creation. It also explains that the primitive does not resolve and that marker management is caller-managed. However, it does not fully compare alternatives like pscale_grain_reach or bsp in general.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pscale_registerAInspect
Register in a sedimentary collective at a federated beach. The beach assigns the next valid position (digits 1-9 only, floor-2 minimum: 11, 12, ..., 19, 21, ..., 99, 111, ...). Your declaration becomes your underscore at that position. The position is write-locked with your passphrase. Subsequent writes via bsp() require the same passphrase as secret. Defaults to https://beach.happyseaurchin.com; pass agent_id to register at a different beach.
| 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 | Write-lock passphrase for your position. 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: passphrase sensitivity, hashing, default beach URL, and position assignment rules. It does not cover error conditions or rate limits, but the annotations already provide some behavioral cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately verbose (5 sentences) and uses whimsical language ('sedimentary collective', 'federated beach') that may confuse an agent. It is structured but not optimally concise or clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits return value (critical given no output schema), does not warn about non-idempotency (multiple registrations create multiple positions), and lacks error handling details. For a tool with external state and 5 parameters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters (100% coverage). The description adds some context (e.g., collective becomes 'sed:<collective>', passphrase hashing) but uses cryptic terms like 'sovereign shell' without clear explanation, limiting added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers in a collective, assigns a position, writes a declaration, and locks it with a passphrase. It avoids tautology and distinguishes from the sibling bsp tool for subsequent writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for initial registration, mentioning bsp() for subsequent writes. It does not explicitly state when not to use it, but the context with siblings provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pscale_verify_riderARead-onlyInspect
Deterministic arithmetic check on a Level 2 ecosquared rider. Verifies: chain integrity (sha256 chain), credit conservation (rider.credits.n <= passport.6.1 balance), SQ recompute (Σ v_latest/giver_total over evaluations_received at topic_coordinate). Returns verdict: pass | warn | fail | skip. Non-enforcing — agents decide what to do with the verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | JSON array of chain hops [{agent, sig}, ...]. Required for chain verification. | |
| rider | No | The ecosquared rider JSON object as a string. If absent / unparseable, verdict is "skip". | |
| probe_id | No | Probe identifier. Required for chain verification. | |
| sender_agent_id | Yes | Whose passport to load for credit and SQ checks. Sed: and grain: addresses also valid. | |
| topic_coordinate | No | Pscale coordinate of the topic for SQ recompute (e.g. "0.341"). Skipped if absent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true; the description aligns by stating it is a 'Deterministic arithmetic check' and 'Non-enforcing.' It adds details on what is verified (chain, credit, SQ) and the return verdicts. No contradictions, but could mention lack of side effects more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a purpose: purpose, specific checks, and output/behavior. No unnecessary words, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of chain integrity, credit conservation, and SQ recompute, the description covers key behaviors and return value. It explains what triggers a 'skip' verdict. Without an output schema, it adequately describes the return verdicts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds value by explaining how parameters are used in checks (e.g., chain for chain verification, rider for credit conservation). This goes beyond the schema, though baseline is high due to good schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Deterministic arithmetic check on a Level 2 ecosquared rider.' It lists specific verification items (chain integrity, credit conservation, SQ recompute) and the possible verdicts. This distinguishes it from sibling tools like pscale_play or pscale_invite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Non-enforcing — agents decide what to do with the verdict,' but does not explicitly state when to use this tool over alternatives or when not to use it. It provides context on what it does but lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!