SiLA 2 Bridge

SiLA 2 Bridge — MCP Server

Let an AI agent work with any SiLA 2 server: liquid handlers, incubators, plate readers, robotic arms, balances or scheduling middleware that implement the open SiLA 2 lab-automation standard. The bridge reads the server's own Feature Definitions (FDL), so it knows every command, property, parameter type, unit and constraint. It validates parameters against the FDL before sending, runs and tracks long-running (observable) commands, and cancels them through SiLA's CancelController.

Try it without hardware

uvx labmcp-sila2 --simulate --check

--simulate starts a real SiLA 2 server in-process, built with the sila2 library. It runs on 127.0.0.1 on a free port, unencrypted, with discovery off. It implements a simulated thermoblock feature (org.labmcp/simulation/TemperatureController/v1) and the official CancelController feature:

• the observable CurrentTemperature property, plus TargetTemperature, RampRate and DeviceState
• ControlTemperature, an observable command with progress, intermediate responses and a DeviceBusy defined error
• RunProgram, taking a list of {TargetTemperature, HoldTime} structures
• SetRampRate, constrained to 0 < rate ≤ 10 K/s
• SwitchOff

The whole bridge runs through the real gRPC and FDL path.

Connect your SiLA server

1. Find it. Use the discover_servers tool (mDNS _sila._tcp), or run the server with its address and port shown. SiLA has no default port, but 50052 is common.
2. TLS. SiLA 2 servers use TLS by default, and most generate a self-signed certificate at startup. Pass that certificate's CA as --option root_cert=ca.pem: many servers write it to a file or publish it in their discovery record. Servers started in insecure test mode need --option insecure=true. For mutual TLS, add --option client_cert=… --option client_key=….
3. Test the connection:
   bash

   uvx labmcp-sila2 --address 192.168.1.40:50052 --option root_cert=~/sila/ca.pem --checkuvx labmcp-sila2 --address sila://localhost:50052 --option insecure=true --check      # test serveruvx labmcp-sila2 --option server_name="Liquid Handler 1" --option root_cert=ca.pem --check  # via discovery

Add to your MCP client

Claude Code

claude mcp add sila -- uvx labmcp-sila2 --address 192.168.1.40:50052 --option root_cert=/path/ca.pem

Claude Desktop / Cursor / Windsurf (claude_desktop_config.json, .cursor/mcp.json, …)

{  "mcpServers": {    "sila": {      "command": "uvx",      "args": ["labmcp-sila2", "--address", "192.168.1.40:50052", "--option", "root_cert=/path/ca.pem",               "--option", "command_allowlist=Incubator.*,PlateReader.ReadPlate"]    }  }}

--read-only lets the agent browse features, read and subscribe to properties, and check command status, but not call commands. cancel_command stays available. To restrict which commands may run, use --option command_allowlist=Feature.Command,Feature.*. Entries can also be separated by ; or spaces, which is handy inside LABMCP_OPTIONS=command_allowlist=A.B;C.*.

Tools

Safety limits

Override at launch, e.g. --limit max_command_wait_s=60. The main guards for commands:

The server always re-validates too, so parameters rejected there come back as SiLA validation errors.

Example prompts

• "What SiLA servers are on the network, and what can the incubator do?"
• "Set the incubator to 37 °C and tell me when it has reached the temperature."
• "Watch the plate reader's chamber temperature for a minute and tell me if it's stable."
• "Run the 'PCR-short' program on the thermocycler, poll its progress every 30 seconds, and report the result."
• "Something's wrong, cancel everything that's running on the liquid handler."
• "Show me the parameters (types, units and allowed ranges) of the robot's MovePlate command."

Notes

• Types as JSON. list_features renders each SiLA type as a JSON-schema-like dict: Real becomes number, Integer becomes integer, List becomes array and Structure becomes object. SiLA units appear as x-unit (the label) and x-unit-si (the conversion to SI base units, SI = value × factor + offset). Other SiLA details use x-sila-* keys. Values are passed as JSON:
  • Binary: base64 strings
  • Date: YYYY-MM-DD[±HH:MM]
  • Time: HH:MM:SS[±HH:MM]
  • Timestamp: ISO 8601, UTC if no offset is given
  • Any: {"type": "Real", "value": 1.5}, basic types only
• Observable commands return an execution_id right away. get_command_status reports the SiLA execution status (waiting, running, finishedSuccessfully, finishedWithError), progress, estimated remaining time and the latest intermediate response. get_command_result returns the responses, or the defined/undefined execution error together with the error's description from the FDL. Pass wait_s to call_command for short runs. Executions are tracked only for this session and are forgotten on reconnect.
• Cancellation isn't part of core SiLA. It needs the server to implement org.silastandard/core.commands/CancelController/v1, and get_server_info reports whether it does. Some vendors provide their own Stop/Abort commands instead, which list_features shows.
• SiLA client metadata (e.g. a LockController lock identifier or an AuthorizationService access token) can be passed with metadata={"LockController.LockIdentifier": "…"} on call_command, get_property and subscribe_property. Values are validated against the metadata's FDL type.
• Feature Definitions are parsed only after refusing any DOCTYPE/entity declaration (SiLA FDL never uses one), so a hostile server can't trigger XML entity expansion. Features that the sila2 library rejects as invalid are left out of list_features (the command log records why).
• Not checked locally: Schema and ContentType constraints, and the Unit constraint, which is informational. The server enforces these. Large binaries (over 2 MB) use SiLA binary transfer, which the sila2 library handles.
• Library limitation (sila2 ≤ 0.14): a Constrained List used directly as a command parameter or response can't be unpacked. Parameters are affected on servers built with sila2, which is why the simulator's RunProgram uses a plain list and checks the 1–10 steps itself. Responses of that shape are affected in this bridge: the server executes the command, but its response can't be decoded. The bridge reports this as "WAS EXECUTED … could not be decoded" so the command is not repeated blindly. Properties of that shape decode fine. Plain (unconstrained) lists are not affected.
• Discovery browses mDNS for the requested time and returns what servers advertise (UUID, name, version, address, whether a CA certificate is published) without connecting to them. In --simulate mode it returns only the simulated server and sends nothing on the network.

Hardware verification