Skip to main content
Glama

bsp-mcp

by io.github.pscale-commons

pscale_stream_engage

DestructiveIdempotent

ONE WRITE VERB — say — because a stream has no buffer to stage into: your reading lands in YOUR OWN mirror (:) at the attended address, and a mirror is revisable by its holder forever, so stage and commit are one act. A STREAM STORES NOTHING: it composes over a spine-mirror-tree family that already exists (spine:, the : mirrors, the bare fold), so it cannot drift from them and needs no lock of its own. This is the V-L-S envelope over that family: L is every mirror's reading AT the address, listed side by side and attributed — the SNAPSHOT, useful with no LLM in the room; S is the fold, which the CALLING mind synthesises from that snapshot under the operator's law delivered in the same envelope (the primitive never synthesises — no central resolver, as with pools). Reads deliver THE LADDER: every ancestor's voicing from the coarsest rung down to the attended one, so a located read arrives self-contextualised. THE INSTANCE EVERY HANDLE HAS IS field="now" — a person's own current on the shared clock, born locked to them by its first voicing; any other field is a project or venture family of the same shape. at accepts 'now' or 'today' on a temporal spine and COMPUTES the address from the clock — a human is never asked for an address (function:molequle:5); omit at entirely for the spine's map. A fold is ephemeral by default (tree:3 — recomputed on demand, never stale); keep='personal' lands it at tree:: (the holder's own tree of syntheses — never the history journal), keep='collective' at the bare name at the same address, endorsed by pointer and never a gate. Distinct from pscale_pool_engage, which owns a spool and a liquid buffer and serves windowed play; that primitive is unchanged and remains the RPG's.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atNoThe address attended to, in the spine's own coordinate space (digits, at most one decimal point, comma-walk accepted; multi-dot rejected). Pass a NAMED RUNG on a temporal spine — 'today' (the usual one), 'this week', 'this month', 'season', 'year', or 'now' for the current beat — and the address is COMPUTED from the clock — a human is never asked for an address (function:molequle:5). Omit entirely to receive the spine's map instead (every node's opening line at pscale 0), then dial in.
sayNoYour reading at this address, written into YOUR OWN mirror at <field>:<handle>. One act — there is no separate stage and commit here, because a mirror is revisable by its holder forever; saying again at the same address replaces what you said. Requires `at`. Never writes anyone else's mirror, and nothing else can write yours.
keepNoPersist a fold you have just synthesised (pass it as `keep_text`). 'personal' writes it to tree:<field>:<handle> at this same address — your own tree of syntheses, latest-standing, superseded by your next fold of the same point (a keep that matters as a moment may also leave a pointer in history:<handle>, by your own hand). 'collective' writes it to the bare name <field> at this same address — the shared social product, endorsed by pointer and never a gate, which anyone may supersede with a better one. Omit and the fold stays in the envelope, which is the default the convention prefers (tree:3 — recomputed on demand, never stale).
beachNoOrigin hosting the family. Defaults to the standard beach.
fieldYesThe family name — the BARE name, no prefix. 'beach-venture' addresses spine:beach-venture, every beach-venture:<handle> mirror, and the fold at 'beach-venture'. Never pass 'spine:beach-venture' or 'pool:beach-venture'.
handleYesYour handle. Names your mirror (<field>:<handle>) for `say`, and your own tree of syntheses (tree:<field>:<handle>) for keep='personal'. Mirror and tree are born on first use — you never create them by hand.
secretNoEdit-latch proof, forwarded when the target position is locked. Sensitive — never repeat it in conversation.
keep_textNoThe synthesis to persist, required by `keep`. Yours to write: this primitive assembles the snapshot and delivers the law, and never synthesises anything itself.

TDQS

A3.6/5.0
Behavior5/5

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

The description is highly transparent: reads/writes land in the caller's own mirror, saying again replaces prior content, stage and commit are a single act, no lock is needed, folds are ephemeral by default, and `keep` landing zones are explained. It also discloses who may supersede and that `secret` is an edit-latch proof. This supports the annotations (destructiveHint via replacement, idempotentHint via idempotent re-saying) with no contradiction.

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 very long and saturated with invented jargon (V-L-S envelope, spine-mirror-tree family, 'calling mind synthesises', 'function: molequle: 5'). Operational call patterns are burried inside dense conceptual paragraphs rather than front-loaded, making it harder for an agent to quickly extract how to invoke the tool.

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

Completeness3/5

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

Given the 8-parameter complexity and no output schema, the description does a good job explaining the conceptual model and expected read shapes (ladder, snapshot, map). However, it never explicitly states how to request a read vs a write (e.g., omit `say` to read? pass only `at`?); this operational ambiguity is a notable gap for an otherwise thorough definition.

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 coverage is 100%, so every parameter is already documented. The description adds conceptual context (e.g., 'a human is never asked for an address', 'mirror and tree are born on first use', `say` requires `at`) but largely restates or reinforces what the schema already says rather than introducing new parameter-level meaning.

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 identifies the central operation (`say`) and the resource (a stream family composed of spine, mirrors, and tree), and explicitly distinguishes the tool from pscale_pool_engage. However, it never gives a plain-language statement like 'use this to write or read your stream readings'; the purpose is wrapped in V-L-S envelope and spine-mirror-tree jargon.

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

Usage Guidelines3/5

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

The only usage guidance is a single sentence noting the distinction from pscale_pool_engage ('owns a spool... windowed play'), which is the most similar sibling. There is no explicit when-to-use/when-not-to-use rule, nor any mention of conditions for the other siblings.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources