LacyLights MCP Server
One-line summary: LacyLights MCP lets an AI assistant design, program, and manage theatrical lighting for the LacyLights system via natural language — handling projects, DMX fixtures, scenes/looks, and cue lists.
Projects: create, list, inspect, and delete (with confirmation) lighting projects.
Fixtures: browse inventories, analyze capabilities (color mixing, positioning, effects), add/update/delete fixture instances, view DMX channel maps, and get optimal channel-assignment suggestions.
AI generation: create lighting scenes/looks from descriptions, script context, mood, color palettes, intensity, and focus areas (requires
OPENAI_API_KEY).Script analysis: extract lighting cues and scene suggestions from theatrical scripts.
Scene/look editing: update scenes, set per-fixture DMX channel values (0–255), and optimize for energy efficiency, color accuracy, dramatic impact, or technical simplicity.
Cue sequences: build cue sequences from existing scenes, auto-generate full act cue lists from script text, optimize cue timing (smooth, dramatic, precise, energy-conscious), and analyze cue structure with recommendations.
Cue list management: update metadata, add/remove/edit cues (numbers, names, notes, scene links, fade in/out, follow times), reorder cues, filter/sort/query cue details, and delete lists.
Requirements: a running
lacylights-goGraphQL backend; optional ChromaDB for enhanced RAG pattern matching.
Supports running ChromaDB via Docker for persistent vector storage and advanced RAG capabilities when analyzing theatrical scripts
Connects to a GraphQL endpoint to access the LacyLights backend for fixture and scene management
Uses OpenAI's API for AI-powered lighting generation, script analysis, and intelligent scene creation based on artistic intent and lighting design principles
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@LacyLights MCP Server generate a dramatic sunset lighting scene for act 2"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
LacyLights MCP Server
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 countscreate_project- Create a new lighting project for a productionget_project_details- Get comprehensive details about a specific projectdelete_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 includesource: BUILTIN, OFL, GDTF, EOS, USER or SYNTHESIZED, when the backend reports it)import_gdtf_fixtures- Import GDTF fixture types from.gdtffiles,.ziparchives of them, or folders on the MCP host (see below)analyze_fixture_capabilities- Deep analysis of fixture capabilities (color mixing, positioning, effects). Capability flags includehasColorTemperature(COLOR_TEMPERATURE channel),hasHueSaturation(both HUE and SATURATION, reported as "Hue/Saturation (HSI)" mixing) andhasSpeed(SPEED channel; positioning analysis reports it asspeedControl)create_fixture_instance- Add a new fixture to a project with manufacturer/model detailsget_channel_map- View DMX channel usage map for a projectsuggest_channel_assignment- Get optimal channel assignments for multiple fixturesupdate_fixture_instance- Modify existing fixture propertiesdelete_fixture_instance- Remove a fixture from a project (requires confirmation)
Look Creation & Management
generate_look- AI-powered look generation based on descriptions and contextanalyze_script- Extract lighting cues and suggestions from theatrical scriptsoptimize_look- Optimize looks for various goals (energy, impact, simplicity)update_look- Update look properties and fixture valuesactivate_look- Activate a look by name or IDfade_to_black- Fade all lights to black with customizable timingget_current_active_look- Get information about the currently active look
Advanced Look Operations
add_fixtures_to_look- Add fixtures to existing looksremove_fixtures_from_look- Remove specific fixtures from looksget_look_fixture_values- Read current fixture values in a lookensure_fixtures_in_look- Ensure fixtures exist with specific valuesupdate_look_partial- Partial look updates with fixture mergingbulk_update_looks_partial- Batch partial updates across multiple looks with fixture merging
Cue Sequence Management
create_cue_sequence- Build cue sequences from existing looksgenerate_act_cues- Generate complete cue lists for theatrical actsoptimize_cue_timing- Optimize cue timing for various strategiesanalyze_cue_structure- Analyze cue lists with recommendations
Cue List Operations
update_cue_list- Update cue list metadataadd_cue_to_list- Add new cues to existing listsremove_cue_from_list- Remove cues from listsupdate_cue- Modify individual cue propertiesbulk_update_cues- Update multiple cues simultaneouslyreorder_cues- Reorder cues with new numberingget_cue_list_details- Query cues with filtering and sortingdelete_cue_list- Delete entire cue lists (requires confirmation)
Cue Playback Control
start_cue_list- Begin playing a cue list from any pointnext_cue- Advance to the next cueprevious_cue- Go back to the previous cuego_to_cue- Jump to a specific cue by number or namestop_cue_list- Stop the currently playing cue listget_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 countsget_look_board- Get a specific look board with all buttons and layoutcreate_look_board- Create a new look board with custom canvas and grid settingsupdate_look_board- Update look board metadata and settingsdelete_look_board- Delete a look board and all its buttons (requires confirmation)bulk_create_look_boards- Create multiple look boards in a single operationbulk_update_look_boards- Update multiple look boards in a single operationbulk_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 positionupdate_look_board_button- Update button properties (position, size, color, label)remove_look_from_board- Remove a button from a look boardupdate_look_board_button_positions- Batch update button positions (drag-and-drop)bulk_create_look_board_buttons- Create multiple buttons in a single operationbulk_update_look_board_buttons- Update multiple buttons in a single operationbulk_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.zipof.gdtffiles (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'sdescription.xmlis sent to the backend'simportGdtfFixturesmutation, in batches of up to 25 files.onExistingisUPDATE(default) orSKIPfor 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
Install dependencies:
npm installSet up environment variables:
cp .env.example .env
# Edit .env with your configurationBuild the project:
npm run buildConfiguration
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-exportsin 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 startYou should see:
RAG service initialized with in-memory patterns
LacyLights MCP Server running on stdioIntegration 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.jsin your configurationIf the above doesn't work, find your Node.js path with:
which nodeThe wrapper script ensures proper CommonJS module loading
Releases & Versioning
Release Channels
LacyLights MCP supports two release channels:
Stable Releases (e.g.,
1.4.0,1.5.0)Production-ready versions
Fully tested and validated
Listed as "Latest" on GitHub
Updates
latest.jsonfor automatic discovery
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
Install Latest Stable (Recommended)
# 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 startInstall 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 startInstall 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 startRelease Distribution
All releases are distributed through multiple channels:
GitHub Releases: https://github.com/bbernstein/lacylights-mcp/releases
Source code
Pre-built archives
Release notes
S3 Distribution: https://dist.lacylights.com/releases/mcp/
Direct archive downloads
SHA256 checksums
latest.jsonmetadata
DynamoDB Registry:
Version tracking
Release metadata
Prerelease flags
Beta Testing Program
Want to help test new features? Install beta releases:
Check for betas: Visit GitHub Releases
Look for releases marked "Pre-release"
Version format:
X.Y.Zb[N]
Install beta:
# See "Install Beta for Testing" aboveReport 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 sceneStep 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 clashesStep 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 soliloquiesStep 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 shiftStep 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 appearancesStep 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 progressionStep 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 fadeStep 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 changesAdvanced 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 projectCollaborative 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 satisfiedAI-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
Module import errors
Ensure Node.js version is 18+ as specified in package.json
Use the
run-mcp.jswrapper script, notdist/index.jsdirectly
GraphQL connection errors
Verify your
lacylights-gobackend is running on port 4000Check the
LACYLIGHTS_GRAPHQL_ENDPOINTenvironment variable
OpenAI API errors (e.g. "This tool requires OpenAI, but OPENAI_API_KEY is not set")
Set
OPENAI_API_KEYin theenvblock 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.envfile by itselfVerify the API key has access to GPT-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
"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:
Option 1: Docker (Recommended)
# Start ChromaDB with Docker
docker-compose up -d chromadb
# Verify it's running
curl http://localhost:8000/api/v2/heartbeatOption 2: Local Installation
# Install ChromaDB
pip install chromadb
# Start the server
chroma run --host localhost --port 8000Then update your .env file:
# Uncomment these lines in .env
CHROMA_HOST=localhost
CHROMA_PORT=8000Integration 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 pointAdding New Tools
Create tool implementation in appropriate file under
src/tools/Add tool definition to
src/index.tsin theListToolsRequestSchemahandlerAdd tool handler in the
CallToolRequestSchemahandlerUpdate this README with tool documentation
Testing
npm testMCP Directory
License
MIT
Available Tools
102 toolsactivate_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:
list_cue_lists(projectId) - Find available cue lists
get_cue_list_details(cueListId, page=1) - Get first page of cues
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:
list_fixtures(projectId, page=1) - Get first page
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
Scored across 102 tools
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.
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.
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.
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
Related MCP Connectors
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Screenplay and storyboard in your AI assistant: import scripts, edit scenes, build shots.
AI story development, screenplay editing, review, media, and export tools for BeatBandit projects.
Read and build visual moodboards, shot lists and lookbooks from an AI assistant.
Related MCP Servers
- AlicenseBqualityDmaintenanceAn 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.10019Apache 2.0
- AlicenseNot gradedqualityBmaintenanceTransforms 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.4AGPL 3.0
- AlicenseBqualityBmaintenanceAnalyzes music and generates xLights light show sequences, compatible with any MCP-compatible AI tool.22026MIT
- AlicenseDqualityDmaintenanceEnables 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.1005Apache 2.0