Talking to ETABS in Natural Language: ETABSharp + MCP

The question a structural engineer actually asks a model is short:

“What’s the maximum story drift in load case EQ-X, and is it inside the 0.5% limit?”

Answering it is not analysis. It is opening the model, finding the right table, reading a column and comparing it to one number. That is why nobody asks it forty times a day, and why the answer usually arrives as a screenshot pasted into a chat window.

An MCP server is the piece that removes the pasting. ETABSharp already turned the fetching into a typed method call; the server is that method call offered to an assistant as a tool.

What is MCP?

The Model Context Protocol (MCP) is an open standard that lets AI assistants (Claude, Cursor, VS Code Copilot, etc.) call external tools through a defined interface.

Instead of copy-pasting data into a chat window, the AI can directly invoke tools — query a database, run a calculation, read a file — and use the results in its response.

The MCP server

The server is a .NET console application in the ETABSharp repository, at mcp/EtabSharp.Mcp. It speaks MCP over stdio — the transport local desktop clients use — and it references the same EtabSharp assembly the C# scripts do.

The tools are grouped by what they touch:

So the question at the top of this page is GetStoryDrifts followed by one comparison, and the assistant does both halves.

That shape is the whole argument for building the wrapper first. A tool is a declaration wrapped around a call that already exists and already returns typed objects. GetStoryDrifts is a small piece of work when AnalysisResults hands back named fields; it is a project when the starting point is a COM ref array.

What it is for

The bottleneck in structural engineering isn’t analysis — it’s interpretation. Running 50 load combinations takes seconds. Checking which members fail and why takes hours.

A drift check is a handful of table lookups and one comparison, and it is tedious in exact proportion to how often it is worth repeating. That is the shape of work a tool call is good at: fetch the table, apply the limit, report which rows failed and by how much.

The judgement stays where it was. What moves is the fetching and the arithmetic, which were never the engineering.

How to set it up

1. Get the wrapper

dotnet add package EtabSharp --prerelease

2. Run the server

The server is a console project, so a clone runs it directly:

dotnet run --project mcp/EtabSharp.Mcp

3. Point a client at it

An MCP client that speaks stdio takes the command in its own configuration file:

{
  "servers": {
    "EtabSharp.Mcp": {
      "type": "stdio",
      "command": "dotnet",
      "args": ["run", "--project", "<path to mcp/EtabSharp.Mcp>"]
    }
  }
}

stdio means the client starts the server itself. There is no port to open and nothing is listening once the client closes — which matters when the process on the other end can reach an open model.

What this changes

ETABSharp + MCP is early-stage, but not in the way that phrase usually means. The wrapper is published on NuGet, the server is in the repository with its own README and client configuration, and the tools in the table above are methods you can open and read. What is early is the judgement: knowing when to trust a number a tool handed you about a model you did not open yourself is a habit nobody has built yet, including me.

One honest leftover: RandomNumberTools is still sitting in that folder from the project template. It does nothing for ETABS, and it is the sort of thing that stays until somebody tidies it.

GitHub: github.com/tadoEng/EtabSharp