Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Phone Panel Show

phone_panel_show

Display a phone-page panel with text, media, buttons, and inputs to collect a decision or structured answer, optionally blocking until the response arrives.

Instructions

A panel over the phone page (the stage_panel_show shape): title, text, an image file, a video file, buttons (labels), and inputs for a fuller answer: [{'id', 'kind': 'choice' (one of options) | 'check' (any of options) | 'toggle' (on or off) | 'text', 'label', 'options', 'optional'}]. A choice must be picked before a button sends (unless 'optional': true). A tap arrives as kind 'answer' {id, answer, values: {input id: value}, for: sender}; Not now (on every panel) arrives as kind 'answer' with dismissed: true and answer null, which is not an answer. wait=N blocks up to N seconds for it. Every panel has a record button: what they say on it arrives as kind 'voice' and 'voice_text' with panel= and for=, so pass sender (your name) to get it back. video=: the person watches it playing inline in the panel, next to the panel's buttons, inputs and voice reply (the video pauses when they start to record), so they can watch and then ask questions about it. image=: a tap opens it full screen, where they can pinch to zoom and move around it. Any agent that controls the phone may use it. A phone-sized copy (H.264 + AAC MP4, at most 720 px tall) is made first, once per file and kept, inside the machine's cpu slot like any heavy job: video_wait is how long to stand in line for the machine ('10m'; '0' refuses at once when it is busy). It needs ffmpeg. priority: 'needs you' (sorts first, and the corner key takes the accent colour while it is open), 'normal' (the default) or 'low' (sorts last). link=: a big button in the panel that opens a page of this server in the same tab; it must start with one '/' (anything else is refused). The picture round is '/eye/?from=phone' (see exam_picture_round), with link_label naming the button. A panel never pops up: it shows as a message on the page's corner key (a short buzz), and the person opens it when they choose, switches between open messages, or puts one back with Later. Send one only for something to decide; say everything else in a caption. Refused: a title, text, button or input naming a place or personal detail from the local private terms (rephrase it), and a yes/no or approve/deny panel (its buttons, or a choice's options, are yes and no words) whose title or text a standing grant covers: act on the grant, then post a caption saying what you did. override_grant='' shows it anyway and logs the reason (phone.md).

Input Schema

NameRequiredDescriptionDefault
linkNo
textNo
waitNo
imageNo
titleNo
videoNo
inputsNo
senderNo
buttonsNo
panel_idNo
priorityNo
link_labelNoOpen
video_waitNo10m
override_grantNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.1/5.0
Behavior5/5

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

With zero annotations the description carries the full burden and does so: it explains the panel never pops up (corner key, short buzz, Later), the exact reply shapes for answer/dismissed/voice, that wait blocks up to N seconds, that video is transcoded to H.264/AAC 720px in the cpu slot and needs ffmpeg, priority ordering effects, and the grant/override refusal path with logging.

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?

Purpose is front-loaded, but the body is a dense, unstructured wall of text mixing parentheticals, reply-shape literals and infrastructure notes; sentences are long and multiple concerns are run together, making it harder to scan than it needs to be.

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

Completeness4/5

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

For a 14-parameter, annotation-free tool this covers the critical operational facts (blocking, refusal, media prep, priority) and an output schema exists so return values need not be described. The main residual gap is the unexplained panel_id and the absence of any explicit sibling routing.

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 largely does: it defines the inputs array item shape and kinds, button labels, wait, video, video_wait, image, priority, link/link_label rules, sender and override_grant. Only panel_id goes essentially unexplained, and a few params (e.g. sender's exact role in routing voice replies) are implied rather than stated.

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?

States a specific verb and resource: shows a panel on the phone page with title, text, image, video, buttons and inputs, and ties itself to 'the stage_panel_show shape'. An agent understands the artifact immediately, though the many adjacent phone-panel siblings (phone_ask, phone_offer, phone_buttons, stage_panel_show) are never explicitly separated out.

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?

'Send one only for something to decide; say everything else in a caption' is a clear when-to-use / when-not rule, and the refusal paragraph names concrete conditions to avoid. It stops short of naming which sibling (e.g. phone_ask) to reach for instead when the intent is not a decision.

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