Skip to main content
Glama
Benedict

TidalCycles MCP Server

by Benedict
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

🌀 TidalCycles MCP Server

Conversational live coding with Claude AI + TidalCycles

License: MIT Node Version

This MCP (Model Context Protocol) server enables Claude to control TidalCycles through natural conversation, creating a powerful AI-assisted live coding experience for algorithmic music composition.

✨ Features

  • 🎵 Evaluate TidalCycles patterns through conversational AI

  • 📊 State awareness - Claude knows what's currently playing

  • 🕰️ Pattern history - Track and recall previous patterns

  • 🎛️ Channel management - Solo, silence, or hush specific channels

  • 💬 Natural conversation - Talk to Claude about your music in plain English

  • 🔄 Real-time feedback - Immediate pattern evaluation

  • 🚀 Dual transport modes: stdio for Claude Desktop + WebSocket for external clients

  • 🌐 Network accessible - Web UIs and remote clients can connect via WebSocket

  • 🔄 Auto-recovery - Robust GHCi process management with automatic reconnection

Related MCP server: supercollider-mcp

📋 Prerequisites

Before installing, ensure you have:

  1. TidalCycles - Install from tidalcycles.org

    • Includes GHCi (Glasgow Haskell Compiler Interactive)

    • Haskell Stack or Cabal

  2. SuperCollider + SuperDirt - Required for audio output

    • Download from supercollider.github.io

    • Install SuperDirt: In SuperCollider, run Quarks.install("SuperDirt")

    • Install samples: Quarks.install("Dirt-Samples")

  3. Claude Desktop - Get from claude.ai

  4. Node.js 18+ - For running the MCP server

🚀 Quick Start

1. Installation

# Clone the repository
git clone https://github.com/yourusername/tidal-mcp-server.git
cd tidal-mcp-server

# Install dependencies
npm install

# Build the server
npm run build

2. Start SuperCollider

Open SuperCollider and run:

// Start SuperDirt
SuperDirt.start;

// Verify it's listening
// Should see: "SuperDirt: listening to Tidal on port 57120"

3. Configure Claude Desktop

Add this to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

File-based Mode (Recommended for stability):

{
  "mcpServers": {
    "tidal": {
      "command": "node",
      "args": [
        "/absolute/path/to/tidal-mcp-server/dist/index.js"
      ],
      "env": {
        "TIDAL_FILE": "/absolute/path/to/tidal-mcp-server/tidal-mcp-output.tidal"
      }
    }
  }
}

Direct GHCi Mode (Experimental - no restarts):

{
  "mcpServers": {
    "tidal": {
      "command": "node",
      "args": [
        "/absolute/path/to/tidal-mcp-server/dist/index.js"
      ],
      "env": {
        "TIDAL_FILE": "/absolute/path/to/tidal-mcp-server/tidal-mcp-output.tidal",
        "TIDAL_USE_GHCI": "true",
        "TIDAL_BOOT_PATH": "/absolute/path/to/tidal-mcp-server/BootTidal.hs",
        "GHCI_PATH": "/usr/local/bin/ghci"
      }
    }
  }
}

Finding your ghci path:

which ghci
# Use this path for GHCI_PATH

Replace /absolute/path/to/ with the actual path to your installation.

4. File Watching Setup (File-based mode only)

For file-based mode, you need to watch the output file and evaluate it in TidalCycles:

Option A: Using watchexec (recommended)

# Install watchexec
brew install watchexec  # macOS
# or
cargo install watchexec-cli  # Any OS with Rust

# Watch and auto-reload patterns
cd /path/to/tidal-mcp-server
watchexec --restart -w tidal-mcp-output.tidal \
  "ghci -ghci-script BootTidal.hs -ghci-script tidal-mcp-output.tidal"

Option B: Using your editor

Open tidal-mcp-output.tidal in your preferred editor with TidalCycles support and manually evaluate patterns when Claude writes them.

5. Start Using

  1. Restart Claude Desktop to load the MCP server

  2. Start a new conversation

  3. Make music!

You: Create a funky drum pattern

Claude: [calls tidal_eval]
       I'll create a syncopated funk groove:
       d1 $ sound "bd ~ bd ~ bd ~ ~ ~"

You: Add a bassline

Claude: [calls tidal_eval on d2]
       Added a groovy bassline:
       d2 $ sound "bass2*8" # n "0 3 5 7"

🎹 Usage Examples

Basic Patterns

You: Play a simple drum beat
You: Make it faster
You: Add some hi-hats
You: What's playing right now?

Advanced Composition

You: Create a glitchy breakbeat with euclidean rhythms
You: Add a wobbling bassline with filter sweeps
You: Layer some atmospheric pads over the top
You: Make the whole thing more sparse

Live Performance

You: Solo channel d2
You: Bring back everything
You: Hush
You: Show me the last 5 patterns I evaluated

🛠️ Available Tools

The MCP server exposes these tools to Claude:

tidal_eval

Evaluate a TidalCycles pattern on a specific channel (d1-d9).

Parameters:

  • channel: String (d1-d9)

  • pattern: String (TidalCycles code without the d1 $ prefix)

Example:

{
  "channel": "d1",
  "pattern": "sound \"bd sd bd sd\" # gain \"1.2\""
}

tidal_hush

Stop all currently playing patterns immediately.

tidal_silence

Stop a specific channel gracefully.

Parameters:

  • channel: String (d1-d9)

tidal_get_state

Get current state of all channels - what's playing and when it started.

tidal_solo

Solo a specific channel, muting all others.

Parameters:

  • channel: String (d1-d9)

tidal_unsolo

Restore all channels after soloing.

tidal_get_history

Get pattern history from the current session.

Parameters:

  • limit: Number (optional, default: 10)

📁 Project Structure

tidal-mcp-server/
├── src/
│   ├── index.ts              # Main MCP server implementation
│   └── websocket-transport.ts # WebSocket transport layer
├── dist/                     # Compiled JavaScript output
├── BootTidal.hs             # TidalCycles initialization
├── tidal-mcp-output.tidal   # Generated pattern output file
├── start-websocket.sh       # WebSocket server startup script
├── test-websocket-client.js # WebSocket connection test
├── examples.tidal            # Example patterns
├── WEBSOCKET-USAGE.md       # WebSocket setup and usage guide
├── package.json             # Node.js dependencies
├── tsconfig.json            # TypeScript configuration
├── README.md                # This file
├── QUICKSTART.md            # Quick reference guide
├── CONTRIBUTING.md          # Contribution guidelines
└── LICENSE                  # MIT License

🎨 Use Cases

Live Performance

  • Generate patterns on the fly during algoraves

  • Quick iterations and experimentation

  • Emergency pattern generation when stuck

  • AI-assisted improvisation

Learning & Exploration

  • Ask Claude to explain TidalCycles concepts

  • Generate example patterns for specific techniques

  • Explore new rhythmic and harmonic ideas

  • Learn by conversation

Composition

  • Rapid prototyping of musical ideas

  • Generate pattern variations

  • Collaborative composition with AI

  • Build complex layered arrangements

🔧 Architecture

┌─────────┐         ┌──────────────┐         ┌──────────────┐
│ Claude  │ ◄─MCP─► │  MCP Server  │ ◄─────► │ TidalCycles  │
│   AI    │         │  (Node.js)   │         │    (GHCi)    │
└─────────┘         └──────────────┘         └──────────────┘
                            │                         │
                            │ (File mode)             │
                            ▼                         ▼
                    ┌──────────────┐         ┌──────────────┐
                    │ .tidal file  │         │ SuperCollider│
                    │   (watch)    │         │  SuperDirt   │
                    └──────────────┘         └──────────────┘

Flow:

  1. You talk to Claude in natural language

  2. Claude uses MCP tools to generate Tidal code

  3. MCP server either:

    • File mode: Writes code to .tidal file → File watcher evaluates it

    • Direct mode: Sends directly to running GHCi process

  4. TidalCycles/GHCi sends OSC messages to SuperDirt

  5. SuperCollider/SuperDirt plays the audio

🐛 Troubleshooting

"MCP server not connecting"

  • Check the path in claude_desktop_config.json is absolute

  • Restart Claude Desktop after config changes

  • Check Node.js version: node --version (need 18+)

  • Check MCP server logs in Claude Desktop

"Patterns not playing" (File mode)

  • Ensure SuperCollider is running: SuperDirt.start

  • Verify file watcher (watchexec) is running

  • Check the TIDAL_FILE path is correct

  • Try manually evaluating the file in your editor

"Patterns not playing" (Direct GHCi mode)

  • Check ghci is in PATH: which ghci

  • Verify GHCI_PATH in config matches which ghci

  • Check MCP server logs for "GHCi/TidalCycles started and connected"

  • Ensure only one GHCi instance is running

"spawn ghci ENOENT"

  • GHCi not found in PATH

  • Set GHCI_PATH environment variable with full path

  • On macOS with ghcup: usually /Users/username/.ghcup/bin/ghci

"No samples found" / Empty sound library

  • Install Dirt-Samples in SuperCollider:

    Quarks.install("Dirt-Samples");
// Recompile (Cmd+K)
SuperDirt.start;

  • Verify: ~dirt.soundLibrary.buffers.keys.do({|x| x.postln});

"Late" messages in SuperCollider

  • Normal at fast tempos (jungle/DnB)

  • If severe (>1 second), restart SuperDirt

  • Check system audio settings

  • Reduce pattern complexity

Music continues after stopping MCP server

  • Patterns run in SuperCollider, independent of MCP server

  • Stop in SuperCollider: s.freeAll;

  • Or in any GHCi/Tidal session: hush

  • Kill all ghci processes: pkill -9 ghci

🚧 Known Limitations

  • File mode: Restarts GHCi on every change (causes brief audio dropout)

  • Direct GHCi mode: Experimental, may have edge cases

  • No visual feedback: Pattern changes aren't visible in editor (file mode)

  • Single instance: Can't run multiple MCP servers simultaneously

  • No undo: Pattern changes are immediate and can't be undone

🗺️ Roadmap

✅ Completed Features

  • Direct GHCi integration - Real-time pattern evaluation without file watching

  • WebSocket transport - Network-accessible server for web UIs and collaboration

  • Robust error handling - GHCi process recovery and connection monitoring

  • Session logging - Complete pattern history with timestamps

🚀 Next Up (Priority Features)

  • MIDI Controller Input - Physical knobs/faders control Tidal parameters

    • MIDI learn mode for easy mapping

    • Support for popular controllers (Push, Launchpad, etc.)

    • Macro controls for complex parameter automation

  • Pattern Version Control - Git-like history for your patterns

    • Undo/redo system with branching

    • Save/restore snapshots

    • Compare pattern versions

  • Browser-based UI - Real-time pattern visualization

    • Live waveform display

    • Channel timeline view

    • WebSocket integration for multiple UIs

🌟 Advanced Features

  • Real-time Audio Analysis - AI gets audio feedback

    • Frequency analysis to inform pattern choices

    • Beat detection for tempo sync

    • Amplitude monitoring for mix balance

  • AI Pattern Suggestions - Context-aware recommendations

    • ML-based pattern generation

    • Style-specific suggestions (techno, ambient, breaks)

    • Automatic complementary pattern creation

  • Multi-user Collaboration - Live coding sessions

    • Multiple users control different channels

    • Turn-based jamming modes

    • Shared pattern library

🎨 Creative Integrations

  • Hydra Visual Integration - Reactive visuals

    • Auto-generate visuals from audio patterns

    • Synchronized visual effects with beat events

    • Live visual coding alongside audio

  • DAW Integration - Professional workflow

    • MIDI output to hardware synths

    • Audio recording of Tidal sessions

    • Timeline sync with Ableton Live/Logic

  • AI Composition Tools - Advanced creativity

    • Generate full track structures

    • Style transfer between genres

    • Harmony analysis and suggestions

🤝 Contributing

Contributions are welcome! Please see CONTRIBUTING.md for guidelines.

Quick start for contributors:

# Clone and setup
git clone https://github.com/yourusername/tidal-mcp-server.git
cd tidal-mcp-server
npm install

# Development mode (with auto-rebuild)
npm run dev

# Run tests
npm test

# Build for production
npm run build

📚 Resources

📄 License

MIT License - see LICENSE file for details.

🙏 Acknowledgments

  • Alex McLean (yaxu) for creating TidalCycles

  • The TOPLAP and algorave communities for live coding culture

  • Anthropic for the Model Context Protocol and Claude

  • Everyone who live codes and makes weird music with computers

📞 Support

Made with 🌀 for the live coding community

Go forth and make some algorithmic noise!

Available Tools

7 tools
tidal_evalA

Evaluate a TidalCycles pattern on a specific channel (d1-d9). This is the main way to make music with Tidal.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelYesThe channel to evaluate on (d1, d2, ... d9)
patternYesThe TidalCycles pattern to evaluate (without the 'd1 $' prefix)

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided; description only states evaluation on a channel without disclosing side effects such as whether previous patterns on that channel are stopped, real-time audio behavior, or prerequisites like having TidalCycles running.

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?

Two sentences directly convey core purpose and a key usage note, but could be slightly more structured with additional behavioral context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema; description omits important context like what happens when a pattern is evaluated (e.g., looping sound, replaces existing pattern), and prerequisites for use.

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 100%, but the description adds value by specifying 'without the 'd1 $' prefix' for the pattern parameter, clarifying usage beyond the schema definition.

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 clearly states the verb 'Evaluate' and the resource 'TidalCycles pattern on a specific channel (d1-d9)', and positions it as the main way to make music, distinguishing it from sibling tools like tidal_hush or tidal_solo.

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 says 'This is the main way to make music with Tidal,' implying primary use, but lacks explicit when-to-use or when-not-to-use guidance, and does not mention alternatives among siblings.

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

tidal_get_historyA

Get the history of patterns evaluated in this session.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of history items to return (default: 10)

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It correctly implies a read operation with no side effects, but does not disclose any additional behavioral traits such as session scoping behavior or memory implications.

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?

The description is a single, front-loaded sentence with no unnecessary words. Every part earns its place.

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?

For a simple read tool with one optional parameter, the description is mostly complete. However, it could mention that history items likely contain pattern text and evaluation status, as no output schema exists.

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?

The schema already describes the 'limit' parameter at 100% coverage. The description adds no additional meaning beyond what is in the schema, so the baseline of 3 is appropriate.

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 clearly states the verb 'Get', the resource 'history of patterns', and the scope 'in this session'. It effectively distinguishes the tool from siblings like tidal_eval (evaluate pattern) and tidal_get_state (get current state).

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 description provides no guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. The agent must infer usage from the tool name and context.

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

tidal_get_stateA

Get the current state of all channels - what patterns are playing and when they started.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention side effects, permissions, rate limits, or whether the operation is read-only. The description only states the basic action without addressing safety or impact.

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?

The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose and the data it returns.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should explain return values. It partially does by mentioning 'what patterns are playing and when they started', but it does not describe the format (e.g., list, object, field names). Given the simplicity of the tool, this is adequate but not complete.

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 no parameters (schema coverage 100%), so the baseline score is 4. The description does not need to add parameter meaning since none exist.

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 clearly states the verb 'Get' and the resource 'state of all channels', and it lists what information is included (patterns and start times). It distinguishes from sibling tools like tidal_get_history (history) and tidal_solo/unsolo (actions).

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?

The description implies usage for obtaining current state, but it does not explicitly state when to use this tool versus alternatives like tidal_get_history or when not to use it. No exclusions or prerequisites are mentioned.

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

tidal_hushA

Stop all currently playing patterns immediately. Use this to clear everything.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries full responsibility. It clearly states the tool stops all patterns 'immediately' and 'clears everything,' which is sufficient for a simple action. No hidden side effects are omitted.

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 sentences, no wasted words. The first sentence front-loads the action, and the second provides context.

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?

Given no parameters or output schema, the description fully explains what the tool does and when to use it. No gaps remain.

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 baseline is 4. The description does not need to add parameter info, and schema coverage is 100%.

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 clearly states the tool stops all currently playing patterns immediately. It uses a specific verb ('stop') and resource ('patterns'), and distinguishes from siblings like tidal_solo or tidal_silence by implying a global stop action.

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 description includes the phrase 'Use this to clear everything,' which implies when to use it. While it doesn't explicitly list exclusions or alternatives, the context of sibling tools (solo, unsolo, silence) makes the usage clear.

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

tidal_silenceA

Stop a specific channel. More graceful than hush for single channels.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelYesThe channel to silence (d1-d9)

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It only states 'stop' and 'more graceful' without explaining what 'graceful' entails (e.g., fade out, immediate stop). No mention of side effects or state changes.

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?

The description is extremely concise with two sentences that front-load the core purpose. Every word is purposeful with no redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, no output schema), the description covers the basic purpose but lacks details on return values, the meaning of 'graceful', and behavioral guarantees. It is adequate but not thorough.

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?

Schema coverage is 100% and the description adds no extra meaning beyond the parameter's enum values and textual description already present in the input schema. Baseline score of 3 is appropriate.

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 uses a specific verb-resource pair ('Stop a specific channel') and explicitly distinguishes itself from the sibling 'tidal_hush' by claiming to be 'more graceful for single channels'. This provides clear differentiation.

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 description implies that 'tidal_silence' is preferable for single channels while 'tidal_hush' is an alternative, likely for multiple channels. It gives clear context but does not explicitly state when not to use it.

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

tidal_soloB

Solo a specific channel, muting all others temporarily.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelYesThe channel to solo

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool mutes other channels and is temporary, which is helpful. However, it does not explain behavior if a channel is already soloed, whether unsoloing is required, or side effects on previous solo states, leaving some gaps.

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?

The description is a single sentence that is appropriately concise for a simple tool. Every word serves a purpose and the action is clearly stated upfront.

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 the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core purpose and effect. It is almost complete, but could mention whether soloing another channel automatically unsolos the previous one, or clarify the temporary nature more precisely.

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

Parameters2/5

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

Schema coverage is 100% with a list of enum values. The description merely repeats 'The channel to solo,' adding no semantic meaning beyond what the schema already provides. It does not explain the effect or format of the parameter.

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 clearly states 'Solo a specific channel, muting all others temporarily,' which defines the action and resource. It distinguishes from siblings like tidal_unsolo (unsolo) and tidal_hush/tidal_silence (likely muting only, not soloing), but could be slightly more explicit about its unique role.

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 description provides no explicit guidance on when to use this tool versus alternatives like tidal_hush or tidal_unsolo. The word 'temporarily' implies reversibility but offers no context about typical use cases or preconditions.

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

tidal_unsoloA

Restore all channels after soloing.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, and the description only states the action without disclosing behavioral traits like side effects, prerequisites, or edge cases (e.g., behavior when no channels are soloed).

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?

The description is a single, front-loaded sentence with no unnecessary words, optimally concise for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While adequate for a simple tool, the description lacks details on error conditions, prerequisites, or explicit relation to siblings like tidal_solo, leaving some gaps.

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?

With no parameters, schema coverage is 100%. The description adds meaning by clarifying the tool's purpose, meeting the baseline for zero-parameter tools.

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 clearly states the verb 'Restore' and the resource 'all channels' with context 'after soloing', which distinguishes it from sibling tools like tidal_solo.

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 implied by 'after soloing', but there is no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives among siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv1.0.0
    • First observedtidal_eval
    • First observedtidal_get_history
    • First observedtidal_get_state
    • First observedtidal_hush
    • First observedtidal_silence
    • First observedtidal_solo
    • First observedtidal_unsolo
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: evaluating patterns, retrieving history, checking state, stopping all, stopping a specific channel, soloing, and unsoloing. No two tools could be confused.

Naming Consistency5/5

All tools follow a consistent pattern: the 'tidal_' prefix followed by a verb (eval, hush, silence, solo, unsolo) or verb_noun (get_history, get_state). The naming is uniform and predictable.

Tool Count5/5

With 7 tools, the count is well-scoped for the domain. Each tool serves a clear purpose in the workflow of evaluating and controlling TidalCycles patterns, without being excessive or lacking.

Completeness4/5

The tool set covers the main operations: evaluating patterns, stopping playback, managing solo, and inspecting state/history. A minor gap is the lack of a tool to list available channels, but this is not critical and the set is otherwise complete.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Benedict/tidal-cycles-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server