Ansys Rocky MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROCKY_MCP_EXE | No | Explicit Rocky executable path. Command line flag --rocky-exe takes precedence. | auto-detected |
| ROCKY_MCP_PORT | No | PyRocky RPC port. Command line flag --rocky-port takes precedence. | 18615 |
| ROCKY_MCP_BACKEND | No | Backend to use: 'auto', 'pyrocky' or 'mock'. Command line flag --backend takes precedence. | auto |
| ROCKY_MCP_VERSION | No | Ansys version code (e.g. 261 = 2026 R1). Command line flag --rocky-version takes precedence. | latest |
| ROCKY_MCP_WORKDIR | No | Working directory. | current directory |
| ROCKY_MCP_HEADLESS | No | Whether to run GUI or headless Rocky. Command line flags --headless / --no-headless take precedence. | true |
| ROCKY_MCP_MOCK_SPEED | No | Simulated seconds per wall-clock second (mock backend only). Command line flag --mock-speed takes precedence. | 8.0 |
| ROCKY_MCP_PYTHON_SESSION | No | Whether to enable the persistent Python session. Disable with the --no-python-session flag. | enabled |
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": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rocky_statusA | Report the status of the Rocky MCP session. Returns the active backend, whether a real Ansys Rocky application is installed and reachable, the detected Rocky versions, the open project and the current simulation state. Use this first: it is the only tool that never launches Rocky. |
| rocky_connectC | Connect to Ansys Rocky. |
| rocky_disconnectA | Disconnect from Ansys Rocky and release the session. |
| rocky_create_projectA | Create a new, empty Rocky project. Any previously open project is replaced and the object registry is reset. |
| rocky_open_projectC | Open an existing Rocky project file. |
| rocky_save_projectB | Save the open Rocky project. |
| rocky_close_projectB | Close the open Rocky project. |
| rocky_describe_studyA | Describe the open project and study. Returns the project path, every study element with its class and key parameters, the domain and solver settings, the user processes, the simulation state, and the identifiers of the registered objects. Call this after any setup step to confirm what the study actually contains. |
| rocky_import_wallC | Import a geometry file as a Rocky wall. |
| rocky_create_surfaceB | Create a circular or rectangular Rocky surface. |
| rocky_create_particleC | Create a Rocky particle definition. |
| rocky_create_inletB | Create a particle inlet on a surface and set its mass flow rate. |
| rocky_create_outletC | Create a Rocky outlet on a surface. |
| rocky_set_domainC | Configure the Rocky domain limits. |
| rocky_set_simulation_settingsC | Configure the Rocky solver settings. |
| rocky_set_motionC | Apply a rotation or translation motion to one or more study objects. |
| rocky_run_simulationC | Start the Rocky simulation. |
| rocky_simulation_statusA | Report the state of the running simulation. Returns whether the solver is running, the progress percentage, the computed time set and whether results are available. |
| rocky_wait_for_completionC | Wait until the running simulation finishes. |
| rocky_get_curveC | Read a time series produced by the simulation. |
| rocky_list_grid_functionsB | List the grid functions available for the current study. |
| rocky_get_grid_function_statsA | Read the minimum and maximum of a grid function over the time set. |
| rocky_create_selectionC | Create a selection process for post-processing. |
| rocky_list_processesB | List the user processes and registered objects of the study. |
| rocky_run_pythonA | Run arbitrary Python code in the persistent Python session. This is the escape hatch for anything the dedicated tools do not cover. The session keeps state between calls, so variables survive from one invocation to the next. |
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 25 tools
Most tools target distinct resources/actions (create_inlet vs create_outlet vs create_surface vs import_wall are clearly separated). However, the reporting cluster is somewhat overlapping: rocky_status, rocky_describe_study, rocky_simulation_status, and rocky_list_processes all surface state information, which could cause hesitation about which to call. The descriptions do help distinguish them (session vs study contents vs solver progress vs object registry), so the overlap is manageable.
Every tool uses the rocky_ prefix followed by a snake_case verb_noun pattern (rocky_create_inlet, rocky_open_project, rocky_set_motion, rocky_run_simulation). Minor noun-only names like rocky_status are still readable and consistent with the resource-query style. No mixed conventions anywhere.
25 tools sits at the heavy end for this surface. The domain (full simulation setup, execution, and post-processing) justifies many of them, but the number is borderline and includes several narrow report tools that could plausibly be consolidated. It is not padded with obviously redundant tools, but it is on the edge of feeling sprawling.
The surface covers connection lifecycle, project CRUD (create/open/save/close), geometry/domain setup, particle and boundary creation, solver configuration, simulation run/status/wait, and post-processing (curves, grid functions, selections). Gaps exist: there are no explicit delete/remove tools for created objects and no material/CFD-coupling tools, but rocky_run_python serves as a deliberate escape hatch for these, so agents can work around them.