Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Phone Exam

phone_exam

Compare real audio clips against low-fidelity MP3 copies to determine if the ear or the device determines if the sound is real.

Instructions

A blind exam on the phone: clips [{label, path, note?}] each with a play button (the live stream pauses while one plays, and rejoins live after), word chips to tick per clip, one choice (e.g. ['A is the record', 'B is the record', "can't tell"] on a single pair), a note, and Submit. The answers arrive as kind 'exam' {id, answers}, and are appended to answers_path when given (the exam's own answers file, so no "done" is needed). Label clips blind (A, B). It runs exam_check first and refuses on NOT READY: give key={label: class} and secrets=[source names] so the blind-leak checks run too. check=False only when the person asked to see it anyway. On several pairs whose real side moves, ask "real or fake?" per clip (chips): one overall "A or B is real" choice is refused (Nate, metal round 3), and with check=False the reply still warns. floor='auto' adds device floor pairs, the real clip against a 64 or 128 kb/s MP3 copy of itself or against itself: the full set on the first floor round, then one rotating pair; 'full' gives the full set again (a new listening device, or a floor answer that changed). Each costs a slot of the 5-6 pair budget. Clips must be labelled 1A, 1B, 2A ...; they are renumbered around the floor pairs, and the reply (and <answers_path>.floor.json) maps the new labels back to yours and says which side of each floor pair is the MP3. floor_from: the real clip (default: the first clip keyed real, record or ref). A floor pair told apart more often than chance means the phone and the ear separate even an MP3 copy; a floor never told apart means a "can't tell" on a real pair is about the voice, not the device. The pre-flight checks your pairs only (a floor pair is one clip against itself, in WAV beside clips of any format), and a refused exam uses up no floor round. measured: what you measured before spending the person's ear, {clip label, pair number or 'all': the lines your instruments gave, with their numbers}; or unmeasured='' (logged in ear_first.jsonl). One of the two is required (the person, 10-16: measure first, then spend my ear). Either is kept beside the answers (<answers_path>.measured.json) for the exam ledger.

Input Schema

NameRequiredDescriptionDefault
keyNo
waitNo
checkNo
chipsNo
clipsYes
floorNo
titleYes
senderNo
choicesNo
exam_idNo
secretsNo
measuredNo
questionNo
floor_fromNo
unmeasuredNo
answers_pathNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and discloses many behaviors: the live stream pauses during playback and rejoins live, answers are appended to answers_path, files like <answers_path>.floor.json and <answers_path>.measured.json are written, exam_check is run first and can refuse on NOT READY, and warnings are emitted under certain conditions. It does not cover permission requirements, but the behavioral disclosure is strong.

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

Conciseness2/5

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

The description is a dense, run-on wall of text with parentheticals, examples, and an anecdote ('Nate, metal round 3'). It is not front-loaded with a clear summary and many sentences are convoluted, making it hard to parse quickly despite containing relevant operational detail.

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?

Given 16 parameters, zero schema description coverage, and no annotations, the description is quite detailed about exam flow, floor pairs, pre-flight checks, and measurement requirements. However, several parameters remain undocumented and there is no mention of how required fields like title or clips should be structured beyond a brief example, leaving clear gaps for an agent to fill.

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 0%, so the description must compensate. It explains key, secrets, check, floor, floor_from, measured, unmeasured, answers_path, chips, choices, and clips in some detail, but it leaves wait, sender, exam_id, question, and title semantics unaddressed. The partial coverage justifies a middle 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 opens with 'A blind exam on the phone' and details the clips, chips, choices, note, and Submit flow, making the purpose clear: run a phone-based blind listening exam. It distinguishes itself from exam_check by noting that exam_check runs first, but it does not sharply differentiate from visual exam siblings like exam_picture_score.

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

Usage Guidelines3/5

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

It gives conditional guidance for parameters such as 'check=False only when the person asked to see it anyway' and explains when to use floor='auto' or 'full'. However, it never explicitly states when to choose phone_exam over alternatives like exam_picture_score or exam_eye_score, leaving tool selection implicit.

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