Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Tell Judged

tell_judged

Record a person's blind-round verdict on a tell — passed, failed, or better — with its source and notes, to track whether it was caught and close it once a passed verdict follows.

Instructions

The person's verdict on a tell after a blind round: passed (they could not tell it), failed (they caught it) or better (still there, less). source: the exam, panel or voice note; words: theirs, 20 words or fewer; when: UTC ISO (default now). Closing a tell needs a passed verdict after its last measure.

Input Schema

NameRequiredDescriptionDefault
idYes
whenNo
roundNo
wordsNo
sourceYes
projectYes
verdictYes

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 must carry the full behavioral burden. It usefully explains verdict categories, source options, word limit, default timestamp, and the closing condition, but does not state whether the verdict is stored, whether it overwrites prior verdicts, or what permissions/effects apply.

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 a compact paragraph with useful details front-loaded: verdict semantics first, then source/words/when, then the closing rule. It is dense but not padded.

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?

An output schema exists, so return values need not be described. However, given many tell_* siblings and no annotation coverage, the description should say more about how this relates to tell_check, tell_measure, tell_status, and what 'round' means. It is sufficient for basic invocation but not fully complete for correct selection in context.

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 explain all seven parameters. It meaningfully explains verdict, source, words, and when, but leaves project, id, and round undocumented, so it only partially compensates for the schema gap.

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 clearly identifies the resource and event: a person's verdict on a tell after a blind round, with three verdict meanings. It does not explicitly name sibling tools like tell_check or tell_measure, but the 'after a blind round' scope helps distinguish it from measurement/check tools.

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 a clear usage context ('after a blind round') and a workflow rule ('Closing a tell needs a passed verdict after its last measure'). It does not explicitly state when not to use it or name alternatives, so it falls short of the top score.

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