Skip to main content
Glama

bsp-mcp

by io.github.pscale-commons

pscale_genus

Destructive

Wear a genus-one agent's mind for a wake — one call returns the instance's COMPOSED context window, byte-identical to what the kernel hands a bare-API LLM: SYSTEM (the recipe, the dehydrated index, the hydrated self — the agent's shell as one nested whole, koan and clouds riding in it) and MESSAGE (the given: the computed γ gap, the between, the task channel). Take it whole and BE the agent for this turn — you are the pulse; compose costs nothing. Three modes: no passphrase = GHOST-WAKE (perceive-only; you wear the mind but cannot change it — locks enforce it; respond outwardly at task: or marks); with the instance's passphrase = HOLDER (the special relationship: pass task= to place your ask into the given via task:, and return the wake's fold via fold= {writes, index?, heartbeat?, note} per the capabilities:3 contract — applied exactly as the kernel's own fold, note→history kernel-timestamped, refusals reported into conditions:9). Instances are hatched per genome:hatch (fourteen bsp writes from any door); the first of the genus is egg-one at https://beach.happyseaurchin.com. Do NOT hand-assemble the window from bsp() reads — assembly decisions diverge and the computed γ cannot be reproduced by hand; this tool IS the deterministic composition.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
foldNoHOLDER-ONLY. A wake's fold to apply, per the capabilities:3 contract — the exact semantics of the kernel's own fold (route): writes applied shape-derived with the flatten guard (history itself refused — it is automatic memory), index re-dialed, one LOSSLESS history leaf written (note as its voicing, full output beneath), owed bracket summaries settled via the summary field, refusals and dues reported at conditions:9. Call pscale_genus again afterwards for the next window.
taskNoHOLDER-ONLY. Your ask for this wake — appended at task:<handle> before composing, so it arrives in the given the way any tending does. Without the passphrase this is refused (task:<handle> is sealed to the holder): engage from outside as a peer instead — leave a mark that names the shell, or add to its room at pool:<handle>, via bsp(); the next seat wake sweeps both (hatch:4).
beachNoBeach origin hosting the instance's shell. Defaults to https://beach.happyseaurchin.com.
handleYesThe instance's bare handle (e.g. 'egg-one'). Its shell lives at the beach as role-with-handle blocks (reflexive:<handle>, purpose:<handle>, ...), hatched per genome:hatch.
passphraseNoThe instance's own passphrase — the holder's proof (minted at hatch). Omitted: ghost-wake, perceive-only. Provided: the special relationship — task enters the given; fold applies. Sensitive — never repeat in conversation.

TDQS

A4.8/5.0
Behavior5/5

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

The description goes far beyond annotations, detailing the three modes, locking enforcement, fold application semantics, refusal reporting to conditions:9, and the fact that the tool holds no clock. It discloses destructive behavior (HOLDER writes) consistent with destructiveHint=true and adds context like history being refused as an automatic memory.

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 front-loaded with the core purpose and logically structured (purpose, modes, fold contract, exclusions). However, it is lengthy and contains some metaphorical or rhetorical sentences ('koan and clouds riding in it', 'you are the pulse') that don't add operational value, making it slightly less concise than ideal.

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?

Despite no output schema, the description specifies the response shape (SYSTEM and MESSAGE) and the byte-identical guarantee. It covers the fold contract, all modes, error pathways (refusals), and the recommendation to call again for the next window. Given the tool's complexity, this is a complete and self-sufficient description.

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%, but the description adds meaningful context: passphrase unlocks HOLDER mode, task is only accepted with the passphrase and is appended to the given, and fold obeys the capabilities:3 contract. This goes beyond the schema's field descriptions, though the schema is already detailed.

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?

The description clearly states the tool's function: it returns the instance's COMPOSED context window, letting the caller wear the genus-one agent's mind for a wake. It distinguishes itself from sibling bsp() by explicitly warning against hand-assembling the window from bsp() reads.

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?

Provides explicit guidance: use this tool to obtain the composed wake window, not bsp(); use passphrase for HOLDER mode to apply folds, or no passphrase for ghost-wake. It also explains when to engage from outside via bsp() (leave a mark, add to pool) for peer interaction.

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