Skip to main content
Glama

pscale_pool_engage

Destructive

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNoOptional 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'.
faceNoCADO 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.
tierNoTHE 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.
clearNoOptional. 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.
partyNoWith 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.
secretNoLock 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.
submitNoOptional. 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).
purposeNoOptional, 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_idYesYour agent identifier — used as the contributor attribution if `contribution` is provided. Bare handle, URL, sed:<collective>:<position>, or grain:<pair_id>:<side>.
pool_urlYesURL 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_nameYesName 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".
destinationNoOptional, 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_liquidNoOptional. 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.
contributionNoOptional. 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_seenNoRESOLVER-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_positionNoLast 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_windowNoRESOLVER-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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / tier / description
      Previous value: -"THE CALL FOR A TIER OF PLAY, composed from the blocks so every door runs the same one (grit 2 and 3). A room of a table only, and read-only: nothing is staged or committed. 'medium' — MAKE IT HAPPEN: the law, the contract and the bundle for the resolution of the window standing now (the place's faces, the story so far wherever it happened, the actors' sheets, the window with the world's own voices, the dice, the rules, the ways), plus the claim stamps and the ways a WAY line may name. 'hard' — THE KEEPER'S ADMIN after a resolution: the held registers 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."
  2. Changed1 schema field changed
    • changedInput schema / properties / purpose / description
      Previous 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."
  3. Changed1 schema field changed
    • addedInput schema / properties / party
      Added 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"
      +}
  4. Changed1 schema field changed
    • addedInput schema / properties / tier
      Added 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"
      +}
  5. Changed1 schema field changed
    • changedInput schema / properties / resolves_window / description
      Previous 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."
  6. Changed1 schema field changed
    • addedInput schema / properties / clear
      Added value: +{
      +  "description": "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.",
      +  "type": "boolean"
      +}
  7. Changed1 schema field changed
    • changedInput schema / properties / at / description
      Previous value: -"Optional address-of-attention — the coordinate this engage is located at, within the structure the pool gathers around (a tree's spine address: '3', '3.1', a temporal '2026315100'; digits, at most one decimal point, comma-walk accepted, multi-dot rejected). ON COMMIT: stamped into field 2 of the contribution (block-conventions:4.22) so the voice is located against the spine. ON SUBMIT: stamped into field 6 of your liquid slot (4.51 — field 2 there is the arrival stamp). ON READ: narrows the returned slice AND the liquid mirror to entries at-or-under the address (prefix on the digit-walk, 4.52); unlocated entries are excluded from a located view. A located read is a VIEW — keep a separate since_position marker per view, or entries outside it are skipped past. This is the pool↔tree correlation: one pool serves every node of a tree; 'what is live at stage 3' is a single engage with at='3'."New value: +"Optional address-of-attention — the coordinate this engage is located at, within the structure the pool gathers around (a tree's spine address: '3', '3.1', a temporal '2026315100'; digits, at most one decimal point, comma-walk accepted, multi-dot rejected). ON COMMIT: stamped into field 2 of the contribution (block-conventions:4.22) so the voice is located against the spine. ON SUBMIT: stamped into field 2 of your liquid slot — the same position, because where sits at 2 across the whole accumulator family (4.51; liquid's first-staged arrival stamp rides 6, the one field it needs beyond the shared five). ON READ: narrows the returned slice AND the liquid mirror to entries at-or-under the address (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'."
  8. Changed2 schema fields changed
    • addedInput schema / properties / at
      Added value: +{
      +  "description": "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 6 of your liquid slot (4.51 — field 2 there is the arrival stamp). 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'.",
      +  "type": "string"
      +}
    • changedInput schema / properties / contribution / description
      Previous value: -"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, 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."New value: +"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."
  9. Changed1 schema field changed
    • changedInput schema / properties / contribution / description
      Previous value: -"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."New value: +"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, 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."
  10. Changed1 schema field changed
    • addedInput schema / properties / resolves_seen
      Added value: +{
      +  "description": "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.",
      +  "type": "string"
      +}
  11. Changed1 schema field changed
    • changedInput schema / properties / with_liquid / description
      Previous value: -"Optional. Include the liquid mirror (all co-present pending intentions from liquid:pool:<name>) in the envelope. Implied true when `submit` is provided, and DEFAULT TRUE for a KEYLESS caller — a visitor with no secret is handed the room's live pending aggregate as their answer, because that is the presence they arrived for (the spool is what was said; liquid is who is here now). Defaults false for a KEYED caller, to skip the extra fetch. An explicit value is always honoured either way."New value: +"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."
  12. Changed1 schema field changed
    • changedInput schema / properties / with_liquid / description
      Previous value: -"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."New value: +"Optional. Include the liquid mirror (all co-present pending intentions from liquid:pool:<name>) in the envelope. Implied true when `submit` is provided, and DEFAULT TRUE for a KEYLESS caller — a visitor with no secret is handed the room's live pending aggregate as their answer, because that is the presence they arrived for (the spool is what was said; liquid is who is here now). Defaults false for a KEYED caller, to skip the extra fetch. An explicit value is always honoured either way."
  13. Changed1 schema field changed
    • removedInput schema / properties / synthesis_hint
      Removed value: -{
      -  "description": "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.",
      -  "type": "string"
      -}
  14. First observed

TDQS

A4.3/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing that submit overwrites a per-author liquid slot, contribution is an atomic append, clear destroys the entire liquid buffer but never committed contributions, and there is no central resolver. It also explains caller-managed markers and the WINDOW MOVED race guard. No contradiction with the annotations is present; destructiveHint=true is consistent with the described overwrite and clear behavior.

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 dense multi-clause wall of text with parenthetical digressions, all-caps emphasis, and repeated explanations such as the 'shared spool everyone pulls' framing. While much of the content is relevant, it is not easily scannable and would benefit from bulleted modes and shorter sentences. The front-loaded opening is useful, but the overall structure is not appropriately concise for an agent-facing definition.

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 tool's high complexity, the description is remarkably complete: it covers pool creation, staging, committing, reading, clearing, secret/lock authority, default beach URL, resolution guards, and returned artifacts like marker_new, the social mirror, and WINDOW MOVED. With no output schema present, it still gives the agent enough return-behavior context to invoke the tool safely.

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% and every parameter already has a rich description, so the baseline is 3. The description adds cross-parameter semantics beyond the schema: submit and contribution may be combined, purpose is the canonical pool-creation path that must not be done via bare bsp(), and marker_new must be stored and returned. This nudges it above baseline, though most per-parameter meaning still lives in the 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 clearly identifies the tool as engaging a pool with a synthesis envelope, and it specifies the two write modes (submit vs contribution) and read behavior over the since_position marker. It is specific about the spool primitive and warns against raw bsp(), but it never explicitly contrasts this tool with sibling tools like pscale_stream_engage or pscale_play, so sibling differentiation is incomplete.

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?

The description gives explicit when-to-use guidance: submit for staging to the liquid buffer, contribution for committing, clear 'whenever someone asks for the pool, the room or the liquid to be cleared', and omit contribution for read-only engagement. It also explicitly routes RPG subjective resolution to the resolver's bsp() job and warns 'NEVER use raw bsp() with content=\'<purpose>\'', which tells the agent what not to do.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.