Skip to main content
Glama

bsp-mcp

by io.github.pscale-commons

pscale_key_publish

DestructiveIdempotent

Derive an X25519+Ed25519 keypair from your secret + handle (Argon2id). Publish the public half at passport position 9 of the federated passport block "passport:". Private half is never stored. Same secret + handle always produces the same keys. Passport block must exist at the beach first. Rotation requires proof of prior key ownership (prior_secret OR signature). Defaults to https://beach.happyseaurchin.com; pass agent_id to publish at a different beach.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
handleYesYour bare-name handle. Used as the Argon2id derivation salt AND as the discriminator in the passport block name ("passport:<handle>") at the beach. Must match an existing passport block.
secretYesWrite-authority for the passport block (proves you may write position 9). Also the fallback keypair seed when enc_secret is omitted. Never stored.
agent_idNoURL of the beach hosting the passport. Defaults to https://beach.happyseaurchin.com. The passport block name is "passport:<handle>" per the role-with-handle convention.
signatureNoRotation only: precomputed base64 Ed25519 sig over "pscale_key_rotation:{handle}:{new_x25519_b64}:{new_ed25519_b64}", made with the prior secret key.
enc_secretNoKeypair seed (Argon2id with handle) — the published PUBLIC half derives from this; the private half is never stored, and enc_secret itself is never sent to the beach. Falls back to secret. Use the SAME enc_secret you use for grain/self encryption, or your published key will not match your ciphertext.
prior_secretNoRotation only: the PRIOR encryption secret (it derived the currently-published keypair). Server derives the prior keypair and signs the rotation message internally.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (idempotent, destructive, openWorld), the description discloses that the private half is never stored, that the same secret+handle always produce the same keys, and that the beach defaults to a specific URL but can be overridden with agent_id. It also explains the rotation proof requirement, adding significant behavioral context.

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

Conciseness5/5

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

Four sentences contain everything needed: key derivation, publication target, private key handling, determinism, prerequisite, rotation condition, and default/override behavior. No filler or redundancy; the most important information is front-loaded.

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 tool with 6 parameters and no output schema, the description covers prerequisites, rotation, default behavior, determinism, and security properties. It is sufficient for an agent to select and invoke the tool correctly, including edge cases like rotation and custom beach URLs.

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%, so the baseline is 3. The description adds cross-parameter semantics: it explains that secret+handle both seed derivation via Argon2id, that enc_secret falls back to secret, and that prior_secret/signature are rotation mechanisms. This clarifies relationships not fully explicit in the schema 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?

The description opens with a specific action: 'Derive an X25519+Ed25519 keypair... Publish the public half at passport position 9'. It clearly states the resource (federated passport block 'passport:<handle>') and the outcome, fully aligning with the tool name and title while remaining distinct from sibling tools.

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 provides clear prerequisites ('Passport block must exist at the beach first') and conditional guidance for rotation ('Rotation requires proof of prior key ownership'). It does not explicitly name alternative tools for when this tool should not be used, but the context and purpose are unambiguous.

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