Skip to main content
Glama

Susurration

by ai.susurration

flock_timeline

Fetch the metrics series over past ticks (the server keeps the last 5000), with an optional stride to thin the series. This is the tool for locating transitions: polarization tends to change fastest inside a narrow band of ticks. Where is that band for your parameters, and does the separation weight shift it?

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNolast tick, inclusive; defaults to the current tick and may not exceed it
fromNofirst tick, inclusive; defaults to the earliest tick still buffered (the timeline keeps a bounded ring of recent ticks)
strideNoreturn every Nth tick (1 to 100, default 1)
flock_idYesflock session id, as returned by flock_create

Schema Changelog

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

  1. Changed4 schema fields changed
    • addedInput schema / properties / flock_id / description
      Added value: +"flock session id, as returned by flock_create"
    • addedInput schema / properties / from / description
      Added value: +"first tick, inclusive; defaults to the earliest tick still buffered (the timeline keeps a bounded ring of recent ticks)"
    • addedInput schema / properties / stride / description
      Added value: +"return every Nth tick (1 to 100, default 1)"
    • addedInput schema / properties / to / description
      Added value: +"last tick, inclusive; defaults to the current tick and may not exceed it"
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose the 5000-tick retention bound, the bounded ring behavior implied by the schema, and stride thinning. However, it does not describe the output format, ordering, or whether any side effects occur, so it is only partially transparent.

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?

Two sentences, with the core fetch behavior front-loaded and the usage heuristic following compactly. The rhetorical closing question adds analytical flavor but does not bloat the definition significantly.

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 purpose, retention, and stride, and the schema handles parameter constraints. However, with no output schema, the description does not clarify what fields or shape the 'metrics series' returns, which is a meaningful gap for an agent deciding how to consume the result.

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 the schema already documents all four parameters with clear semantics. The tool description adds the idea of thinning via stride and the notion of tick ranges, but it does not meaningfully go beyond the parameter descriptions already present.

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 states a specific action ('Fetch'), a clear resource ('metrics series over past ticks'), and useful scope details ('last 5000', optional stride). The phrase 'This is the tool for locating transitions' gives it a distinct identity among siblings like flock_get and flock_step.

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

Usage Guidelines4/5

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

It explicitly frames when to use the tool: for locating transitions, with a concrete heuristic about polarization changing fastest in a narrow band of ticks. It does not name sibling alternatives or state when not to use it, but the usage context is clear.

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