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.

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.

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