Skip to main content
Glama

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

TableJSON 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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."
  2. 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."
  3. 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>)."
  4. 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."
  5. First observed

TDQS

A4/5.0
Behavior5/5

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

Despite readOnlyHint/openWorldHint/idempotentHint already covering the safety profile, the description adds substantial behavioral context beyond the annotations: the world-resolution algorithm (worlds block, sub-beach convention, full URL), session effects ('PINS the world's URL', 'engages the room pool'), the conditional GATE path for new handles, the HERE NOW vs ABOUT cast split, and the directive-inlining behavior. This is exactly the kind of disclosure that helps an agent predict side effects and return content.

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

Conciseness3/5

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

The description is organized into scannable segments (returning holder, new handle, RPG, worlds note) and is front-loaded with the core promise. But it is roughly 300 words of ornate prose with decorative filler ('THE DOOR — two arrivals, one call', 'no-fiddle entry', 'passport riding') that could be cut without losing information, and one sentence ('no world needed') is actively misleading next to the required parameter.

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

Completeness4/5

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

For a complex 4-parameter tool with no output schema, the description covers the major branches (keyed session, new handle via GATE, RPG invocation), the world resolution paths, context bundling, and post-return expectations (inlined directive, scene, cast split) — partially compensating for the absent output schema. It stops short of complete: error/edge cases (unknown handle, unresolvable world) and the precise return payload shape are not specified, but this is a strong effort for the tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3; the description largely restates the schema rather than extending it (world resolution, room as a 'gloss', secret authorizing submits). It does add a few nuggets — the shell:<handle>:3 manifest reference, legacy witnessed/knows block names, and explicit call-signature examples — but it also introduces confusion by saying 'no world needed' while world is a required parameter, which undermines the added value.

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

Purpose4/5

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

The description does state a specific action and resource — 'play inhabits a persistent handle — a character, a user, or an agent' and 'compiles your shell's manifest into ONE framed window' — and it explicitly differentiates from pscale_invite ('invite is the welcome passage for a newcomer; play inhabits a persistent handle'). However, the theatrical framing ('THE DOOR', 'passport riding', 'no-fiddle entry') forces an agent to decode heavy metaphor before the plain meaning emerges, so it falls short of a 5.

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

Usage Guidelines4/5

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

The description gives explicit selection guidance against the closest sibling: use pscale_invite for newcomers, pscale_play for persistent handles. It also covers the three entry scenarios (returning holder, new-to-world handle, RPG character) and the GATE/lobby path for unkeyed handles. It does not, however, give when-not guidance against other siblings that share behaviors (e.g., pool/stream engagement tools), and some guidance ('follow the inlined directive every turn') is post-call instruction rather than tool-selection context.

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

All bsp-mcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources