Skip to main content
Glama
newsbubbles

ismail: agent DAW (MCP server)

Stream Look

stream_look

Inspect live stream health and preview context by reading venue connection status, sent megabytes, sound source, encoder, text lines, and refreshed preview frame paths.

Instructions

How the stream is doing: each venue (live, reconnecting with the site's error, MB sent), the sound source, the encoder, the text lines, and the path of a preview frame (refreshed every 2 s): Read it to see the picture.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A3.6/5.0
Behavior4/5

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

No annotations are present, so the description carries the full burden; it discloses the reported fields (venue status, sound source, encoder, text lines, preview frame path) and the refresh interval of the preview frame. It does not explicitly state that the tool is read-only or side-effect-free, but the 'look' framing and data list make that clear.

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 single sentence is front-loaded with 'How the stream is doing' and then lists the included information, so the key purpose is immediately visible. The list is dense but not wasteful; it could be split for readability but remains efficient.

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?

An output schema exists, so the description need not explain return values in detail; nevertheless, it adds useful context about refresh timing and included fields. For a zero-parameter diagnostic tool with no annotations, this is nearly complete, though it could clarify when to use it over stream_status.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter meaning, and what it provides about output contents is supplementary rather than redundant.

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 states a specific resource (stream status) and enumerates the data items it reports, so an agent knows it returns a diagnostic snapshot. However, it never distinguishes this from similar siblings like stream_status or stream_visual, leaving the agent to guess when this tool is preferable.

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

Usage Guidelines2/5

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

The only usage hint is 'Read it to see the picture,' which is an implied instruction but no explicit when-to-use, when-not-to-use, or alternative tool guidance is given. With many stream-related siblings, the lack of routing information is a clear gap.

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