Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Phone Vibe

phone_vibe

Styles a phone page to match a music set's mood and chapter changes with presets, colors, images, effects, reactions, and beat-synced transitions.

Instructions

Set the phone page's look to fit the music, so the person feels you there (as the stage does in VR): change it with the mood, on chapter changes. preset: a starting point (default, rain, calm, warm, night, peak), then any part over it. ground/ink/accent: colours ('#rrggbb', 'rgb(r g b)', 'hsl(h s% l%)'); the ground stays dark, ink on ground 7:1 and accent 3:1 or it is refused with what to change. heading: the face of the titles (archivo, fraunces, playfair, cormorant, space grotesk, syne, unbounded, bebas, major mono). image: a picture file (a cover, a Blender still, art another agent made) behind the page, blurred by blur px (0-40) and darkened by dim (0.2-0.9); '' removes it. effect: none, rain, particles, pulse (breathes on the set's beat), grain, aurora, at intensity 0-1. Changes fade over transition_ms. reset=True starts from the default skin; menu=True lists the presets, faces and effects, the current vibe, the saved scenes and the scheduled moves. layers: up to 3 effects at once, drawn in order, each a dict: effect, intensity, speed (0.1-4), density (0-1), size (0.25-4), angle (rain's slant, -60-60), opacity, color, color2, blend (normal, add, screen, multiply, overlay); e.g. [{'effect': 'aurora', 'speed': 0.5}, {'effect': 'rain', 'density': 0.9, 'angle': 25, 'blend': 'add'}]. effect= alone replaces them with one. hue_drift: degrees a minute the colours turn (0 still). at='bar:N': the look lands on bar N as the phone hears it (a drop on its downbeat); each call with at= adds a move, building on the last one, and they play in bar order; ramp_beats: fade into it over that many beats. cancel_moves=True drops the scheduled ones. save='name' keeps the resulting look as a scene; scene='name' starts from a saved one (then any part over it). react: the set's own notes drive the page, each on the beat the phone hears it: {track: reaction} with flash, glow, burst, sparks, drops or ring, or {track: {'do': 'glow', 'color': '#ff8844', 'amount': 0.8}}; 'qrq*' matches every track starting qrq. E.g. {'kick': 'glow', 'qrq': 'sparks', 'stab': 'flash', 'piano': 'drops'}. {} turns it off.

Input Schema

NameRequiredDescriptionDefault
atNo
dimNo
inkNo
blurNo
menuNo
saveNo
imageNo
reactNo
resetNo
sceneNo
accentNo
effectNo
groundNo
layersNo
presetNo
senderNo
headingNo
hue_driftNo
intensityNo
ramp_beatsNo
cancel_movesNo
transition_msNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses color-contrast refusal with corrective feedback, numeric ranges, the three-layer cap, scheduling via at='bar:N' building moves in bar order, cancel_moves, and save/scene persistence. Gaps remain around permissions/scope (which phone/viewers) and explicit overwrite/undo behavior beyond reset.

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, and most of the long text is parameter-dense rather than filler. However, it is delivered as one sprawling block with semicolon-separated clauses, making it hard to scan; some framing ('as the stage does in VR', 'so the person feels you there') is not essential.

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?

Given 22 optional parameters, nested objects, no annotations, and an output schema, the description is substantially complete for correct invocation: it explains most params, constraints, scheduling, and persistence. It is only incomplete on `sender` and on the operational scope of the phone page.

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?

Despite 0% schema-description coverage, the description documents almost every parameter: enums for preset/heading/effect, color formats, blur/dim/intensity ranges, layer dict fields, react mapping syntax, at/ramp_beats, save/scene, reset/menu, and transition_ms. The only schema parameter not addressed is `sender`, which is a concrete omission.

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 opening sentence names the verb and resource ('Set the phone page's look') and frames the intent (fit the music, change with mood/chapter changes), so the tool's job is clear. It does not explicitly contrast with sibling visual/stream/stage tools, so it falls short of the sibling-differentiation bar for a 5.

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 an implied usage context ('change it with the mood, on chapter changes') and explains modes like menu/reset/save/scene, but it never states when to prefer this over alternatives such as stream_visual or stage_scene_* tools. No when-not or exclusion guidance is provided.

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