LacyLights MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHROMA_HOST | No | ChromaDB host for enhanced RAG functionality | localhost |
| CHROMA_PORT | No | ChromaDB port | 8000 |
| OPENAI_API_KEY | Yes | OpenAI API key for AI-powered lighting generation | |
| LACYLIGHTS_GRAPHQL_ENDPOINT | No | GraphQL endpoint for your lacylights-node backend | http://localhost:4000/graphql |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsC | List all available lighting projects |
| create_projectC | Create a new lighting project |
| get_project_detailsC | Get detailed information about a specific project |
| delete_projectC | Delete a project and all its data |
| get_fixture_inventoryB | Get available lighting fixtures and their capabilities for a project or globally |
| analyze_fixture_capabilitiesC | Analyze specific fixtures to understand their lighting capabilities |
| create_fixture_instanceC | Create a new fixture instance in a project with manufacturer/model details |
| get_channel_mapC | Get the DMX channel usage map for a project |
| suggest_channel_assignmentC | Suggest optimal channel assignments for multiple fixtures |
| update_fixture_instanceC | Update an existing fixture instance with new properties |
| generate_sceneC | Generate a lighting scene based on script context and design preferences |
| analyze_scriptC | Analyze a theatrical script to extract lighting-relevant information |
| optimize_sceneC | Optimize an existing scene for specific goals |
| update_sceneC | Update an existing scene with new values |
| create_cue_sequenceC | Create a sequence of lighting cues from existing scenes |
| generate_act_cuesC | Generate cue suggestions for an entire act based on script analysis |
| optimize_cue_timingC | Optimize the timing of cues in a cue list |
| analyze_cue_structureC | Analyze the structure and timing of a cue list |
| update_cue_listC | Update cue list name or description |
| add_cue_to_listB | Add a new cue to an existing cue list |
| remove_cue_from_listC | Remove a cue from a cue list |
| update_cueC | Update properties of an existing cue |
| reorder_cuesC | Reorder multiple cues by assigning new cue numbers |
| get_cue_list_detailsC | Query and analyze cues in a cue list with filtering, sorting, and lookup tables |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Most tools have clearly distinct purposes (e.g., list_projects vs. create_project vs. delete_project), but a few pairs like optimize_scene/update_scene and generate_act_cues/create_cue_sequence could cause confusion if descriptions are not explicit. Overall, the boundaries are mostly clear.
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_projects, create_fixture_instance, optimize_cue_timing). No mixed conventions or vague verbs are present.
With 24 tools, the set feels heavy for a single server, but it covers multiple subdomains (projects, fixtures, scenes, cues, script analysis) where each tool has a specific role. It is within the 16-25 heavy range, so not ideal but not extreme.
Core CRUD and analysis operations are well-covered for projects, fixtures, scenes, and cues. Minor gaps exist such as missing delete operations for fixtures and scenes, and no update_project, but these are not critical to the main workflows.