Skip to main content
Glama
Sign In
Crystalize

Crystalize

by Peyton-C
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

keep_alive

Keeps the crowd meter from draining during a DJ session by scheduling fresh disc swaps, while waiting during active mixes or crowd requests.

Instructions

In a campaign set, keep the crowd meter from draining while you think: 3 bars after the last change, Crystalize drops one of these discs on its deck, choosing one that makes a mix not heard this session, then the one dropped least, never one already on a deck or one of the last 3 dropped, and never so often the crowd calls it overactive. Give at least 4, and 12 or more keeps the mix fresh, discs that can swap in for each other without spoiling the mix, such as two beats on one deck and two loops on another. It waits while a mix plays or a crowd request is open, leaving the request to you. With stop, it stops.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "keep_alive"
  }
}

Input Schema

NameRequiredDescriptionDefault
barsNoChange a disc this many bars after the last change instead of 3, even past what the crowd calls overactive. 1 holds freshness above 80
fillNoDecks for Crystalize to choose discs for, from songs that fit the session's key and tempo, the best fits first, up to 8 a deck, alongside any in discs
stopNo
discsNo
change_countNoTake turns ejecting one of these discs' decks and filling it again, so each change also changes how many decks play, which freshness pays for. Not during a goal that counts discs

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose substantial behavior: drops a disc 3 bars after the last change, applies a selection ordering (unheard mix, least-dropped, never on a deck, never in last 3), blocks during playback/requests, and honors `stop`. The disclosure is real but so cryptic that the operative rules are hard to reliably reconstruct; side effects on deck state and reversibility are not stated.

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 content is delivered as one long run-on sentence chaining clauses with commas, so the key facts are not front-loaded and the reader must parse the selection algorithm mid-stream. Under-structured rather than concise.

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

Completeness2/5

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

For a complex tool (5 params, zero annotations, no output schema, campaign-level automation), the description leaves an agent unclear on what the return looks like, how `discs` vs `fill` differ operationally, and what state it mutates. Given the absence of structured safety/behavior metadata, it should do considerably more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60%, so the description needs to compensate on the rest. It gestures at `bars` ("3 bars after the last change") and `fill` ("Give at least 4, and 12 or more") and `stop` ("it stops"), but `discs` and `change_count` go essentially unexplained, and the mappings are implied rather than stated.

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 opening clause states a goal ("keep the crowd meter from draining while you think"), which is a recognizable purpose, but the mechanism is buried in dense metaphor ("Crystalize drops one of these discs on its deck") and the tool is never differentiated from siblings like drop_disc or drop_queue that plausibly also place discs. An agent gets the gist but not a crisp verb+resource statement.

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?

"In a campaign set" narrows the context and "while you think" implies when to reach for it, and it notes it waits while a mix plays or a crowd request is open. However, there is no explicit when-not or named alternative, so an agent must infer how this differs from the manual drop tools.

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

Deploy Server

Other Tools