OpenVSP MCP (Maintained Fork)
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENVSP_BIN | Yes | Path to the OpenVSP script binary (`vspscript` or `vsp` accepting `-script`). Required to run the server. | |
| VSPAERO_BIN | Yes | Path to the VSPAERO solver binary. Required to run the server. | |
| OPENVSP_CPU_BUDGET | No | Limits shared native work in one server; requests exceeding this budget are rejected. Optional. | the larger of 4 and the reported logical CPU count |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| openvsp.healthB | Fresh executable/API readiness and versions. |
| openvsp.create_modelC | Create a template or custom model. |
| openvsp.inspectA | Read XML geometry metadata without OpenVSP. |
| openvsp.modifyC | Validate edits, then replace the source model. |
| openvsp.previewC | Export SVG/STL from a private model copy. |
| openvsp.preflightC | Check loaded geometry sets without solving. |
| openvsp.run_vspaeroB | Solve one steady subsonic condition; verify actual solver inputs and results. Source preserved. fixed_wake selects the official fixed-wake flag. |
| openvsp.sweepC | Existing 1–25 condition sequential sweep. |
| openvsp.queryA | Query native capabilities, analysis input types/defaults, or geometry parameters. Read-only. Parameters are paginated. Analysis defaults may depend on the supplied model. |
| openvsp.set_parametersA | Apply parameter ID/value edits in one load/update, verify limits and readback, then replace the source. Obtain IDs with openvsp.query. |
| openvsp.read_resultsA | Read saved coefficients, settings and bounded log tails without running OpenVSP. |
| openvsp.batch_submitA | Submit independent steady cases with CPU and parallel-job limits. Returns a durable batch directory immediately; use batch_status, batch_cancel, batch_resume and batch_export. Source preserved; no automatic retry. Each case may edit parameters on a private copy. |
| openvsp.batch_statusB | Read paginated batch progress, including after a restart. |
| openvsp.batch_cancelA | Cancel selected case IDs, or the whole batch when empty. |
| openvsp.batch_resumeA | Explicitly retry non-successful cases after verifying the model, package, native binaries, specification and successful artifacts. Never replays successful cases. |
| openvsp.batch_exportA | Export a saved batch snapshot to CSV/JSON without solving. |
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 16 tools
Most tools occupy clearly distinct lifecycle roles: health, batch management, model creation/editing, preflight, analysis, and result reading. The only mild ambiguities are modify vs. set_parameters and run_vspaero vs. sweep vs. batch_submit, but the descriptions do enough to separate them.
Names use consistent snake_case, but grammatical styles are mixed: batch_* is noun-first, most other tools are bare verbs or verb_noun, and health is a standalone noun. The conventions are still readable and group-related tools are predictable, but the pattern is not uniform.
Sixteen tools is slightly above the typical 3-15 range, but each tool serves a meaningful purpose and the set is organized into clear clusters. The count feels justified for a full OpenVSP workflow rather than bloated.
The tool surface covers the core model lifecycle, parameter editing, preflight checks, single and sweep analysis, batch job submission/control/export, and result reading. Batch operations are especially complete with submit, status, cancel, resume, and export, leaving no obvious dead ends.