Vensim MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| vensim_doctorA | Detect local Vensim and report the exact native automation boundary. |
| generate_vensim_modelB | Generate a styled, runnable .mdl file from a JSON model specification. |
| inspect_vensim_modelA | Read equations, sketch objects, arrows, and views from a text .mdl model. |
| validate_vensim_modelB | Run a conservative static audit before opening the model in Vensim. |
| render_vensim_previewB | Render an SVG preview from the model's actual Vensim sketch records. |
| open_vensim_modelB | Open a .mdl in the locally installed Vensim application. |
| create_vensim_dss_scriptC | Create a Vensim DSS .cmd batch script; PLE does not support this official path. |
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 7 tools
Each tool targets a distinct action: environment detection, model generation, inspection, validation, rendering, opening, and script creation. There is no overlap in purpose or output, making tool selection unambiguous.
Most tools follow the `verb_vensim_noun` pattern (generate_vensim_model, inspect_vensim_model, etc.), but `vensim_doctor` deviates by being a noun-first name without a clear verb. This is a minor inconsistency, not a chaotic mix.
Seven tools is a well-scoped size for a domain-specific integration. Each tool covers a necessary workflow step without redundancy, fitting comfortably within the ideal range.
The surface covers the primary lifecycle: create (generate), read (inspect), validate, preview (render), and open. Missing update/delete operations are acceptable since models are generated from JSON specs, and there is no simulation tool, but the core use cases are well addressed.