Skip to main content
Glama
Sign In

bsp-mcp

by io.github.pscale-commons
OverviewDiscussionsAdmin

pscale_play

Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
roomNoOptional 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.
worldYesThe 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.
handleYesThe 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>).
secretNoYour 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.
threadNoOptional: a thread to take up, by its place — the number from spine:thread, or the address of its live end as it was handed to you ('14', '14.12' or 'thread:14.12'). The window then carries the registry's line and every hand's knots at that place and beneath it, and every later ack says what was tied there since (function:thread 5).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / thread
      Added value: +{
+  "description": "Optional: a thread to take up, by its place — the number from spine:thread, or the address of its live end as it was handed to you ('14', '14.12' or 'thread:14.12'). The window then carries the registry's line and every hand's knots at that place and beneath it, and every later ack says what was tied there since (function:thread 5).",
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / handle / description
      Previous 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>)."
    • changedInput schema / properties / world / description
      Previous 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."
  3. Changed1 schema field changed
    • changedInput schema / properties / room / description
      Previous value: -"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."New value: +"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."
  4. Changed1 schema field changed
    • changedInput schema / properties / handle / description
      Previous 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 (witnessed:<handle>, passport:<handle>, shell:<handle>)."New 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>)."
  5. Changed1 schema field changed
    • changedInput schema / properties / world / description
      Previous value: -"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."New 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."
  6. First observed

TDQS

A3.6/5.0
Behavior4/5

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

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

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

Conciseness2/5

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

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

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

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

Purpose4/5

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

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

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

Usage Guidelines4/5

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

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

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

All bsp-mcp toolsInspect
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.

Resources