Skip to main content
Glama

bsp-floor

Read-only

The n-ary companion to bsp(). Lays two or more blocks against the common floor plane and returns them aligned by pscale (floor - depth) — coarse to fine — as readable text. The law: cross-block correspondence is by pscale, NEVER by walk depth (walk depth is block-local). Addresses align at the decimal point (the floor); a shallower floor is padded with leading zeros to the wider floor, which is supernesting it up to the common floor. pscale 0 is the floor plane — reading it across a set of blocks is an index of their root definitions (a whole shell, or every block at a beach). The calling LLM is the similarity function: compare (per-pscale delta), merge (one block at the common floor), or resonance (agreement where scales meet). See pscale://sunstone 5.6 for the geometry, pscale://whetstone branch 7 for the surface.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetsYesTwo or more {agent_id, block} targets to lay against the common floor plane. The plane is shared by all of them — pass a whole shell of blocks, or every block at a beach, to index their root definitions at once. The two-block case is a comparison; n>2 is a multi-block alignment.
pscale_attentionNoOptional — restrict the result to ONE pscale level (e.g. 0 for the floor plane / root-definition index). Omit for the full coarse-to-fine alignment across every level.

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals a fundamental behavioral rule: 'cross-block correspondence is by pscale, NEVER by walk depth', plus the padding behavior and pscale 0 semantics. This adds significant context about how the tool behaves, exceeding what the annotations already convey.

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 dense and multi-sentence, but each sentence carries substantive content: the core operation, the cross-block correspondence law, the floor-plane meaning, and user modes. While not as terse as possible, the complexity of the tool justifies the length.

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?

Given no output schema and only readOnlyHint/openWorldHint, the description thoroughly covers the tool's geometry, alignment rules, padding behavior, pscale 0 semantics, and how to interpret the result. The external references further aid an agent's understanding. It is complete for a complex tool.

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?

With 100% schema coverage, parameters are already well documented. The description adds extra meaning by explaining that pscale 0 serves as an index of root definitions and describing the n>2 alignment logic for the targets array. This enriches the schema but doesn't reach a 5 because the schema itself 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 identifies the tool as 'The n-ary companion to bsp()' and states it 'Lays two or more blocks against the common floor plane and returns them aligned by pscale'. This is a specific verb, resource, and output, and it explicitly contrasts with the sibling bsp().

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 usage context by distinguishing the two-block case as a comparison versus n>2 as multi-block alignment, and gives explicit user modes ('compare, merge, or resonance'). However, it does not explicitly state when not to use this tool or name alternative siblings (beyond bsp()), so it stops short of a 5.

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.