studio5000-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pingA | Health check — verify the server is running. |
| load_projectC | Parse an L5X file and return a project summary. Args: l5x_path: Path to a .l5x file exported from Studio 5000. |
| get_tagsA | List tags from an L5X project, optionally filtered by scope and data type. Args: l5x_path: Path to a .l5x file. scope: "controller" for controller-scoped, a program name for program-scoped, or empty for all. data_type: Filter by data type (e.g. "BOOL", "DINT", "Motor_UDT"). |
| get_tagB | Get details for a specific tag by name. Args: l5x_path: Path to a .l5x file. tag_name: Tag name to look up (searches all scopes). |
| get_udtsA | List all User Defined Type names in an L5X project. Args: l5x_path: Path to a .l5x file. |
| get_udtC | Get UDT definition(s) with member details. Args: l5x_path: Path to a .l5x file. udt_name: UDT name. If empty, returns all UDTs. |
| get_routinesB | List routines in an L5X project with type and size info. Args: l5x_path: Path to a .l5x file. program: Filter by program name. Empty returns routines from all programs. |
| get_routineA | Get routine logic — NeutralText for ladder, raw code for Structured Text. Ladder rungs are returned as compact NeutralText with rung comments, not raw XML. A single rung like 'XIC Motor_Start XIO Motor_Fault OTE Motor_Run' replaces hundreds of lines of verbose XML. Args: l5x_path: Path to a .l5x file. program: Program name containing the routine. routine_name: Routine name. |
| get_aoisB | List all Add-On Instructions in an L5X project. Args: l5x_path: Path to a .l5x file. |
| get_aoiB | Get an Add-On Instruction definition with parameters and internal logic. Args: l5x_path: Path to a .l5x file. aoi_name: AOI name. |
| list_modulesB | List all I/O modules in an L5X project with catalog numbers and slot assignments. Args: l5x_path: Path to a .l5x file. |
| search_logicA | Search for a tag, AOI, or pattern across all routines in an L5X project. Returns every routine/rung/line that references the matching symbol(s). Supports regex patterns. Use this to answer "Where is this tag used?" or "Which routines reference this AOI?" Args: l5x_path: Path to a .l5x file. pattern: Tag name, AOI name, or regex pattern to search for. |
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 12 tools
Most tools have clearly distinct purposes: list/get pairs for tags, UDTs, AOIs, and routines are well-differentiated, plus search_logic and list_modules cover unique targets. Minor overlap exists because get_udt with an empty name returns all UDTs, duplicating get_udts (and similarly get_aoi vs get_aois), but the boundaries are still understandable.
Nearly all tools follow a predictable verb_noun pattern (get_tags, get_routine, get_aoi, search_logic, load_project). Slight inconsistency in using both get_* and list_* for listing operations (get_udts vs list_modules), and 'ping' is an outlier, but overall it is readable and consistent.
At 12 tools, the surface is well-scoped for a read-only L5X analysis server, with each tool earning its place. No redundant or trivial tools beyond the standard ping health check.
The read/query surface is thorough: project summary, tags, UDTs, AOIs, routines, I/O modules, and cross-routine search all have coverage. Minor gaps include no direct program-list tool (programs are only inferred via get_routines) and no export/reporting operation, but core analysis workflows are fully served.