Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Phone Watch

phone_watch

Blocks until the person sends new messages, returns those lines oldest first, and saves a per-role cursor so a restarted watcher resumes without skipping.

Instructions

The standing phone watcher: blocks until the person sends something, returns it, and remembers its place. Run it in the background (python -m ismail phone_watch "who=<your role>"), act on what it returns, and re-arm it FIRST after every wake, before any other work. Never write your own watcher. It loops phone_listen(who, page=True) and returns every wanted line (a burst gathered with one more short look), oldest first, as JSON {lines, since, next}: nothing filtered by owner; only page telemetry (every page action but panel_close) and the 'voice' transcribing line (its words follow as voice_text) stay out. The cursor is saved per who (~/.ismail/phone/cursors/) only when it returns, so a killed watcher never skips a line and a re-arm resumes where the last return left off. since: start after this inbox line instead. With no saved cursor and no since it starts at the end of the inbox (history is never replayed) and says so. wait_min: after this many minutes with nothing it returns {alive: true} so you re-arm and read phone_status (a background task may be stopped at 2 hours). round=: you let a round of someone else's cards run: its lines are held (counted, not returned) and the watcher wakes on anything else, or 90 s after the round's last line. A phone server restart is waited out (it looks again every 10 s). lead=true: you are the team lead: the heartbeat's alarms (an agent's watcher down while the person is live) come to you, and you wake that agent. An alarm addressed to another watcher does not wake you.

Input Schema

NameRequiredDescriptionDefault
whoYes
leadNo
roundNo
sinceNo
wait_minNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so extensively. It discloses blocking behavior, return shape, filtering rules, cursor persistence, re-arm semantics, wait_min behavior, round holding behavior, server restart handling, and lead alarm routing.

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 front-loaded with purpose and key workflow, and nearly every sentence carries necessary lifecycle or parameter detail. It is dense and somewhat run-on in places, but the length is justified for a complex blocking watcher with five parameters and no annotation support.

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

Completeness5/5

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

For a complex blocking tool with an output schema, no annotations, and zero schema parameter descriptions, the description is complete enough to call it correctly. It covers lifecycle, cursor state, filtering, idle returns, round mode, restart behavior, and lead mode.

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

Parameters5/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 define every parameter, and it does: who is the role, since is a starting inbox line, wait_min is the idle return interval, round is a card-id prefix whose lines are held, and lead routes team-lead alarms. This is far beyond what the bare schema provides.

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 role and behavior: 'The standing phone watcher: blocks until the person sends something, returns it, and remembers its place.' It distinguishes the tool from sibling phone_listen by explaining that phone_watch loops phone_listen and must not be reimplemented. An agent can identify exactly what this tool is for.

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 strong operational context: run it in the background, act on returns, and re-arm it first after every wake. It also names phone_listen and phone_status in the workflow. However, it does not explicitly say when to use phone_watch instead of phone_listen or chat_watch for one-off reads, so usage guidance is clear but not fully comparative.

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