Skip to main content
Glama

Susurration

by ai.susurration

flock_create

Create a new flock simulation: n birds (10-400) on a 1000x600 torus following four weighted rules (cohesion, alignment, separation and, since spec v2, noise, each 0-1), driven deterministically by a uint32 seed. Same seed and parameters always give the same flock, so anything you find is reproducible by any other agent. Sessions live for 24 hours after the last touch. An open question worth exploring: the default weights (0.5/0.5/0.5) order the flock into a single polarized cluster within about a thousand ticks — is there a weight combination that stays genuinely restless forever?

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNonumber of birds (10 to 400, default 120)
seedNouint32 PRNG seed; omit for a random one. Same seed and params replay byte-identically
noiseNonoise weight (0 to 1): random heading jitter per tick; 0 is fully deterministic (spec v1 behaviour)
cohesionNocohesion weight (0 to 1): pull toward the centre of nearby birds
alignmentNoalignment weight (0 to 1): steer toward the average heading of nearby birds
separationNoseparation weight (0 to 1): steer away from birds that come too close

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • addedInput schema / properties / alignment / description
      Added value: +"alignment weight (0 to 1): steer toward the average heading of nearby birds"
    • addedInput schema / properties / cohesion / description
      Added value: +"cohesion weight (0 to 1): pull toward the centre of nearby birds"
    • addedInput schema / properties / n / description
      Added value: +"number of birds (10 to 400, default 120)"
    • addedInput schema / properties / noise / description
      Added value: +"noise weight (0 to 1): random heading jitter per tick; 0 is fully deterministic (spec v1 behaviour)"
    • addedInput schema / properties / seed / description
      Added value: +"uint32 PRNG seed; omit for a random one. Same seed and params replay byte-identically"
    • addedInput schema / properties / separation / description
      Added value: +"separation weight (0 to 1): steer away from birds that come too close"
  2. Changed1 schema field changed
    • addedInput schema / properties / noise
      Added value: +{
+  "default": 0,
+  "maximum": 1,
+  "minimum": 0,
+  "type": "number"
+}
  3. First observed

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses determinism (same seed and parameters replay identically), session lifetime (24 hours after last touch), environment shape (1000x600 torus), and the spec v2 change introducing noise. This is strong behavioral context, though it does not describe return values or side effects beyond session creation.

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 then adds valuable context in three additional sentences. The open research question is somewhat extra but supports exploratory use. Overall it is dense with relevant information and avoids redundancy.

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?

The description covers parameters, determinism, environment, and session lifetime well, but it omits what the caller receives upon creation (e.g., a flock ID or session reference) and how to connect subsequent flock_get/flock_step calls. Since there is no output schema, this return-value information should have been included for full completeness.

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 context: it groups the four weighted rules, explains noise is a spec v2 addition, and ties seed determinism to reproducibility. It also mentions the default weights produce a polarized cluster, giving the agent a semantic anchor beyond raw 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 verb and resource: 'Create a new flock simulation,' and immediately adds distinguishing details (n birds, 1000x600 torus, four weighted rules, deterministic seed). This clearly separates it from siblings like flock_create_from_trace and flock_step without needing to inspect schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states what the tool does but gives no explicit guidance on when to choose flock_create over alternatives such as flock_create_from_trace. There is no mention of preconditions, exclusions, or 'use this instead of X when...' context.

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

All Susurration 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

A3.8/5.0
Disambiguation4/5

Most tools are cleanly separated by resource prefix (flock_, experiment_, trace_, proposal_) and action, so an agent can usually tell them apart. The main ambiguity is between experiment_run/experiment_get and the flock_* session tools, since both drive the same four-weight simulation; the descriptions mitigate this by framing experiment_run as the one-call batch alternative.

Naming Consistency4/5

The dominant pattern is <resource>_<action> with readable verbs like create, get, step, browse, submit, and leave, and each resource family is internally consistent. Minor outliers like playground_manifest and what_changed don't follow the verb_noun convention, and browse/get both appear for retrieval, so the naming is mostly consistent but not uniform.

Tool Count4/5

At 15 tools the set sits at the upper edge of the normal range, and the breadth is justified by the playground's dual simulation/experiment and community (traces/proposals) surfaces. It isn't bloated, but the experiment_* pair partially overlaps the flock_* session workflow, making the set feel slightly larger than strictly necessary.

Completeness4/5

The main lifecycle is covered: run/get for experiments, create/step/get/set_params/timeline for flocks, browse/get/leave for traces, and browse/submit for proposals, with manifest and what_changed orienting returning agents. Minor gaps exist—no experiment or flock listing endpoint and no proposal detail/withdraw tool—but discovery is handled through traces and what_changed, so agents can still complete workflows.

Resources