Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Chat Commands

chat_commands

Parses and acts on chat !request, !vote, and !love commands using venue rules: queues or refuses DJ requests, counts votes, and enforces per-viewer reward rate limits.

Instructions

Handle chat's !request <text>, !vote <id> and !love by the venue's rules (venue_rules), the same way every time: a request is queued for the DJ, refused (too many waiting, too soon, too long, closed) or, when one like it is waiting, counted as a vote for that one; a vote moves a request up; a !love counts for what plays (request_next shows them) with no reply. One !vote or !love per viewer per reward_s seconds (venue_rules), so the reward channel cannot be spammed. Reach for it when chat_watch returns lines with commands in them. lines: chat_watch's JSON as it came (or its lines). Returns JSON {replies: [{reply_to, text}], handled, left}: say each reply with chat_say(text, reply_to=...). A line is acted on once, however often it is handed in. left: commands it does not decide (!vote a in a vote of yours), and every other line is yours as before.

Input Schema

NameRequiredDescriptionDefault
linesYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations, so the description carries the full burden and does: it discloses the decision rules (queue, refuse for queue-length/too-soon/too-long/closed, near-duplicate counted as vote), rate limiting one vote/love per viewer per reward_s seconds, that `!love` produces no reply, and that a line is acted on once regardless of repeated handoff. These are exactly the side-effect/idempotency facts an agent needs.

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?

Front-loaded with the commands and their outcomes, then usage trigger, then input/return semantics. Dense and mostly earned, though the refusals and vote-counting are packed into a long clause chain that takes a second read.

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?

Return shape is spelled out ({replies, handled, left}) and the follow-up action for each reply is given, so the agent can close the loop. Referenced dependencies (venue_rules, request_next, reward_s) are named with their role. Nothing material is missing for a one-parameter tool.

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% and the single parameter is untyped in the schema, but the description compensates by explaining `lines` accepts chat_watch's JSON as-is or just its lines array. That is the critical semantic; it stops short of a formal shape example but is sufficient.

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?

States a specific verb+resource (handle chat's `!request`, `!vote`, `!love`) and enumerates the exact command syntax it owns. Sibling tools chat_watch/chat_say are functionally distinguished: this tool consumes chat_watch output and defers speaking to chat_say.

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

Usage Guidelines5/5

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

Explicit trigger: reach for it when chat_watch returns lines with commands in them. Explicit handoffs: replies go out via chat_say(text, reply_to=...), and undecided commands come back in `left`. No ambiguity about when this tool applies vs alternatives.

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