Skip to main content
Glama

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.

  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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources