ETABSharp

The raw API

ETABS exposes almost all of itself through a COM API, and that API is COM-era all the way down. Results come back through ref arrays. Failures come back as an integer you have to test yourself after every call — ret != 0 — rather than as an exception. Arguments are strings, with no compiler and no IntelliSense standing behind them.

None of that is wrong, exactly. It is that every script pays the same tax before it does any engineering, and the boilerplate is where the mistakes live: a return code nobody checked, a model left locked, a hidden ETABS instance left running after the batch job finished. The wrapper’s own article writes that control flow out in full.

What the wrapper adds

ETABSharp sits directly on the COM API and changes four things.

• Typed results. Operations return objects with named fields, not ref arrays you have to unpack positionally.
• Fluent access. You navigate to the thing you want instead of assembling parameter arrays by hand.
• Real exceptions. EtabsAnalysisException, EtabsElementException, EtabsMaterialException and three siblings, instead of an integer tested at every call site.
• Session lifecycle. Attach to a running ETABS, or start a hidden instance for a batch job — with the model lock and the save prompts handled either way.

What that looks like end to end, against an open model:

using var etabs = ETABSWrapper.Connect();
var model = etabs.Model;

model.Materials.AddConcreteMaterial("C30", fc: 30, ec: 25000);
model.PropFrame.AddRectangularSection("COL-400x400", "C30", 400, 400);

model.Analyze.RunAnalysis();

var disp = model.AnalysisResults.GetJointDispl("", eItemTypeElm.Objects);

The wrapper is deliberately thin: a method maps onto an ETABS API call rather than hiding it. If ETABS can do it, ETABSharp exposes it — and where ETABS cannot, neither can this.

Design principles

Thin wrapper, not a replacement

ETABSharp does not try to stand in front of ETABS. It gives the same capabilities a safer, cleaner way in, which is what keeps the full API surface reachable and behaviour predictable. Nothing is computed here that ETABS computes itself.

Typed results over out-parameters

Every output is a typed object with named fields. A JointDisplacementResult carries ObjectName, LoadCase, StepType and the six displacement components, where the raw call fills a row of parallel arrays through ref and leaves you to line them up by index. That is what makes a result readable at the call site, discoverable through IntelliSense, and safe to pass onward.

Ergonomics measured in a real script

The test of the design is how much of a working automation script is about the model rather than about the API. Session setup, lock state, return-code checks and array unpacking are all overhead; the goal is to shrink them until what is left reads as engineering.

The MCP layer

The same repository carries an MCP server — mcp/EtabSharp.Mcp — that publishes the wrapper’s operations as tools an AI assistant can call. Pointed at a client that speaks the protocol, such as Claude Desktop or VS Code Copilot, it covers three kinds of request.

• Read the model. “What is the dead-load base reaction of this model?” Base reactions, story drifts, joint displacements, frame forces and modal results, plus a project summary meant as the first call, before any of the detail.
• Build the model. “Add a 400x400 C30 rectangular column section.” Materials, frame and shell sections, load patterns, points, frames, restraints, and point or distributed loads.
• Run the analysis. “Run the seismic cases and tell me the status.” Choose which load cases run, run them, and read the per-case state back.

The assistant picks the tool; what comes back is the wrapper’s typed result rather than scraped text. That is what the typing was for — a structured answer is one the assistant can reason over instead of re-parse. The MCP article traces one question down to the tool that answers it.

What it does not do

Design checks are the honest gap. The wrapper has a design layer — concrete and steel managers over ACI 318-14 and AISC 360-16, returning per-element results — but none of it is exposed as an MCP tool yet, so an assistant cannot run a code check for you today.

It is also not a way to avoid ETABS. The package needs ETABS v22 or later installed, .NET 10, and Windows. It deliberately does not ship ETABSv1.dll; it locates the one your own ETABS installation already has.

Get it

• Source: github.com/tadoEng/EtabSharp
• Documentation: deepwiki.com/tadodev/EtabSharp
• Package: nuget.org/packages/EtabSharp

dotnet add package EtabSharp --prerelease

--prerelease is required while EtabSharp has no stable release — without it, the bare command has nothing to resolve.