Drives Altair Inspire on Windows through its headless batch mode: runs Python inside Inspire (e.g. creating geometry, querying models), inspects models and their parts/materials/load cases, summarizes OptiStruct .h3d results (min/max displacement, stress), and exports OptiStruct .fem input decks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@inspire-mcp summarize von Mises stress results in C:\models\bracket.h3d"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small Model Context Protocol (stdio) server that lets an AI agent
(Cursor, Codex, Claude Desktop, ...) drive Altair Inspire on Windows through Inspire's
official headless batch mode and its Python API (hwx.inspire).
Unofficial. Not affiliated with or endorsed by Altair. You need your own licensed Inspire install.
Tested with: Altair Inspire 2026.0 (release file 2026, embedded Python 3.10.18) on Windows 11,
mcp 1.30 (Python 3.13 venv), Cursor CLI and its MCP client.
Each tool call writes a small Python script into a fresh run folder and launches
<Inspire>\hwx\bin\win64\ExecWinEnvInsp.exe -cfg -b -p Inspire -ex hwx.exe -f <run>\task.pyThe script runs inside Inspire's own interpreter with from hwx import inspire available, writes
result.json, and Inspire exits. Consequences:
No GUI is opened and an Inspire window you already have open is never touched.
No state is kept between calls (each call is a new process, ~2-15 s startup, longer for big models).
Save to a .stmod if you need to continue in a later call.
On timeout, only the batch process tree started by that call is terminated.
Calls are serialized (one Inspire batch process at a time per server).
Each run folder keeps user_code.py, args.json, result.json, stdout.log, stderr.log.
Related MCP server: Windows-MCP
Tool | What it does |
| Is Inspire found, install root, release/version, batch executor path, running Inspire processes, free RAM. Does not start Inspire. |
| Run arbitrary Python inside a fresh headless Inspire. Names provided: |
| Open a model read-only ( |
| Open an OptiStruct |
| Export an OptiStruct input deck ( |
Example for inspire_run_python:
m = inspire.newModel()
m.createSolidBlock(x=0.02, y=0.01, z=0.005)
b = inspire.geometry.minBoundingBox(m.parts)
result = {"parts": len(m.parts), "bbox_m": [b.x, b.y, b.z]}API reference: https://help.altair.com/inspire/inspireapi/index.html
Requires Windows, Altair Inspire with a working license, and Python 3.10+ for the server itself (the server does not need Inspire's Python; it just launches Inspire).
git clone https://github.com/zchenjun88-hash/inspire-mcp.git
cd inspire-mcp
python -m venv venv
.\venv\Scripts\python.exe -m pip install -r requirements.txt
# quick check: prints status and runs a tiny script inside Inspire
.\venv\Scripts\python.exe inspire_mcp_server.py --self-testIn this order:
--inspire-root <path> command-line argument
INSPIRE_ROOT environment variable
Auto-detect on all drives: X:\Altair Inspire*\Inspire*\, X:\Program Files\Altair\*\Inspire*\,
X:\Program Files\Altair\*\, X:\Altair\*\Inspire*\
The path may be the install root (e.g. C:\Program Files\Altair\2026), the Inspire2026 folder,
or ExecWinEnvInsp.exe itself.
Run folders go to --runs-dir, else INSPIRE_MCP_RUNS, else ./runs next to the script.
Keep this path ASCII-only (see Known issues).
%USERPROFILE%\.cursor\mcp.json:
{
"mcpServers": {
"inspire": {
"command": "C:\\path\\to\\inspire-mcp\\venv\\Scripts\\python.exe",
"args": ["-u", "C:\\path\\to\\inspire-mcp\\inspire_mcp_server.py",
"--inspire-root", "C:\\Program Files\\Altair\\2026"]
}
}
}For the Cursor CLI (agent), you can pre-approve the tools by adding "Mcp(inspire:*)" to
permissions.allow in %USERPROFILE%\.cursor\cli-config.json, then check with agent mcp list.
%USERPROFILE%\.codex\config.toml:
[mcp_servers.inspire]
command = 'C:\path\to\inspire-mcp\venv\Scripts\python.exe'
args = ['-u', 'C:\path\to\inspire-mcp\inspire_mcp_server.py']
env = { INSPIRE_ROOT = 'C:\Program Files\Altair\2026' }
startup_timeout_sec = 30
tool_timeout_sec = 900 # exports of large models can take minutesAny MCP client that can launch a stdio server works: command = the venv python.exe,
args = inspire_mcp_server.py plus optional --inspire-root.
Non-ASCII output paths hang OptiStruct export (observed on Inspire 2026: the batch process
idles forever when the .fem target folder contains e.g. Chinese characters). The export tool
therefore exports into an ASCII-only staging folder (inside the runs dir, or %SystemDrive%\inspire_mcp_stage)
and copies the deck to your requested path. Opening models from non-ASCII paths worked fine.
If you write your own export code with inspire_run_python, use ASCII paths.
Not a live-GUI bridge: it cannot see or change the model currently open in your Inspire window.
inspire_h3d_summary reads the first subcase/step; field names must match the names listed
in available (shell models, for instance, may not expose von Mises Stress).
inspire_run_python executes arbitrary code with your user's permissions. Only connect it to
agents you trust and review what they run.
Some MCP clients have short default tool timeouts (Codex: 60 s). Raise them for exports.
这是一个让 AI 助手（Cursor、Codex 等）通过 MCP 操作 Altair Inspire 的小服务。原理是调用 Inspire 官方的
无界面批处理（ExecWinEnvInsp.exe -cfg -b -p Inspire -ex hwx.exe -f 脚本.py），在 Inspire 自带的 Python 里执行
hwx.inspire 接口。每次调用都是一个全新的后台 Inspire 进程，不会打开界面，也不会碰你已经开着的 Inspire 窗口；
调用之间不保留状态，需要接着做的请先保存成 .stmod。
已测试版本：Altair Inspire 2026.0（Windows 11）。工具：inspire_status（安装/版本状态）、
inspire_run_python（在 Inspire 里跑任意 Python，给 result 赋值即可返回）、inspire_model_info（读取模型的零件、
材料、载荷工况）、inspire_h3d_summary（读取 .h3d 结果的最大/最小值）、inspire_export_optistruct（导出 OptiStruct .fem）。
安装：python -m venv venv，venv\Scripts\python.exe -m pip install -r requirements.txt，然后按上面的
Cursor / Codex 配置登记。Inspire 安装路径可用 --inspire-root 参数或 INSPIRE_ROOT 环境变量指定，不指定会自动搜索。
注意：导出路径含中文时 Inspire 2026 的 OptiStruct 导出会卡死，本工具已自动先导出到纯英文临时目录再复制过去； 自己写导出脚本时请用纯英文路径。需要有效的 Inspire 许可证。
MIT, see LICENSE.
Open a model in headless Inspire and export an OptiStruct input deck (.fem) for its parts and the given load cases (default: all), using inspire.OptiStructAnalysis.export. element_size_m is in metres. Refuses to overwrite an existing output file. Does not run the solver. Export happens in an ASCII-only staging folder and the .fem is then copied to output_fem (Inspire 2026 export hangs on non-ASCII output paths).
| Name | Required | Description | Default |
|---|---|---|---|
| run_name | No | ||
| timeout_s | No | ||
| load_cases | No | ||
| model_path | Yes | ||
| output_fem | Yes | ||
| element_size_m | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it states that overwriting is refused, that the solver is not run, and that export occurs through an ASCII-only staging folder before copying to the final path. It leaves out permissions/auth needs, timeout behavior, and what success returns, so it is not fully complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and key constraints are front-loaded, and most sentences carry operational value. The description is slightly dense with implementation details, such as the specific Inspire API method, but it remains compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with no annotations and no output schema, the description covers purpose, overwrite refusal, non-solver behavior, and the ASCII path workaround. However, it does not explain run_name, timeout_s, or the return value, leaving gaps an agent may need filled elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds useful meaning for element_size_m (metres), load_cases (default all), output_fem (ASCII staging workaround), and model_path context, but run_name and timeout_s are not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: open a model in headless Inspire and export an OptiStruct input deck (.fem). It also scopes the operation to parts and given load cases, so an agent can distinguish this from the sibling status/info/run_python tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies when to use this tool: exporting an OptiStruct .fem, with the default of all load cases, and explicitly says it does not run the solver. It does not name a sibling alternative or spell out when not to use it, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an OptiStruct .h3d result file in headless Inspire and return, for each analysis run, the list of available result types and min/max (with positions) for the requested fields (default: Displacement, von Mises Stress) at the first subcase/step.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| units | No | MKS | |
| fields | No | ||
| timeout_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful behavior: read-only semantics are implied by 'Read', and a key scope limitation is stated (only the first subcase/step is summarized). It omits whether headless Inspire is launched on demand, license/session requirements, cost, and failure behavior for missing/invalid files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the resource before the return contract; every clause (headless, per-run, min/max with positions, first subcase) earns its place. Slightly dense but not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The return value is described well, which matters since there is no output schema, and there are no annotations to lean on. However, for a 4-parameter tool at 0% schema coverage, leaving 'units' and 'timeout_s' unexplained and omitting any note on prerequisites or failure modes leaves real gaps an agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and only partly does: 'path' is implicitly the .h3d file and 'fields' is explained via the default (Displacement, von Mises Stress). 'units' (default MKS) and 'timeout_s' (default 300) are never mentioned, so half the parameters have no meaning anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb+resource pair ('Read an OptiStruct .h3d result file in headless Inspire') and states precisely what is returned (result types per run, min/max with positions). An agent can clearly tell this apart in substance from status/model-info/export siblings, though the description never names or explicitly contrasts them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent deduces this is the tool for a quick results summary versus export or model inspection, and that it requires an existing .h3d file. There is no explicit 'use when' statement, no exclusions, and no mention of prerequisites such as an Inspire license or session, nor when inspire_export_optistruct or inspire_model_info would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a model file read-only in headless Inspire (.stmod, .fem and other formats Inspire can open) and summarize parts (dimensions, mass, volume, material, sheet thickness), load cases, loads and contacts (bounding_box = minimum bounding box x/y/z). The file is not saved or modified. units: e.g. MKS, MMKS.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| units | No | MKS | |
| timeout_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well on the safety profile: it explicitly says the file is opened read-only and is not saved or modified, and it discloses that the tool runs headless Inspire. It also explains the bounding_box convention. It does not mention that launching Inspire is expensive/slow, nor what happens on timeout or an unopenable file, which is why it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the action and safety guarantee, followed by a short units note. Every clause carries information (output fields, bounding_box definition, non-destructive guarantee). Slightly over-packed, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe return values, and it does so thoroughly by enumerating the summary sections and the bounding_box convention. What is missing is operational context around the 300s timeout and the cost of spinning up headless Inspire, which matters for an agent deciding whether to call this repeatedly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all three parameters. It only clarifies one: 'units: e.g. MKS, MMKS' gives usable values for the units parameter. The path parameter is self-evident, but timeout_s (default 300s) is never explained, leaving the agent to guess at runtime expectations and timeout behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (open read-only, summarize) and resource (an Inspire model file, with example extensions), then enumerates exactly what is summarized: parts with dimensions/mass/volume/material/sheet thickness, load cases, loads, and contacts. This is clearly distinguishable from siblings like inspire_h3d_summary or inspire_export_optistruct, which handle different formats/tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: an agent can infer this is the tool for inspecting a model before doing anything else, and the read-only framing tells it this is a safe inspection step. However, no alternative is named (e.g., when to prefer inspire_h3d_summary or when to use inspire_run_python instead), and no prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Python code inside a fresh headless Altair Inspire process.
Pre-defined names: inspire (hwx.inspire module), RUN_DIR (a scratch folder for this run).
Assign result = ... to return data; print() output is captured in stdout.
Example: m = inspire.newModel(); m.createSolidBlock(x=0.01, y=0.01, z=0.01); result = len(m.parts)
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| timeout_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It usefully states that code runs in a fresh headless process, that RUN_DIR is a scratch folder, and that result assignment and print() output are captured. However, it omits important behavior such as timeout semantics, error handling, persistence of model state, side effects, and permissions or sandboxing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and execution environment. The predefined names, result convention, and example all earn their place by clarifying invocation. There is no redundant or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the execution model and return conventions (result and stdout), which is important because no output schema exists. However, for an arbitrary code execution tool with no annotations and 0% schema parameter descriptions, the missing timeout behavior and failure/persistence semantics leave meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It explains the code parameter well by naming available objects, the result-return convention, and stdout capture. It completely omits the timeout_s parameter, which is undocumented in both the schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: run Python code inside a fresh headless Altair Inspire process. It is clearly distinct from siblings like inspire_status, inspire_model_info, inspire_h3d_summary, and inspire_export_optistruct. The predefined names and example further confirm the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the execution context and example, but it does not explicitly say when to use this tool versus the sibling tools. There is no guidance on when not to use it or which alternative to select for model inspection, status, or export tasks. The use case is inferable but not clearly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether Altair Inspire is installed/found, its version, batch executor path, running Inspire-related processes, free memory and the runs directory. Does not start Inspire.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key trait: it only reports and does not launch Inspire, so there are no side effects. The enumerated return surface (version, executor path, processes, memory, runs directory) further tells the agent what evidence it will get, though failure behavior when Inspire is absent is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the positive scope stated first and the negative scope ('Does not start Inspire') closing it out. Every clause names a distinct piece of reported information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates well by listing the specific fields returned, which is exactly what an agent needs before calling a status probe. It falls short only on edge cases such as what the report shows when Inspire is not installed or whether the process/memory scan is expensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and the schema has nothing to leave undocumented. The description correctly says nothing about inputs, which is consistent with the empty properties object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Report' is paired with an explicit enumeration of the resources inspected (install presence, version, batch executor path, running processes, free memory, runs directory), which is unambiguous. It also carves out scope against action-oriented siblings by stating 'Does not start Inspire', though no sibling is named directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is a diagnostic/pre-flight check to run before invoking inspire_run_python or the export tools, but the description never says when to prefer it or what to do with the result. The single exclusion ('Does not start Inspire') is the only explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0inspire_export_optistructinspire_h3d_summaryinspire_model_infoinspire_run_pythoninspire_statusScored across 5 tools
Each tool targets a distinct stage of the headless Inspire workflow: status check, Python execution, model inspection, result reading, and OptiStruct export. The main overlap is that inspire_run_python is a generic escape hatch that could technically replicate model_info, h3d_summary, or export, but the dedicated tools' descriptions make their intended scope clear.
All five tools share the inspire_ prefix and snake_case, giving a predictable namespace. Minor deviation: three names are noun-style (status, model_info, h3d_summary) while two are verb_noun (run_python, export_optistruct), so the verb convention isn't fully uniform.
Five tools is well within the ideal 3-15 range and each covers a distinct workflow need without redundancy. The generic run_python handles arbitrary scripting, so no bloat of convenience wrappers is needed.
The surface covers discovery, execution, model inspection, results extraction, and export — a coherent lifecycle for headless Inspire automation. Gaps remain: there is no dedicated tool to run the solver (export explicitly does not solve) and no model save/conversion flow, though inspire_run_python can bridge most of these.
Connect ChatGPT, Claude, Cursor or VS Code to your Windows PC: files, terminal, browser, apps.
Connect AI assistants to your approved computer for files, commands, browser and desktop tasks.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
