Skip to main content
Glama
LacyLights MCP Server

LacyLights MCP Server

by bbernstein

LacyLights MCP Server

GitHub Release GitHub Pre-release License: MIT

An MCP (Model Context Protocol) server that provides AI-powered theatrical lighting design capabilities for the LacyLights system. This server enables AI assistants to create, manage, and control professional theatrical lighting designs through natural language interactions.

What is LacyLights MCP?

LacyLights MCP is an intelligent lighting control interface that bridges the gap between creative vision and technical execution. It allows lighting designers, directors, and technicians to:

  • Design lighting looks using natural language descriptions

  • Analyze theatrical scripts to automatically generate lighting cues

  • Manage DMX fixtures from various manufacturers

  • Create and run cue sequences for theatrical performances

  • Optimize lighting designs for dramatic impact or energy efficiency

The system uses AI to understand artistic intent and translate it into precise DMX values for real-world lighting fixtures.

Related MCP server: Eos MCP

Complete Function Reference

Project Management

  • list_projects - List all available lighting projects with optional fixture/look counts

  • create_project - Create a new lighting project for a production

  • get_project_details - Get comprehensive details about a specific project

  • delete_project - Delete a project and all associated data (requires confirmation)

  • qlc_import_guidance - Get information about importing QLC+ (.qxw) files

Fixture Management

  • get_fixture_inventory - Query available fixtures and their capabilities (definitions include source: BUILTIN, OFL, GDTF, EOS, USER or SYNTHESIZED, when the backend reports it)

  • import_gdtf_fixtures - Import GDTF fixture types from .gdtf files, .zip archives of them, or folders on the MCP host (see below)

  • analyze_fixture_capabilities - Deep analysis of fixture capabilities (color mixing, positioning, effects). Capability flags include hasColorTemperature (COLOR_TEMPERATURE channel), hasHueSaturation (both HUE and SATURATION, reported as "Hue/Saturation (HSI)" mixing) and hasSpeed (SPEED channel; positioning analysis reports it as speedControl)

  • create_fixture_instance - Add a new fixture to a project with manufacturer/model details

  • get_channel_map - View DMX channel usage map for a project

  • suggest_channel_assignment - Get optimal channel assignments for multiple fixtures

  • update_fixture_instance - Modify existing fixture properties

  • delete_fixture_instance - Remove a fixture from a project (requires confirmation)

Look Creation & Management

  • generate_look - AI-powered look generation based on descriptions and context

  • analyze_script - Extract lighting cues and suggestions from theatrical scripts

  • optimize_look - Optimize looks for various goals (energy, impact, simplicity)

  • update_look - Update look properties and fixture values

  • activate_look - Activate a look by name or ID

  • fade_to_black - Fade all lights to black with customizable timing

  • get_current_active_look - Get information about the currently active look

Advanced Look Operations

  • add_fixtures_to_look - Add fixtures to existing looks

  • remove_fixtures_from_look - Remove specific fixtures from looks

  • get_look_fixture_values - Read current fixture values in a look

  • ensure_fixtures_in_look - Ensure fixtures exist with specific values

  • update_look_partial - Partial look updates with fixture merging

  • bulk_update_looks_partial - Batch partial updates across multiple looks with fixture merging

Cue Sequence Management

  • create_cue_sequence - Build cue sequences from existing looks

  • generate_act_cues - Generate complete cue lists for theatrical acts

  • optimize_cue_timing - Optimize cue timing for various strategies

  • analyze_cue_structure - Analyze cue lists with recommendations

Cue List Operations

  • update_cue_list - Update cue list metadata

  • add_cue_to_list - Add new cues to existing lists

  • remove_cue_from_list - Remove cues from lists

  • update_cue - Modify individual cue properties

  • bulk_update_cues - Update multiple cues simultaneously

  • reorder_cues - Reorder cues with new numbering

  • get_cue_list_details - Query cues with filtering and sorting

  • delete_cue_list - Delete entire cue lists (requires confirmation)

Cue Playback Control

  • start_cue_list - Begin playing a cue list from any point

  • next_cue - Advance to the next cue

  • previous_cue - Go back to the previous cue

  • go_to_cue - Jump to a specific cue by number or name

  • stop_cue_list - Stop the currently playing cue list

  • get_cue_list_status - Get playback status and navigation options

Look Board Management

Look Boards provide a visual layout system for organizing and triggering looks with customizable button positions on a 2D canvas (default 2000x2000 pixels).

Look Board CRUD

  • list_look_boards - List all look boards in a project with button counts

  • get_look_board - Get a specific look board with all buttons and layout

  • create_look_board - Create a new look board with custom canvas and grid settings

  • update_look_board - Update look board metadata and settings

  • delete_look_board - Delete a look board and all its buttons (requires confirmation)

  • bulk_create_look_boards - Create multiple look boards in a single operation

  • bulk_update_look_boards - Update multiple look boards in a single operation

  • bulk_delete_look_boards - Delete multiple look boards in a single operation

Look Board Button Management

  • add_look_to_board - Add a look as a button at a specific canvas position

  • update_look_board_button - Update button properties (position, size, color, label)

  • remove_look_from_board - Remove a button from a look board

  • update_look_board_button_positions - Batch update button positions (drag-and-drop)

  • bulk_create_look_board_buttons - Create multiple buttons in a single operation

  • bulk_update_look_board_buttons - Update multiple buttons in a single operation

  • bulk_delete_look_board_buttons - Delete multiple buttons in a single operation

Look Board Playback

  • activate_look_from_board - Activate a look from a board (uses board's default fade time)

  • create_look_board_with_buttons - Create a complete look board with buttons in one command

GDTF Fixture Import

  • import_gdtf_fixtures({ paths, onExisting? }) - Reads each path on the computer running the MCP server: a .gdtf, a .zip of .gdtf files (nested zips up to 2 levels), or a folder searched recursively (hidden folders and non-GDTF files ignored, symlinks leading out of the folder not followed). Only each fixture's description.xml is sent to the backend's importGdtfFixtures mutation, in batches of up to 25 files. onExisting is UPDATE (default) or SKIP for fixture types imported before. Returns created/updated/unchanged/skipped/failed counts and a per-file list (capped at 100, failures first).

Limits match the backend: at most 2000 entries per archive, description.xml at most 32 MB, __MACOSX/ and ._* entries skipped. Unreadable files are reported as FAILED and never stop the others. Only import files you supply; the tool never downloads from GDTF Share.

Data Export (CSV / Excel)

Requires lacylights-go v0.4.0 or newer; older backends get an "update LacyLights" message.

  • list_data_export_tables - List exportable tables with their columns and scope (which IDs each export needs)

  • export_data_table - Export one table as CSV (returned inline, truncated with a note when large) or XLSX (written to a file; the path is returned)

  • export_data_workbook - Export several project tables as one multi-sheet XLSX workbook written to a file

Files are written to the tool's outputDirectory argument, else LACYLIGHTS_EXPORT_DIR, else a private (0700) lacylights-exports folder in the system temp directory. Files are created with mode 0600 and never overwrite an existing file (a numeric suffix is added). Note that outputDirectory is chosen by the AI assistant and can be any directory the MCP server process can write to. Set LACYLIGHTS_EXPORT_DIR to give exports a predictable home, and keep the assistant on that default.

Installation

  1. Install dependencies:

npm install
  1. Set up environment variables:

cp .env.example .env
# Edit .env with your configuration
  1. Build the project:

npm run build

Configuration

Environment Variables

  • LACYLIGHTS_GRAPHQL_ENDPOINT - GraphQL endpoint for your lacylights-go backend (default: http://localhost:4000/graphql)

  • OPENAI_API_KEY - OpenAI API key, needed only for the AI-powered generation tools (e.g. generate_look, analyze_script, generate_act_cues). The server starts without it and every other tool works; the AI tools then return an error asking you to set it.

Optional Environment Variables

  • CHROMA_HOST - ChromaDB host for enhanced RAG functionality (default: localhost)

  • CHROMA_PORT - ChromaDB port (default: 8000)

  • LACYLIGHTS_EXPORT_DIR - Directory for CSV/XLSX data export files (default: lacylights-exports in the system temp directory)

Running the Server

Make sure your lacylights-go backend is running first, then:

# Start in development mode (with auto-reload)
npm run dev

# Or build and run in production mode
npm run build
npm start

You should see:

RAG service initialized with in-memory patterns
LacyLights MCP Server running on stdio

Integration with Claude

Add this server to your Claude configuration:

{
  "mcpServers": {
    "lacylights": {
      "command": "/usr/local/bin/node",
      "args": ["/path/to/lacylights-mcp/run-mcp.js"],
      "env": {
        "OPENAI_API_KEY": "your_openai_api_key_here",
        "LACYLIGHTS_GRAPHQL_ENDPOINT": "http://localhost:4000/graphql"
      }
    }
  }
}

Important:

  • Use the absolute path to run-mcp.js in your configuration

  • If the above doesn't work, find your Node.js path with: which node

  • The wrapper script ensures proper CommonJS module loading

Releases & Versioning

Release Channels

LacyLights MCP supports two release channels:

  1. Stable Releases (e.g., 1.4.0, 1.5.0)

    • Production-ready versions

    • Fully tested and validated

    • Listed as "Latest" on GitHub

    • Updates latest.json for automatic discovery

  2. Beta Releases (e.g., 1.4.1b1, 1.5.0b2)

    • Pre-release versions for testing

    • New features and experimental changes

    • Marked as "Pre-release" on GitHub

    • Does not affect stable latest.json

Version Format

  • Stable: X.Y.Z (semantic versioning)

    • X = Major version (breaking changes)

    • Y = Minor version (new features)

    • Z = Patch version (bug fixes)

  • Beta: X.Y.Zb[N] (beta with iteration)

    • b = Beta identifier

    • [N] = Beta iteration number (1, 2, 3, ...)

Installing Specific Versions

# Download latest stable release
curl -s https://dist.lacylights.com/releases/mcp/latest.json | jq -r '.url' | xargs curl -LO

# Extract archive
tar -xzf lacylights-mcp-*.tar.gz
cd lacylights-mcp

# Install and run
npm ci --omit=dev
npm start

Install Specific Version

# Download specific version (replace X.Y.Z with actual version)
VERSION="1.4.0"  # or "1.4.1b1" for beta
curl -LO https://dist.lacylights.com/releases/mcp/lacylights-mcp-${VERSION}.tar.gz

# Verify SHA256 checksum (optional but recommended)
curl -s https://dist.lacylights.com/releases/mcp/latest.json | jq -r '.sha256'
sha256sum lacylights-mcp-${VERSION}.tar.gz

# Extract and run
tar -xzf lacylights-mcp-${VERSION}.tar.gz
cd lacylights-mcp
npm ci --omit=dev
npm start

Install Beta for Testing

# Download latest beta (check GitHub releases for version)
VERSION="1.5.0b2"
curl -LO https://dist.lacylights.com/releases/mcp/lacylights-mcp-${VERSION}.tar.gz

# Extract and test
tar -xzf lacylights-mcp-${VERSION}.tar.gz
cd lacylights-mcp
npm ci --omit=dev
npm start

Release Distribution

All releases are distributed through multiple channels:

  1. GitHub Releases: https://github.com/bbernstein/lacylights-mcp/releases

    • Source code

    • Pre-built archives

    • Release notes

  2. S3 Distribution: https://dist.lacylights.com/releases/mcp/

    • Direct archive downloads

    • SHA256 checksums

    • latest.json metadata

  3. DynamoDB Registry:

    • Version tracking

    • Release metadata

    • Prerelease flags

Beta Testing Program

Want to help test new features? Install beta releases:

  1. Check for betas: Visit GitHub Releases

    • Look for releases marked "Pre-release"

    • Version format: X.Y.Zb[N]

  2. Install beta:

    # See "Install Beta for Testing" above
  3. Report issues:

    • Open issues on GitHub

    • Include version number

    • Provide reproduction steps

Release Process

For maintainers: See RELEASE_PROCESS.md for complete release documentation including:

  • Beta release workflows

  • Stable release procedures

  • Version management

  • Distribution verification

  • Troubleshooting and rollback

Complete Example: Lighting Design for Macbeth

Here's a comprehensive example showing how a lighting designer would use LacyLights MCP to create a complete lighting design for Shakespeare's Macbeth:

Step 1: Create the Project

Use create_project to create a new project called "Macbeth - Main Stage 2024"
with description "Shakespeare's Macbeth, directed by Jane Smith, March 2024 production"

Step 2: Set Up Fixtures

Use create_fixture_instance to add these fixtures to the project:
- 12x Chauvet SlimPAR Pro RGBA fixtures for front wash (channels 1-48)
- 8x Martin MAC Quantum Profile moving heads for specials (channels 100-163)
- 6x ETC Source Four LED Series 2 for side lighting (channels 200-241)
- 4x Chauvet Strike 4 strobes for storm effects (channels 300-315)
- 2x Rosco Vapour Plus hazers for atmosphere (channels 400-403)

Step 3: Analyze the Script

Use analyze_script with the full text of Act 1 to extract:
- All lighting cues mentioned in stage directions
- Scene transitions that need lighting changes
- Mood and atmosphere requirements for each scene

Step 4: Generate Key Looks

Use generate_look to create these essential looks:

1. "Opening - Thunder and Lightning"
   - Script context: "Thunder and lightning. Enter three witches."
   - Mood: ominous, supernatural
   - Color palette: ["deep purple", "electric blue", "white strobe"]
   - Intensity: dramatic

2. "Duncan's Arrival at Inverness"
   - Script context: "Hautboys and torches. Enter Duncan, Malcolm, Donalbain, Banquo"
   - Mood: regal, warm
   - Color palette: ["warm amber", "gold", "soft orange"]
   - Intensity: moderate

3. "Lady Macbeth Reads the Letter"
   - Script context: "Enter Lady Macbeth, reading a letter"
   - Mood: intimate, plotting
   - Color palette: ["cool blue", "pale amber", "shadow"]
   - Focus areas: ["center stage", "downstage center"]

4. "The Dagger Soliloquy"
   - Script context: "Is this a dagger which I see before me"
   - Mood: hallucinatory, tense
   - Color palette: ["blood red", "deep shadow", "cold steel blue"]
   - Intensity: subtle
   - Focus areas: ["center stage spot"]

5. "Murder of Duncan"
   - Script context: "Macbeth exits to kill Duncan, bell rings"
   - Mood: dark, suspenseful
   - Color palette: ["deep red", "black", "moonlight blue"]
   - Intensity: dramatic

6. "Banquo's Ghost Appears"
   - Script context: "The Ghost of Banquo enters, and sits in Macbeth's place"
   - Mood: supernatural, terrifying
   - Color palette: ["ghostly green", "cold white", "shadow"]
   - Effects: use moving heads for ghost tracking

7. "Lady Macbeth's Sleepwalking"
   - Script context: "Enter Lady Macbeth with a taper"
   - Mood: haunted, guilty
   - Color palette: ["candlelight amber", "moonlight", "deep shadow"]
   - Focus areas: ["follow spot", "single candle effect"]

8. "Final Battle"
   - Script context: "Alarums. Enter Macbeth and Macduff fighting"
   - Mood: violent, chaotic
   - Color palette: ["fire red", "steel blue", "explosive white"]
   - Intensity: dramatic
   - Effects: strobe for sword clashes

Step 5: Create Cue Sequences

Use create_cue_sequence to build the Act 1 cue list:
- Name: "Act 1 - Complete"
- Include all Act 1 looks in order
- Set default fade times: 3 seconds in, 3 seconds out
- Add follow cues for quick transitions during soliloquies

Step 6: Generate Act Cues with Script Analysis

Use generate_act_cues with the complete text of Act 2:
- This will analyze the script and create a complete cue list
- Automatically times transitions based on dramatic pacing
- Suggests lighting changes for every entrance, exit, and mood shift

Step 7: Optimize for Performance

Use optimize_cue_timing on the Act 1 cue list:
- Strategy: "dramatic_timing"
- This will adjust fade times for maximum dramatic impact
- Smooth transitions for scene changes
- Sharp cuts for supernatural appearances

Step 8: Create Special Effect Sequences

Use create_cue_sequence for the storm effect:
1. Lightning Strike 1 (strobes at full, 0.1s)
2. Thunder Roll (deep blue wash, 2s fade)
3. Lightning Strike 2 (strobes at 75%, 0.15s)
4. Return to storm base (purple/blue, 3s fade)
- Set follow times for automatic progression

Step 9: Run the Show

During performance, the stage manager can use:

start_cue_list "Act 1 - Complete"
next_cue  # Advance through each cue
go_to_cue 15.5  # Jump to specific cue for pickups
fade_to_black 5  # Emergency blackout with 5-second fade

Step 10: Make Live Adjustments

Use update_look to adjust the "Banquo's Ghost" look:
- Increase moving head intensity for better visibility
- Adjust color temperature based on costume reflectance
- Fine-tune positioning for actor's blocking changes

Advanced Usage Examples

Script-Driven Design Workflow

1. Analyze the entire script:
   analyze_script with full play text

2. Review extracted cues and looks

3. Generate all suggested looks in batch:
   generate_look for each suggestion

4. Create master cue list:
   create_cue_sequence with all looks

5. Optimize for your venue:
   optimize_look for each look with "technical_simplicity"

Multi-Universe Setup

For large productions spanning multiple DMX universes:

1. Plan channel allocation:
   suggest_channel_assignment for all fixtures

2. Create fixtures with specific universe assignments:
   create_fixture_instance with universe: 1 for front lights
   create_fixture_instance with universe: 2 for moving heads
   create_fixture_instance with universe: 3 for effects

3. View the complete channel map:
   get_channel_map for the project

Collaborative Design Process

Director requests:
"I want the witches' scenes to feel otherworldly but not cartoonish"

Use generate_look:
- Description: "Witches on the heath"
- Mood: "otherworldly, mysterious"
- Color palette: ["deep violet", "fog grey", "pale green"]
- Intensity: "subtle"

Then iterate with optimize_look using "dramatic_impact" until satisfied

AI-Powered Features

Intelligent Script Analysis

  • Extracts explicit lighting cues from stage directions

  • Identifies implicit lighting needs from dialogue and action

  • Suggests atmospheric lighting based on dramatic context

  • Recognizes standard theatrical conventions (sunrise, sunset, storms)

Context-Aware Look Generation

  • Understands theatrical lighting principles

  • Applies color theory for emotional impact

  • Considers fixture capabilities and positions

  • Generates DMX values that respect real-world constraints

Adaptive Optimization

  • Energy Efficiency: Reduces power consumption while maintaining artistic intent

  • Dramatic Impact: Enhances contrast and focus for maximum effect

  • Technical Simplicity: Simplifies programming for easier operation

  • Color Accuracy: Optimizes for true color rendering

Troubleshooting

Common Issues

  1. Module import errors

    • Ensure Node.js version is 18+ as specified in package.json

    • Use the run-mcp.js wrapper script, not dist/index.js directly

  2. GraphQL connection errors

    • Verify your lacylights-go backend is running on port 4000

    • Check the LACYLIGHTS_GRAPHQL_ENDPOINT environment variable

  3. OpenAI API errors (e.g. "This tool requires OpenAI, but OPENAI_API_KEY is not set")

    • Set OPENAI_API_KEY in the env block of your MCP client configuration (or export it in the shell that launches the server), then restart the server. The server does not load a .env file by itself

    • Verify the API key has access to GPT-4

  4. MCP connection errors in Claude

    • Use the full absolute path in your Claude configuration

    • Restart Claude after updating the MCP configuration

    • Check Claude's logs for detailed error messages

  5. "Unexpected token ?" error

    • Update your config to use the full path to Node.js 14+

    • On macOS with Homebrew: "command": "/opt/homebrew/bin/node"

    • On other systems, find your node path with: which node

ChromaDB Setup (Optional - For Enhanced RAG)

The MCP server works out of the box with in-memory pattern storage. For persistent vector storage and more sophisticated pattern matching:

# Start ChromaDB with Docker
docker-compose up -d chromadb

# Verify it's running
curl http://localhost:8000/api/v2/heartbeat

Option 2: Local Installation

# Install ChromaDB
pip install chromadb

# Start the server
chroma run --host localhost --port 8000

Then update your .env file:

# Uncomment these lines in .env
CHROMA_HOST=localhost
CHROMA_PORT=8000

Integration with LacyLights Ecosystem

This MCP server is part of the complete LacyLights system:

  • lacylights-go - Backend GraphQL API for fixture and look management

  • lacylights-fe - Web frontend for manual control and visualization

  • lacylights-mcp - AI interface for intelligent automation

The MCP server enhances the existing system with:

  • Natural language control

  • Intelligent look generation

  • Script analysis capabilities

  • Automated cue creation

  • Performance optimization

Development

Project Structure

src/
├── tools/           # MCP tool implementations
│   ├── fixture-tools.ts    # Fixture management operations
│   ├── look-tools.ts       # Look creation and control
│   ├── cue-tools.ts        # Cue list management
│   └── project-tools.ts    # Project operations
├── services/        # Core services
│   ├── graphql-client.ts   # GraphQL API client
│   ├── rag-service.ts      # RAG pattern matching
│   └── ai-lighting.ts      # AI look generation
├── types/          # TypeScript type definitions
│   └── lighting.ts         # Core lighting types
└── index.ts        # MCP server entry point

Adding New Tools

  1. Create tool implementation in appropriate file under src/tools/

  2. Add tool definition to src/index.ts in the ListToolsRequestSchema handler

  3. Add tool handler in the CallToolRequestSchema handler

  4. Update this README with tool documentation

Testing

npm test

MCP Directory

License

MIT

Available Tools

102 tools
activate_lookC

Activate a lighting look by name or ID

Inputs: lookId, lookName, projectId.

activate_look_from_boardA

Activate a look from a board (uses board's default fade time unless overridden).

Inputs: lookId (required), lookBoardId (required), fadeTimeOverride.

add_cue_to_listC

Add a new cue to an existing cue list

Inputs: name (required), lookId (required), cueListId (required), cueNumber (required), +6 more.

add_fixtures_to_lookC

Safely add fixtures to a look without affecting existing fixtures

Inputs: lookId (required), fixtureValues (required), overwriteExisting.

add_look_to_boardC

Add a look as a button to a look board at a specific position.

Inputs: lookId (required), layoutX (required), layoutY (required), lookBoardId (required), +4 more.

analyze_cue_structureC

Analyze the structure and timing of a cue list

Inputs: cueListId (required), projectId (required), includeRecommendations.

analyze_fixture_capabilitiesC

Analyze specific fixtures to understand their lighting capabilities

Inputs: fixtureId, fixtureIds, analysisType.

analyze_scriptC

Analyze a theatrical script to extract lighting-relevant information

Inputs: scriptText (required), suggestLooks, extractLightingCues.

bulk_create_cue_listsC

Create multiple cue lists in a single operation.

Inputs: cueLists (required).

bulk_create_cuesC

Create multiple cues in a single operation. All cues are created in one GraphQL call for efficiency.

Inputs: cues (required).

bulk_create_fixture_definitionsB

Create multiple fixture definitions in a single operation. Use this to efficiently add multiple fixture types (manufacturer/model combinations) to the system at once.

Inputs: definitions (required).

bulk_create_fixturesA

Create multiple fixture instances with best-effort approach. Each fixture is processed individually, allowing partial success if some fixtures fail. Returns detailed success/failure information for each fixture. Automatically assigns DMX channels if not specified. Validates channel availability before creation.

Inputs: fixtures (required).

bulk_create_look_board_buttonsC

Create multiple buttons in a single operation.

Inputs: buttons (required).

bulk_create_look_boardsC

Create multiple look boards in a single operation.

Inputs: lookBoards (required).

bulk_create_looksB

Create multiple looks in a single operation. Returns all created looks with their IDs.

Inputs: looks (required).

bulk_create_projectsC

Create multiple projects in a single operation.

Inputs: projects (required).

bulk_delete_cue_listsB

Delete multiple cue lists in a single operation. Returns count of successfully deleted cue lists and any failed IDs.

Inputs: cueListIds (required), confirmDelete (required).

bulk_delete_cuesA

Delete multiple cues in a single operation. Returns count of successfully deleted cues and any failed IDs.

Inputs: cueIds (required), confirmDelete (required).

bulk_delete_fixturesA

Delete multiple fixture instances in a single operation. Returns count of successfully deleted fixtures and any failed IDs.

Inputs: fixtureIds (required), confirmDelete (required).

bulk_delete_look_board_buttonsC

Delete multiple buttons in a single operation.

Inputs: buttonIds (required), confirmDelete (required).

bulk_delete_look_boardsC

Delete multiple look boards in a single operation.

Inputs: lookBoardIds (required), confirmDelete (required).

bulk_delete_looksA

Delete multiple looks in a single operation. Returns count of successfully deleted looks and any failed IDs.

Inputs: lookIds (required), confirmDelete (required).

bulk_delete_projectsB

Delete multiple projects in a single operation. Returns count of successfully deleted projects and any failed IDs.

Inputs: projectIds (required), confirmDelete (required).

bulk_update_cue_listsC

Update multiple cue lists in a single operation.

Inputs: cueLists (required).

bulk_update_cuesB

Update fade times and follow times for multiple cues in a single operation

Inputs: cueIds (required), skip, easingType, fadeInTime, +2 more.

bulk_update_fixturesA

Update multiple fixture instances in a single atomic operation. All updates succeed or fail together. Useful for batch renaming, repositioning, or re-tagging fixtures.

Inputs: fixtures (required).

bulk_update_look_board_buttonsC

Update multiple buttons in a single operation.

Inputs: buttons (required).

bulk_update_look_boardsC

Update multiple look boards in a single operation.

Inputs: lookBoards (required).

bulk_update_looksC

Update multiple looks in a single operation. Supports updating name, description, and fixture values.

Inputs: looks (required).

bulk_update_looks_partialA

Update multiple looks with partial fixture value merging support. Each look can independently specify name, description, fixtureValues, and mergeFixtures. Unlike bulk_update_looks, this preserves existing fixtures not mentioned in the update (when mergeFixtures=true). This is useful for batch operations like changing a channel value across many looks without affecting other fixtures.

Inputs: looks (required).

clear_operation_historyA

Clear all operation history for a project.

WARNING: This is a destructive operation that cannot be undone. All undo/redo history will be permanently deleted.

Parameters:

  • projectId: The project to clear history for

  • confirmClear: Must be true to confirm the deletion

Returns:

  • success: Whether the history was cleared

  • message: Confirmation message

Inputs: projectId (required), confirmClear (required).

copy_fixtures_to_looksB

Copy fixture channel values from a source look to multiple target looks. This is an atomic operation that supports undo/redo. Useful for propagating lighting changes across multiple looks efficiently.

Inputs: fixtureIds (required), sourceLookId (required), targetLookIds (required).

create_cue_sequenceC

Create a sequence of lighting cues from existing looks

Inputs: lookIds (required), projectId (required), sequenceName (required), scriptContext (required), +1 more.

create_fixture_instanceC

Create a new fixture instance in a project with manufacturer/model details

Inputs: name (required), model (required), projectId (required), manufacturer (required), +6 more.

create_look_boardC

Create a new look board for organizing looks with custom layout.

Inputs: name (required), projectId (required), gridSize, canvasWidth, +3 more.

create_look_board_with_buttonsC

Create a complete look board with buttons in a single operation. Allows defining an entire look board layout in one command.

Inputs: name (required), projectId (required), buttons, gridSize, +4 more.

create_projectC

Create a new lighting project

Inputs: name (required), groupId, description.

delete_cue_listB

Delete a cue list and all its cues

Inputs: cueListId (required), confirmDelete (required).

delete_fixture_instanceB

Delete a fixture instance from a project (will remove it from all looks)

Inputs: fixtureId (required), confirmDelete (required).

delete_look_boardB

Delete a look board and all its buttons.

Inputs: lookBoardId (required), confirmDelete (required).

delete_projectC

Delete a project and all its data

Inputs: projectId (required), confirmDelete (required).

ensure_fixtures_in_lookA

Ensure specific fixtures exist in a look with given values, adding only if missing

Inputs: lookId (required), fixtureValues (required).

export_data_tableA

Export one data table (fixtures, looks, cue lists, look details, ...) as CSV or Excel.

  • format "csv" (default): returns the CSV text inline so you can read it. Large exports are truncated (default 50000 characters), preferably at a line break, with truncated=true and a note. A cut is not guaranteed to fall between complete rows (a very long first line, or a quoted field containing line breaks, may be split); pass outputDirectory to also save the full file, or raise maxCharacters.

  • format "xlsx": writes the Excel file to disk and returns its path, row count and size (no file content in the response).

Files are written to outputDirectory, else the LACYLIGHTS_EXPORT_DIR environment variable, else a private lacylights-exports folder in the system temp directory. Existing files are never overwritten; a numeric suffix is added instead. Use list_data_export_tables to see the tables and which need scopeId.

Inputs: table (required), format, scopeId, projectId, +2 more.

export_data_workbookA

Export several project tables as one multi-sheet Excel (XLSX) workbook, one sheet per table.

Writes the file to disk and returns its path, total row count and size. Omit tables to export the backend's default set of project-level tables. FIXTURE_LIBRARY and scoped tables (LOOK_DETAILS, CUE_LIST_DETAILS, LOOK_BOARD_ENTRIES) cannot be included.

Inputs: projectId (required), tables, outputDirectory.

export_eos_asciiA

Export a LacyLights project as an ETC Eos ASCII (.asc) showfile.

Returns the file content as a string along with a suggested filename suffix and any export warnings. LacyLights-only concepts (Look Boards, per-channel fade behaviors, synthesized definitions) ride along as $$ LACYLIGHTS: comment lines at the end of file so a subsequent re-import preserves them. EOS itself ignores those comments.

Output is deterministic: the same project produces byte-identical output across runs.

Inputs: projectId (required).

fade_to_blackC

Fade all lights to black (turn off)

Inputs: fadeOutTime.

generate_act_cuesC

Generate cue suggestions for an entire act based on script analysis

Inputs: actNumber (required), projectId (required), scriptText (required), cueListName, +1 more.

generate_lookC

Generate a lighting look based on script context and design preferences

Inputs: projectId (required), lookDescription (required), activate, lookType, +3 more.

get_build_infoA

Get build information for the backend server.

Returns version, git commit hash, and build timestamp for the running lacylights-go server. This is useful for:

  • Verifying the server version after updates

  • Debugging version mismatches

  • Confirming deployment success

Returns:

  • version: Semantic version (e.g., "v0.8.10")

  • gitCommit: Full git commit hash

  • buildTime: UTC timestamp when the binary was built

Inputs: no named parameters.

get_channel_mapC

Get the DMX channel usage map for a project

Inputs: projectId (required), universe.

get_cueA

Get full details for a specific cue by ID.

Returns:

  • Cue metadata (name, number, fade times, follow time, notes)

  • Look information (id, name, description)

  • Cue list information (id, name)

Use this when you need to inspect a single cue in detail.

Use cases:

  • "Show me details for cue 5.5"

  • "What look does this cue use?"

  • "What are the fade times for this cue?"

Note: To look up a cue by number or name, use get_cue_list_details with filters and lookup tables instead.

Inputs: cueId (required).

get_cue_list_detailsA

Get cue list with its cues, optionally paginated.

Parameters:

  • cueListId: Cue list to retrieve

  • page: Page number (default: 1)

  • perPage: Items per page (default: 50, max: 100)

  • includeLookDetails: Include full look data for each cue (default: false)

  • sortBy: Sort cues by cueNumber, name, or lookName

  • filterBy: Optional filters (cueNumberRange, nameContains, etc.)

By default, each cue includes lookId and lookName but NOT full look fixture values. Set includeLookDetails=true only if you need full look data for every cue (this can be very large).

For large cue lists (50+ cues), use pagination to avoid context overflow.

Returns:

  • Cue list metadata

  • Paginated cues array

  • Pagination info (total, page, perPage, hasMore)

  • Statistics (averages, counts, ranges)

  • Lookup tables for quick reference

Example workflow:

  1. list_cue_lists(projectId) - Find available cue lists

  2. get_cue_list_details(cueListId, page=1) - Get first page of cues

  3. If pagination.hasMore, call with page=2, etc.

Inputs: cueListId (required), page, sortBy, perPage, +2 more.

get_cue_list_statusB

Get information about the currently playing cue list and navigation options

Inputs: no named parameters.

get_current_active_lookA

Get the currently active look if any

Inputs: no named parameters.

get_fade_update_rateA

Get the current fade engine update rate in Hz.

The fade update rate controls how frequently the fade engine updates DMX channel values during look transitions. Higher rates provide smoother fades but use more CPU.

Returns:

  • Current update rate in Hz (default: 60Hz)

  • Whether the value is using the default

Typical values:

  • 30Hz: Efficient, adequate for most theatrical lighting

  • 60Hz: Default, smooth fades for professional use

  • 120Hz: Very smooth, for critical applications

Inputs: no named parameters.

get_fixtureA

Get full details for a specific fixture.

Returns:

  • All metadata (id, name, manufacturer, model, type, mode)

  • DMX addressing (universe, startChannel, channelCount)

  • Full channel definitions with types and ranges

  • Tags

Use this tool when you need:

  • Complete channel information for a fixture

  • To understand fixture capabilities in detail

  • Channel types and DMX value ranges

Use list_fixtures instead if you only need basic fixture information.

Inputs: fixtureId (required).

get_fixture_inventoryB

Get available lighting fixtures and their capabilities for a project or globally

Inputs: projectId, fixtureType, includeDefinitions.

get_group_detailsB

Get full details of a group including its members, projects, and assigned devices. Requires the group ID.

Inputs: groupId (required).

get_lookA

Get full details for a specific look.

Parameters:

  • lookId: Look to retrieve

  • includeFixtureValues: Include all DMX channel values (default: true)

Set includeFixtureValues=false if you only need to know which fixtures are in the look, not their specific values. This is much faster for large looks.

Use get_look_fixtures instead if you only need fixture metadata.

Inputs: lookId (required), includeFixtureValues.

get_look_boardA

Get a specific look board with all its buttons and layout information.

Inputs: lookBoardId (required).

get_look_fixturesA

Get just the fixtures used in a look without their values.

Returns:

  • Fixture IDs, names, and types

This is the fastest way to understand look composition without loading full DMX channel data.

Use cases:

  • "Which fixtures does this look use?"

  • "What type of fixtures are in this look?"

  • Quick look composition analysis

Inputs: lookId (required).

get_look_fixture_valuesB

Get current fixture values for a look (read-only)

Inputs: lookId (required).

get_operation_historyA

Get the operation history for a project with pagination.

Returns a list of all recorded operations that can be navigated via undo/redo. Each operation includes:

  • id: Unique operation ID

  • description: Human-readable description

  • operationType: CREATE, UPDATE, DELETE, or BULK

  • entityType: Type of entity affected (Look, FixtureInstance, etc.)

  • sequence: Position in the history

  • createdAt: When the operation occurred

  • isCurrent: Whether this is the current state

Use this to display an operation history timeline and allow jumping to specific points.

Inputs: projectId (required), page, perPage.

get_projectA

Get high-level project information including metadata and counts.

Returns:

  • Project metadata (id, name, description, timestamps)

  • Resource counts (fixtureCount, lookCount, cueListCount)

Does NOT include:

  • Fixture details (use list_fixtures or get_fixture_inventory)

  • Look details (use list_looks)

  • Cue list details (use list_cue_lists or get_cue_list_details)

Use this tool first to understand project scope before drilling down into specific resources.

Inputs: projectId (required).

get_project_detailsA

Get detailed information about a specific project including all fixtures, looks, and cue lists. This returns a lot of data and should only be used when you need comprehensive project information.

Inputs: projectId (required).

get_undo_redo_statusA

Get the current undo/redo status for a project.

Returns information about available undo/redo operations:

  • canUndo: Whether undo is available

  • canRedo: Whether redo is available

  • currentSequence: Current position in the operation history

  • totalOperations: Total number of operations in history

  • undoDescription: Description of the operation that would be undone

  • redoDescription: Description of the operation that would be redone

Use this to determine if undo/redo buttons should be enabled and to show tooltips.

Inputs: projectId (required).

go_to_cueB

Jump to a specific cue by number or name in the currently playing cue list

Inputs: cueName, cueNumber, fadeInTime.

import_eos_asciiA

Import an ETC Eos ASCII (.asc) showfile into LacyLights.

Creates a new project (or appends into an existing one if targetProjectId is given) populated with the patch, cues, palettes, and groups from the Eos showfile. EOS-only concepts (effects, partitions, magic sheets, action triggers, curves, submasters) are skipped and surfaced as structured warnings. Palettes/presets are imported as standalone Looks in dedicated cue lists ("Color Palettes", "Beam Palettes", etc.).

Returns:

  • projectId: the created or updated project

  • counts of fixtures, looks, cue lists, cues, groups created

  • warnings: structured list with code/severity/message/context entries

  • synthesizedDefinitionIds: definitions auto-synthesized when no library match was found

Provide either newProjectName or targetProjectId, not both. If both are omitted, the project name comes from the showfile's $$Title.

Inputs: asciiContent (required), newProjectName, targetProjectId.

invite_to_groupA

Invite a user to join a group by their email address. Requires GROUP_ADMIN role in the target group. The invited user will receive a pending invitation they can accept or decline.

Inputs: email (required), groupId (required), role.

jump_to_operationA

Jump to a specific operation in the history.

This allows navigating directly to any point in the operation history, effectively performing multiple undos or redos to reach the target state.

Parameters:

  • projectId: The project containing the operation

  • operationId: The ID of the operation to jump to

Returns:

  • success: Whether the jump was successful

  • message: Description of what happened

  • operation: Details of the target operation

Use get_operation_history to get available operation IDs.

Inputs: projectId (required), operationId (required).

list_cue_listsA

List all cue lists in a project with lightweight summaries.

Returns:

  • Metadata (id, name, description)

  • Cue count

  • Total duration estimate

  • Loop setting

Does NOT include:

  • Individual cues (use get_cue_list_details)

  • Look details (use get_look)

This is the most efficient way to browse available cue lists. Projects typically have < 10 cue lists, so no pagination needed.

Use cases:

  • "What cue lists are available?"

  • "Show me all cue lists in this project"

  • Quick cue list overview

Inputs: projectId (required).

list_data_export_tablesA

List the data tables that can be exported as CSV or Excel (XLSX), with their column headers and scope.

Each table has a scope that says which IDs export_data_table needs:

  • none: global (FIXTURE_LIBRARY); projectId optional

  • project: projectId required (FIXTURE_TYPES, FIXTURES, LOOKS, EFFECTS, CUE_LISTS)

  • look: projectId + scopeId = look ID (LOOK_DETAILS)

  • cueList: projectId + scopeId = cue list ID (CUE_LIST_DETAILS)

  • lookBoard: projectId, optional scopeId = look board ID (LOOK_BOARD_ENTRIES)

Requires LacyLights backend v0.4.0 or newer.

Inputs: no named parameters.

list_fixturesA

List fixtures in a project with pagination and filtering.

Returns lightweight fixture information:

  • Basic metadata (id, name, manufacturer, model, type)

  • DMX addressing (universe, startChannel, channelCount)

  • Tags

Does NOT include:

  • Full channel definitions (use get_fixture for that)

  • Look usage (use get_fixture_usage)

Pagination:

  • Default: 50 items per page

  • Max: 100 items per page

  • Use pagination.hasMore to check if more results exist

Filtering:

  • type: Filter by fixture type (LED_PAR, MOVING_HEAD, etc.)

  • universe: Filter by DMX universe

  • tags: Filter by tags (array)

  • manufacturer: Filter by manufacturer name

  • model: Filter by model name

Example workflow:

  1. list_fixtures(projectId, page=1) - Get first page

  2. If pagination.hasMore, call with page=2, etc.

Inputs: projectId (required), page, filter, perPage.

list_groupsA

List groups accessible to this device/user. Shows group names, member counts, and device counts. Groups determine which projects you can access.

Inputs: no named parameters.

list_look_boardsB

List all look boards in a project.

Returns lightweight look board summaries with button counts.

Inputs: projectId (required).

list_looksA

List looks in a project with pagination and filtering.

Returns lightweight look summaries:

  • Metadata (id, name, description)

  • Fixture count

  • Timestamps

Does NOT include:

  • Fixture values (use get_look for that)

  • Usage information (use get_look_usage)

This is the most efficient way to browse available looks.

Filtering:

  • nameContains: Filter by look name (case-insensitive)

  • usesFixture: Filter to looks using specific fixture ID

Sorting:

  • name: Alphabetical by name

  • createdAt: Oldest first (default)

  • updatedAt: Recently modified first

Inputs: projectId (required), page, sortBy, perPage, +2 more.

list_my_invitationsA

List pending group invitations for the current user/device. Shows which groups you've been invited to, who invited you, and the offered role.

Inputs: no named parameters.

list_projectsA

List all projects with optional detail level.

Parameters:

  • includeDetails: When true, includes resource counts for each project. Default false.

Returns:

  • Basic info (id, name, description) always

  • Resource counts (fixtureCount, lookCount, cueListCount) when includeDetails=true

Use includeDetails=false for quick project listing. Use includeDetails=true when you need to understand project sizes.

Inputs: includeDetails.

next_cueB

Advance to the next cue in the currently playing cue list

Inputs: fadeInTime.

optimize_cue_timingC

Optimize the timing of cues in a cue list

Inputs: cueListId (required), projectId (required), optimizationStrategy.

optimize_lookC

Optimize an existing look for specific goals

Inputs: lookId (required), projectId (required), optimizationGoals.

previous_cueB

Go back to the previous cue in the currently playing cue list

Inputs: fadeInTime.

qlc_import_guidanceB

Get information about importing QLC+ (.qxw) files into LacyLights

Inputs: no named parameters.

redoA

Redo a previously undone operation in a project.

Re-applies an operation that was previously undone. Only available after an undo operation. If a new operation is performed after undo, the redo history is cleared.

Returns:

  • success: Whether the redo was successful

  • message: Description of what was redone

  • operation: Details of the redone operation

  • restoredEntityId: ID of the restored entity (if applicable)

Use get_undo_redo_status to check if redo is available.

Inputs: projectId (required).

remove_cue_from_listC

Remove a cue from a cue list

Inputs: cueId (required).

remove_fixtures_from_lookB

Safely remove specific fixtures from a look

Inputs: lookId (required), fixtureIds (required).

remove_look_from_boardC

Remove a button from a look board.

Inputs: buttonId (required).

reorder_cuesC

Reorder multiple cues by assigning new cue numbers

Inputs: cueListId (required), cueReordering (required).

set_fade_update_rateA

Set the fade engine update rate in Hz.

The fade update rate controls how frequently the fade engine updates DMX channel values during look transitions.

Valid range: 10-120 Hz

Guidelines:

  • 10-30Hz: Lower CPU usage, adequate for simple fades

  • 30-60Hz: Good balance of smoothness and efficiency

  • 60-120Hz: Maximum smoothness for professional applications

Note: Changes take effect immediately for new look transitions.

Inputs: rateHz (required).

start_cue_listC

Start playing a cue list from the beginning or a specific cue

Inputs: cueListId, projectId, cueListName, startFromCue.

stop_cue_listB

Stop the currently playing cue list

Inputs: no named parameters.

suggest_channel_assignmentC

Suggest optimal channel assignments for multiple fixtures

Inputs: projectId (required), fixtureSpecs (required), universe, startingChannel, +1 more.

toggle_cue_skipA

Toggle the skip status of a cue. Skipped cues remain visible but are bypassed during playback.

Inputs: cueId (required).

undoA

Undo the last operation in a project.

Reverts the most recent change made to the project. Operations that can be undone include:

  • Creating, updating, or deleting looks

  • Creating, updating, or deleting fixture instances

  • Creating, updating, or deleting cues

  • Creating, updating, or deleting cue lists

Returns:

  • success: Whether the undo was successful

  • message: Description of what was undone

  • operation: Details of the undone operation

  • restoredEntityId: ID of the restored entity (if applicable)

Use get_undo_redo_status to check if undo is available.

Inputs: projectId (required).

update_cueC

Update properties of an existing cue

Inputs: cueId (required), name, skip, notes, +5 more.

update_cue_listC

Update cue list name or description

Inputs: cueListId (required), loop, name, description.

update_fixture_instanceC

Update an existing fixture instance with new properties

Inputs: fixtureId (required), mode, name, tags, +5 more.

update_lookC

Update an existing look with new values

Inputs: lookId (required), name, description, fixtureValues.

update_look_boardC

Update an existing look board's metadata and settings.

Inputs: lookBoardId (required), name, gridSize, canvasWidth, +3 more.

update_look_board_buttonC

Update a look board button's properties (position, size, color, label).

Inputs: buttonId (required), color, label, width, +3 more.

update_look_board_button_positionsB

Update positions of multiple buttons in a single operation (useful for drag-and-drop).

Inputs: positions (required).

update_look_partialC

Safely update look metadata and optionally merge fixture values

Inputs: lookId (required), name, description, fixtureValues, +1 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    C2.9/5.0

    Scored across 102 tools

    Disambiguation3/5

    Many tools target distinct resources, but the set contains numerous near-duplicate pairs such as update_look vs update_look_partial, bulk_update_looks vs bulk_update_looks_partial, and get_look vs get_look_fixtures vs get_look_fixture_values. Long descriptions often help, but the sheer number of bulk_-prefixed variants and subtle semantic differences creates real misselection risk.

    Naming Consistency4/5

    Nearly all tool names use snake_case with a consistent verb_noun or verb_noun_prep_noun pattern, including the bulk_ prefix. A few names deviate from the pattern (undo, redo, next_cue, previous_cue, qlc_import_guidance), but the overall convention is predictable.

    Tool Count1/5

    102 tools is far beyond a reasonable scope for an MCP server and is bloated with redundant bulk operations and many near-duplicate single/bulk/partial variants. This extreme count creates severe cognitive load and makes tool selection unnecessarily difficult.

    Completeness3/5

    Core lighting entities (projects, fixtures, looks, cues, cue lists, look boards) have extensive CRUD, bulk, import/export, undo/redo, and playback coverage. However, there are notable gaps: group invitations cannot be accepted or declined, and descriptions reference get_fixture_usage and get_look_usage tools that are not present, leaving dead ends in access-control and usage analysis.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      D
      maintenance
      An MCP server that lets AI assistants control grandMA2 lighting consoles via Telnet, exposing 41 high-level tools for cue management, fixture control, preset management, executor control, macro editing, appearance assignment, bulk operations, console state queries, show file management, read-back verification, and music show workflows.
      100
      19
      Apache 2.0
    • A
      license
      Not graded
      quality
      B
      maintenance
      Transforms an ETC Eos lighting console into a service controllable by AI assistants and automation tools via MCP and OSC, enabling cue management, preset recall, and channel level control.
      4
      AGPL 3.0
    • A
      license
      D
      quality
      D
      maintenance
      Enables AI-driven control of MADRIX LED lighting software, providing over 100 tools for storage, layer, cue list, timeline, audio, output, and color management via the MADRIX Remote HTTP interface.
      100
      5
      Apache 2.0