Skip to main content
Glama
Sign In
SuperCollider OSC MCP

SuperCollider OSC MCP

by Tok
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

stop_all

Idempotent

Immediately silence all audio initiated by the server and cancel scheduled playback to halt ongoing SuperCollider output.

Instructions

Immediately silence every sound started by this server and cancel scheduled playback.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "stop_all"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare idempotent=true, destructive=false, readOnly=false, so the safety profile is covered. The description adds real context beyond that: the stop is immediate (no fade-out), it is scoped only to sounds this server started, and it also cancels scheduled/pending playback — a side effect an agent would not otherwise know.

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?

A single sentence, front-loaded with 'Immediately', containing two distinct and necessary facts (scope of silencing, cancellation of scheduled playback). Nothing is redundant.

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?

Zero parameters plus an existing output schema mean the description need not cover arguments or return values. What remains — immediacy, scope, and scheduled-playback cancellation — is fully addressed for a tool this simple.

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?

There are zero parameters, so the baseline is 4 and there is no schema semantics left to compensate for. The description correctly spends no words on arguments.

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?

The description pairs a specific verb ('silence') with a precisely bounded resource ('every sound started by this server') and adds a second action ('cancel scheduled playback'). It is unmistakably the only teardown tool among siblings that are all creation/playback oriented.

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?

Usage is only implied: an agent can infer this is the panic/cleanup call, but the description never says 'use when you want to halt all audio' nor names any alternative or exclusion. With no sibling stop tools, the routing risk is low, but the guidance is still left to inference.

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