Continuing where the first post left off. The SAP 2000 MCP integration is now at v0.3 — call it the world's first natural-language interface to SAP 2000, with the caveat that "first" is only meaningful until somebody else does it. Four of nine planned phases are now operational, which means the core structural modeling pipeline runs end-to-end from a chat window — eleven days after the first joint was placed.
Where the prototype is right now
Status check across all four shipped phases:
- Phase 1 — SAP 2000 session management ✓
- Phase 2 — Structural geometry creation ✓
- Phase 3 — Materials and sections automation ✓
- Phase 4 — Loading system integration ✓
- Phases 5–9 — analysis execution, post-processing, design checks, optimization, and code-rule export (next)
Modules 1 and 2 already let me query and understand existing structures: connect to a SAP session, check units (kip_in_F), enumerate joints, frames, and areas (recent test: 88 frames, 41 areas), and pull model contents into context — all from natural-language prompts. That gave me the substrate for what came next.
What modules 3 and 4 unlocked
The new capabilities, in concrete terms:
- Material property creation and management — A992 Fy=50 ksi steel, 4 ksi (4000 psi) normal-weight concrete, density and modulus auto-set from named grades
- Frame section automation — W14×22 beams and W14×26 columns from the AISC database, plus shell properties for slabs and walls
- Load pattern creation and assignment — DEAD and LIVE patterns with their self-weight multipliers handled correctly
- Uniform load application to area objects — for example, −0.05 kip/ft² roof live and −0.18 kip/ft² floor dead, applied to specific area selections
- Multi-story structures created from coordinate-driven natural-language prompts — composing multi-property systems through a single exchange
- Real-time property assignment driven from chat — no manual step in the SAP UI
The thing that surprised me: once Phase 3 worked, Phase 4 fell out almost for free. Most of the LLM "knowledge" about loads is already in the training data — what was missing was the bridge to SAP's API. Once the bridge existed, the model could reason about gravity loads, lateral loads, and load combinations like an engineer would, then call the OAPI methods to express that reasoning.
A limitation worth being honest about
The system handles greenfield modeling well. Modifying an existing structure — adding elements to a model that already has hundreds of them — is the rough edge. Two failure modes show up:
- The system places elements one at a time when a batch operation would be cleaner and faster
- Placement is hit-or-miss when the LLM has to reason about local geometry inside an already-dense model
The honest diagnosis: most of this is the SAP 2000 OAPI itself, not the LLM. Some of the methods that would let me do clean batch insertions into existing models either do not exist or do not behave the way the documentation suggests. I am not blaming CSI for that — the OAPI was built for scripted, deterministic workflows, not for an AI that needs to compose calls dynamically against a moving model state.
What this might mean for the architecture
I am starting to think the long-term shape of this is not an MCP server with Claude Desktop on top. The MCP route is great for what I am doing now: prototype fast, swap clients, prove the concept. But for end users, two friction points keep showing up:
- Anyone who wants to use this has to install Claude Desktop, configure MCP, and maintain a Python environment
- For the modify-existing-structure case, I want tighter control over how the LLM sees the SAP session — possibly through a plugin model where the integration runs inside SAP, not alongside it
It might end up being a desktop app. It might end up being an SAP plugin. It might end up being both. I do not know yet — but v0.3 is teaching me which trade-offs matter and which do not.
What is next
Phase 5 is analysis execution and post-processing: run static analysis from chat, pull base reactions and member forces back into the conversation, surface code-design results in a way the engineer can actually act on. That should close the loop on the original thesis: describe a building, watch it get analyzed, get an engineering-grade summary back without ever touching the SAP UI.
Testing continues with Claude Desktop as the MCP client. Each release is a chance to figure out which capability shapes generalize and which are special-case enough to deserve their own dedicated handler.
Thanks
Computers and Structures, Inc. — thanks again for the tooling. The OAPI surface area is what makes any of this possible. If the modify-existing-structure path eventually turns into a plugin instead of an external integration, that is a sign of the SAP ecosystem being mature enough to support deeper hooks, not a sign of a problem.