ETABS MCP Server
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": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| discover_apiA | Discover available API guidance and skills. Call this FIRST before using other etabs-mcp tools.
Then use |
| read_skillsA | Read one or more skills by name. Use |
| list_instancesA | List all running ETABS instances. Returns a list of instances with their alias, process ID, currently
open file path, and ETABS version. Call this before If a version is below the minimum supported (21.0.0), a |
| get_statusA | Check the connection to an ETABS instance. Pass Returns connection state, ETABS version, model path, and lock status. |
| prepare_sessionA | Open ETABS if needed and prepare a usable session, without computer-use. Call this before creating geometry on the Start Page or when ETABS is closed. For a NEW building use new_model=True (omit instance): it opens a separate ETABS process, creates the requested grid in metres, and saves a unique model. Existing files and unsaved geometry are never reset or overwritten. With new_model=False a loaded model is returned unchanged; an empty, unsaved session receives a new grid and unique file automatically. This tool does not click, type, arrange other apps, or create view windows. If ETABS needs authentication, the user completes that sign-in manually. |
| get_model_geometryA | Read point, frame, area, opening and story geometry in metres. Preserves model units, lock, analysis results and all ETABS windows. Uses only the COM model API. Never reads or controls the desktop. |
| render_model_viewA | Generate and return a PNG from ETABS API geometry, with no screen access. For a plan specify an exact story such as Story3. Other views are 3d and a frontal elevation. Saves a unique PNG under Documents/ETABS-MCP/exports. These are API-derived drawings, NOT screenshots of ETABS's windows. No clicks, keys, focus changes, menus or native view window changes occur. |
| execute_codeA | Execute Python code in a sandbox against the ETABS COM API (call discover_api and read_skills first). The sandbox provides a pre-connected The last expression value or an explicit |
| search_docsA | Search ETABS API documentation by natural language query. Returns matching API methods with their Python calling convention. Use this to discover the correct method name, parameters, and return format for any ETABS operation before using execute_code. |
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 9 tools
Most tools target clearly distinct concerns (session prep, geometry read, rendering, code execution), but the trio of discover_api, read_skills, and search_docs all relate to finding API guidance and could be conflated by an agent. Similarly, get_status and list_instances both surface connection/version info, though the descriptions do clarify the split.
All nine tools use a consistent snake_case verb_noun pattern: get_model_geometry, discover_api, read_skills, list_instances, get_status, prepare_session, render_model_view, execute_code, search_docs. No camelCase or stylistic mixing, and verbs are meaningful and predictable.
Nine tools is a well-scoped set for a domain that delegates the bulk of operations to a code-execution escape hatch. Each tool (discovery, session, status, geometry, render, docs search, execute) earns its place without redundancy.
The surface covers the full lifecycle: discovery, session preparation, instance/status checks, geometry read, rendering, and a general execute_code path for writes and analysis. The only minor gap is the absence of dedicated higher-level write/analysis tools, but execute_code plus search_docs reasonably covers those workflows.