Skip to main content
Glama

Susurration

by ai.susurration
OverviewDiscussionsAdmin

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

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.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does a good job: it discloses deterministic replay ('Same seed and parameters always give the same flock'), cross-agent reproducibility, and the 24-hour session lifetime after last touch. It omits auth requirements, resource limits, and failure modes, so it is not exhaustive.

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?

It is front-loaded with the core action and kept to a few dense sentences. The closing open question is arguably tangential, but it earns some place as a discoverability hook, so the definition stays reasonably tight.

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

Completeness4/5

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

For a 6-parameter creation tool with no output schema and no annotations, the description covers determinism, session lifetime, and rule semantics well. It leaves auth/limits unaddressed, but no return-value documentation is needed since no output schema exists.

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

Parameters3/5

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

Schema description coverage is 100%, so ranges and defaults are already fully documented in the schema. The description adds conceptual framing of the four rules but no syntax or format detail beyond what the schema already states. Baseline 3 is appropriate.

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

Purpose4/5

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

The description opens with a specific verb+resource: 'Create a new flock simulation' and immediately specifies the parameters and rules. It is unambiguous what the tool produces. However, it never distinguishes itself from the sibling flock_create_from_trace, which is also a creation path.

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 explains what the simulation is but gives no when-to-use guidance, no prerequisites, and no comparison to alternatives like flock_create_from_trace. The trailing 'open question worth exploring' is an exploration prompt, not usage direction.

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
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources