Skip to main content
Glama

pscale_play

Read-onlyIdempotent

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/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='thornwood', handle='anya') → you are Anya in the Beaten Drum, directive and scene in hand.

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: 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.
handleYesThe 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>).
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.

TDQS

A4.9/5.0
Behavior5/5

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

It discloses specifics beyond annotations: world resolution to beach/sub-domain, room-pool engagement with directive+scene inlining, URL pinning, and GATE sequence for new handles. Also notes secret's role in authorizing future writes. These are useful behavioral context not captured by readOnlyHint/idempotentHint/openWorldHint.

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

Conciseness4/5

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

The description is a long paragraph with jargon-rich detail, but it is front-loaded with the core purpose and every sentence adds functional information. Some flourish ('no-fiddle', 'co-present cast arrives split by grain') increases length without adding clarity, but it remains structured and useful.

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

Completeness5/5

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

For a complex tool with no output schema, it thoroughly covers what gets returned (directive and scene), the new-handle GATE sequence, cast presence split (HERE NOW vs ABOUT), and the resolution/pinning mechanics. It is complete for an agent to invoke and behave correctly afterward.

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

Parameters5/5

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

Schema already covers 100%, but the description adds crucial nuance: world resolution via worlds directory and fallback convention, handle being an attribution and block suffix, room as a convenience gloss for pscale 0, and secret's 'omit to perceive only' effect. This far exceeds the schema's plain field descriptions.

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

Purpose5/5

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

First sentence states 'Inhabit a handle in a world, in one call' — a clear verb+resource. It explicitly distinguishes from pscale_invite via 'invite is the welcome passage for a newcomer; play inhabits a persistent handle.'

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 names pscale_invite as the alternative and delineates when each applies. It also provides post-call instructions ('follow the inlined directive every turn') and the special GATE flow for new handles, making usage context explicit.

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.

TDQS

A4/5.0
Disambiguation4/5

Each tool targets a distinct primitive of the beach substrate: block I/O, floor alignment, pools, streams, settlements, identity, SAND, verification, world entry, and agent wakes. The descriptions explicitly separate near-neighbors like pool vs stream and networking vs verify_rider, though a few pairs (bsp/bsp-floor, play/invite) could still be confused on name alone.

Naming Consistency3/5

The pscale_ prefix provides a consistent family marker, but the verb/object pattern is mixed: bare verbs (invite, play, settle), object-verb compounds (key_publish, pool_engage, stream_engage), a verb-object compound (verify_rider), and nouns (genus, networking). bsp and bsp-floor also break the snake_case convention, keeping the naming readable but not strongly predictable.

Tool Count5/5

Twelve tools is well within the well-scoped range for a server of this breadth, and each tool maps to a distinct capability: core bsp, floor alignment, identity, grains, pools, streams, collectives, worlds, SAND networking, verification, and agent wakes. No tool feels redundant given the described domain.

Completeness4/5

The surface covers the main lifecycle areas: block read/write/discovery, key publication, bilateral grains, pools, streams, settlements, world entry, SAND networking, and rider verification. Minor gaps exist—passport creation is a prerequisite for key_publish but is only implied as a bsp write, and instance/world creation is referenced rather than directly exposed—so agents may need to work around a few edges.