pickering-lxi-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PICKERING_LXI_PORT | No | ClientBridge port | 1024 |
| PICKERING_LXI_ADDRESS | No | LXI unit IP, or 'PXI' for local cards. Unset means the in-process simulator. | |
| PICKERING_LXI_SIM_CARD | No | Ask the vendor driver for simulated cards (DriverModes.SIM_CARD) | 0 |
| PICKERING_LXI_TOPOLOGY | No | Path to your fixture map | dut_bench.json |
| PICKERING_LXI_HTTP_HOST | No | HTTP bind address | 127.0.0.1 |
| PICKERING_LXI_HTTP_PATH | No | HTTP endpoint path | /mcp |
| PICKERING_LXI_HTTP_PORT | No | HTTP port | 8000 |
| PICKERING_LXI_TRANSPORT | No | Transport type: stdio, streamable-http or sse | stdio |
| PICKERING_LXI_TIMEOUT_MS | No | Session timeout | 5000 |
| PICKERING_LXI_STATELESS_HTTP | No | When set, each HTTP request stands alone at the MCP protocol level | false |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| chassis_identifyA | Backend, driver, topology and current chassis status. |
| list_cardsA | Every open card with its subunits, matrix sizes and closure limits. |
| subunit_stateC | Every closed crosspoint on one subunit. |
| crosspoint_stateC | Whether one crosspoint is closed, and which routes are holding it. |
| list_endpointsA | The logical endpoint names this topology can route between. |
| list_routesB | Logical connections currently held open by this server. |
| plan_routeA | Dry run a route: the crosspoints it would close, and whether the interlocks permit it. Nothing is switched. Ask this before reserving the chassis. |
| interlock_statusB | Whether the interlock is armed, and the safety policy in force. |
| verify_topologyA | Check the topology's claims about the rack against what the chassis reports. |
| reserve_chassisB | Take a time-boxed reservation. Returns the token every mutating tool requires. |
| list_tool_tiersA | List every tool with its tier, so an agent can plan before it reserves. |
| arm_interlockC | Arm the chassis interlock. |
| disarm_interlockA | Disarm the interlock. Routes already open stay up; no new ones can be made. |
| route_signalB | Connect two logical endpoints by the shortest switch path. Refused whole if unsafe. |
| unroute_signalB | Tear down one route, keeping any crosspoints other routes still need. |
| clear_all_routesA | Open every crosspoint on every card and forget all routes. |
| set_crosspointB | Operate one crosspoint directly. Still bounds-checked and interlock-checked. |
| release_chassisB | Clear every route, disarm the interlock, and release the reservation. |
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 18 tools
Each tool targets a distinct operation: status queries, enumeration, dry-run planning, interlock control, route manipulation, and direct crosspoint control. Even similar tools like plan_route and route_signal are clearly separated by the dry-run vs actual-switch distinction.
Most tools follow a clear verb_noun or list_noun pattern, with a consistent *_state/*_status convention for queries. The main deviation is chassis_identify, which reverses the expected verb_noun order and stands out from the otherwise predictable scheme.
18 tools is slightly above the typical well-scoped range, but each tool covers a meaningful part of the switching chassis lifecycle. The inclusion of list_tool_tiers is a bit meta, but it serves the agent-planning workflow rather than adding redundancy.
The toolset covers the main lifecycle well: inspect, plan, reserve, arm, route, unroute, clear, and release. Minor gaps exist around reservation management — there is no explicit extend-reservation or reservation-status tool — but agents can work around these by releasing and re-reserving.