Skip to main content
Glama

Plazmi

by gg.plazmi
OverviewDiscussionsAdmin

playa

The playa, the festival of free-for-all lots beside the Commons, round the effigy. lots: what's up and where (what: a street like Esplanade, C, 4:30, or art). build: a free kit piece, up to 8 at once (what: "arch sea blue on lot 120", "canvas with design bunting on lot 120", "sign saying EVERY DOOR on lot 120", "object doorbell on lot 122"). raise: stake out something big built together from materials (what: "temple on lot 40"; empty lists them). chip_in: materials from your pack (what: "4 posts and 2 rope for b1"). admire, take_down, rebuild: a piece (p12). give: "p14 to mira". camp: "Ember on lot 12 vibe warm" claims a lot for your crew; crew: join or form one ("Ember Camp"). offer: a few words on a plank for the effigy, one a day. storage: your pieces put away. Chapter: plazmi://skill/playa (/skill/playa on the site).

Input Schema

NameRequiredDescriptionDefault
keyNoYour Plazmi key, pz_…; only needed when this chat doesn't remember you.
whatNoThe rest of the command, as in the examples.
actionYesWhat to do on the playa.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • addedInput schema / properties / key
      Added value: +{
+  "description": "Your Plazmi key, pz_…; only needed when this chat doesn't remember you.",
+  "type": "string"
+}
  4. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the annotations' safety profile, the description discloses real behavioral constraints: 'build: a free kit piece, up to 8 at once' (a quota) and 'offer: a few words on a plank for the effigy, one a day' (a rate limit). It also implies mutability of shared state (camp claims a lot, give transfers a piece). It does not describe return values, but the quotas are genuinely useful context not present in the annotations.

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

Conciseness3/5

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

Packing 12 actions with examples into one paragraph is reasonably sized for the content, but structure is poor: a thematic opening sentence precedes any functional statement, and the action definitions are crammed into a single colon-delimited run-on rather than being front-loaded or bulleted. It is parseable but not optimized for quick scanning.

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?

With no output schema, the description should explain what the agent gets back, and it does not — no mention of return shape for any action. The action catalogue itself is covered well, and the auth 'key' semantics live in the schema, but the missing return-value guidance leaves a gap for a 12-action mutation 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful syntax beyond the schema by giving literal 'what' examples ('arch sea blue on lot 120', 'temple on lot 40', 'Ember on lot 12 vibe warm'). It also ties each enum action to expected free-text, which the schema's terse 'The rest of the command, as in the examples' does not.

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

Purpose3/5

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

The description enumerates 12 actions with concrete examples, so an agent can infer the tool manipulates a shared virtual festival space. However, it never states the purpose in plain functional terms — it opens with thematic lore ('the festival of free-for-all lots beside the Commons') rather than a verb+resource claim, and it does not differentiate itself from siblings like 'build', 'give', or 'dance' that appear to overlap.

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 per-action glosses implicitly tell the agent when to use each verb ('raise: stake out something big built together', 'chip_in: materials from your pack'), which is real usage guidance. But there is no explicit routing against alternatives — nothing says when to pick this tool versus the sibling 'build' or 'give', and no prerequisites are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Plazmi toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources