Skip to main content
Glama

Delete a stream

delete_stream
DestructiveIdempotent

Use this only when the user asks to stop monitoring a stream. AudD stops recognizing it and removes it from the account; this cannot be undone (add the stream again to resume).

Input Schema

NameRequiredDescriptionDefault
radio_idYesThe integer that identifies the stream on this account (see list_streams)

Output Schema

NameRequiredDescriptionDefault
deletedYes
radio_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds real value: the operation is irreversible ('this cannot be undone'), the stream is removed from the account, and the recovery path is stated (add it again to resume). That is meaningful behavioral context beyond the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the usage constraint is front-loaded and the consequence/recovery is second. No filler, no repetition of the title, and every clause carries information an agent needs.

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 return values need not be described, and annotations cover the safety profile. Combined with the irreversibility warning and the resume path, the description is nearly complete for a one-parameter destructive tool; only explicit framing of the delete-vs-update choice among siblings is missing.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single parameter with 100% schema coverage, and the schema already explains radio_id and points to list_streams for discovery. The description adds no syntax, format, or ID-resolution detail beyond what the schema provides, so the baseline of 3 applies.

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 gives a specific verb+resource ('stop monitoring a stream') and details the concrete effect: AudD stops recognizing it and removes it from the account. It is clearly distinguishable from siblings like list_streams, add_stream, and update_stream_url, though it never names an alternative explicitly.

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?

The opening clause 'Use this only when the user asks to stop monitoring a stream' gives an explicit trigger plus an implicit exclusion ('only'), which is strong when-to-use guidance. It stops short of naming alternatives (e.g., update_stream_url for changing rather than removing) or stating preconditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources