Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Tell Measure

tell_measure

Records a per-round metric measurement for an open tell, comparing our result with a target so you can track whether the performance gap shrinks over time.

Instructions

One measured row for a tell: ours against the target on one metric (the same metric name every round), so the ledger sees whether the gap shrinks. gap = ours - target unless given (a distance is its own gap: target=0). Instead of typing numbers, pass a measuring op's reply (or the path of a saved reply or .json report) as reply=: sound_compare(a=ours, b=the reference) gives distance, bands, envelope, width, pitch clarity, centroid and 'band '; region_measure gives share, box, reference band (its target from target_reply=, the same measure on the reference, or target=); sound_zoom_diff gives grain, strokes, plumes (mean |z|, target the controls'). pull: which number (default the metric). round: the round's name; source: the files or run. Reach for it every round, once per open tell.

Input Schema

NameRequiredDescriptionDefault
idYes
gapNo
oursNo
pullNo
whenNo
replyNo
roundNo
metricYes
sourceNo
targetNo
projectYes
target_replyNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the burden and does explain that it writes a measured row into a ledger and how gap is computed (ours - target, with target=0 as a distance case). However, it does not clearly disclose mutation side effects, idempotency, required open-tell state, or permission needs, leaving important behavioral traits implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the description is a dense, jargon-heavy block with nested clauses and semicolon-separated reply-source details. It is appropriately information-rich for a 12-parameter tool, yet structure could be improved for readability.

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?

For a 12-parameter tool with no annotations, it covers reply semantics and gap calculation well enough to call it. It still leaves key identifiers (project, id, when) unexplained and does not describe mutation behavior or prerequisites, which are notable gaps given the lack of annotations.

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 0%, so the description must compensate, and it does for the most complex parameters: reply, target_reply, pull, round, source, gap, ours, and target are all given meaning. Core identifiers project, id, and when remain undocumented, preventing a top score.

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 states a specific resource and action: recording one measured row for a tell, comparing 'ours' against 'target' on a metric. It clearly implies the ledger/gap-tracking purpose, though the terminology ('tell', 'ledger') is domain-specific and it does not explicitly differentiate itself from sibling tools like tell_add or tell_status.

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 gives explicit cadence guidance: 'Reach for it every round, once per open tell.' It also explains how to supply values via reply= from specific measuring operations instead of typing numbers, which is directly actionable. It does not state when not to use it or what happens if the tell is not open.

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