dlubal-mcp

Model Context Protocol (MCP) server that enables AI tools and large language models (LLMs) to interact with running Dlubal structural analysis applications.

Built on top of the dlubal.api gRPC client library, dlubal-mcp exposes tools that AI assistants can call directly to do modelling, analysis or reading results through the API scripts.

Supported Applications

How It Works

Choosing a transport

dlubal-mcp speaks two MCP transports. Pick by how the client reaches it.

Use stdio unless something prevents it. It is what the MCP specification asks clients to prefer, and it needs no port and no token: the client owns the process, so there is no anonymous caller to authenticate. Browsers cannot launch a subprocess, which is why Dlubal CALC uses the HTTP door instead.

{
  "mcpServers": {
    "dlubal-mcp": {
      "command": "C:\\Program Files\\Dlubal\\RFEM 6.15\\bin\\python.exe",
      "args": ["-m", "dlubal_mcp", "--transport", "stdio"]
    }
  }
}

Running the Dlubal-bundled python.exe lets the server find the API key the Dlubal application already wrote, so no key configuration is needed. Set DLUBAL_MCP_ALLOW_SCRIPTS=false to withhold the script tools on stdio as well.

Running a stdio server next to the Connector. Both use the same execution journal in %LOCALAPPDATA%\DlubalMCP, so while one of them runs a script or a model operation, the other refuses new ones with busy. RFEM also accepts only one API client at a time, so read tools on the second server report RFEM as unavailable until the first finishes. Either retry, or keep one server in use. The exclusion holds only while both use the default journal: do not point RFEM_EXECUTION_STATE_FILE (or the RSTAB/RSECTION equivalents) at a different file on a machine that runs both.

Serving only some products

DLUBAL_MCP_PRODUCTS limits which products a server registers, as a comma-separated subset of rfem,rstab,rsection (default: all). Products outside the set register no tools and appear in health_check as {"disabled": true}; an unknown name stops the server at startup.

Use it to run one server per Dlubal API build. A product must be driven by a dlubal.api client of its own build: protobuf matches fields by number, the numbers move between builds, and a mismatched client returns wrong values without an error. Every Dlubal-bundled python.exe carries all three product clients, so a server started from RSTAB 9.14's Python would otherwise also offer RFEM and RSECTION tools on a 2.14 client.

HTTP access protection

Starting with 1.0.13, HTTP access always requires a separate bearer token and a numeric loopback bind address. The matching Dlubal Connector provisions this automatically. Standalone clients must configure DLUBAL_MCP_ALLOWED_API_KEYS and send Authorization: Bearer <access-token>; the Dlubal application API key is a separate credential. Anonymous operation and query-string tokens are not supported. See HTTP authentication and upgrade notes.

dlubal-mcp acts as a bridge between an AI assistant and a running Dlubal application. The application must already be open and its API service active — the MCP server connects to the live session, it does not launch applications itself.

1. Start RFEM 6, RSTAB 9, or RSECTION 1 on your machine
2. Launch the MCP server with proper settings (urls, API ports)
3. An AI tool calls e.g. run_rfem_script with Python code
4. The code executes against the live application and returns the output

LLM Responsibility for API Scripts

The run_rfem_script, run_rstab_script, and run_rsection_script tools execute arbitrary Python code against the live application. The LLM is responsible for composing correct and valid API scripts — the MCP server simply runs whatever code it receives and returns the output or any errors.

To write correct scripts, the LLM should consult the Dlubal API Documentation, which covers all available objects, methods, and usage patterns for the gRPC-based API.

After a script write fails

Managed scripts stop accepting writes after a write raises an exception, including a rejected model target or invalid arguments before the SDK call, even if the script catches that exception. Read-only inspection remains available, but further writes, model creation, and model opening are refused in that execution. The original failure is returned when the script finishes, so catching it cannot turn a failed or uncertain write into a successful tool result. This applies to RFEM, RSTAB, and RSECTION through their shared managed connection. Pre-SDK validation failures do not mark the journal as having attempted a model mutation; any earlier mutation record is preserved.

Earlier changes are not rolled back. Inspect the model before requesting further work. A new execution still follows the existing admission rules: an unknown outcome remains blocked by the execution journal. This guard does not make arbitrary Python a security sandbox.

If RFEM reports another connected client after a model write was attempted, the error warns about possible partial changes and does not recommend replaying the script. The same caution applies to uncertain execution outcomes. A busy connection before any write remains retryable when its outcome is known.

If an exception's diagnostic text or RPC status cannot be read, the execution remains unknown and blocks further scripts. Diagnostic failures cannot produce a successful result. Captured output and the recorded model GUID remain available for inspection, including after restarting the server.

Requirements

• Python 3.11 or higher
• A running Dlubal application (RFEM 6, RSTAB 9, or RSECTION 1)
• Active API Service subscription — see dlubal.api for details

Installation

pip install "dlubal-mcp[rfem]"      # RFEM 6
pip install "dlubal-mcp[rstab]"     # RSTAB 9
pip install "dlubal-mcp[rsection]"  # RSECTION 1
pip install "dlubal-mcp[all]"       # All products

Available MCP Tools

Typed RFEM result access

read_rfem_results is the preferred path for read-only agents. It accepts only five fixed result types (calculation_status, member internal forces, node deformations, stability critical load factors, and steel member design ratios). Result queries require bounded integer object numbers (except stability) and validated loading identifiers. Both filters are verified against every returned row. It never calculates, writes, opens, saves or switches a model.

The response is bounded to at most 100 rows and contains only allowlisted numeric fields, units, the active model GUID, the RFEM version, a complete model-input state_fingerprint and a canonical result_hash. The fingerprint is produced from RFEM's Python-gRPC model export before and after the result query. The export is canonicalised and hashed locally, then deleted; its model contents never leave the machine. If the model changes during the read or RFEM cannot produce the complete snapshot, the tool returns unavailable fail-closed. Model paths, object names, arbitrary RFEM warning text and exception messages are not returned. no_results and unavailable are explicit states, not successful checks.

Related

• dlubal.api — the underlying gRPC client library
• Dlubal API Documentation — reference for all API objects and methods used in scripts
• Dlubal Software