A short progress update on the SAP 2000 MCP server. v0.4 is the first version where the size of the project starts to feel like a real engineering artifact rather than a weekend prototype, so it is worth pausing to write down what is actually in there.
The numbers
- 700+ Python source files
- 140,000+ lines of code
- 1,900+ wrapped OAPI functions
For perspective: the original SAP 2000 OAPI exposes roughly 2,000 functions across all of its COM objects. v0.4 wraps the vast majority of them in MCP-callable Python tools, with structured docstrings, parameter schemas, and per-tool natural-language phrasings. About 5% of the original OAPI surface area is intentionally left out — UI-only methods, deeply stateful flows that an LLM cannot reason about safely, and a few methods whose behavior contradicts the documentation enough that wrapping them would mislead the model.
The 20–40% overhead
Converting an OAPI method into an MCP-callable tool is not just renaming and re-exporting. Each tool needs:
- A plain-English description tuned for tool-call selection accuracy
- A typed parameter schema that the LLM will validate against
- Pre-call validation — coordinate-system checks, unit-system checks, joint-existence checks
- Post-call shape normalization so the return value is consistent across SAP versions
- Natural-language phrasings the model can match against incoming user requests
Once you sum all of that, an MCP wrapper of an OAPI method runs about 20–40% larger than the bare OAPI call would. That overhead is what makes the model actually pick the right tool for the right request — without the overhead, the catalog gets ambiguous fast and the model starts hallucinating method names.
The hardest part — porting from VBA / C# to Python
CSI’s reference implementations of OAPI usage are in VBA and C#. Bringing each one across to Python (the language MCP servers naturally live in) was not a one-shot translation:
- Type system differences forced explicit annotations everywhere VBA was implicit
- C# COM interop conventions and Python COM interop conventions disagree on byref parameter handling
- Some VBA samples relied on side-effect-y idioms that quietly do not translate — they have to be rewritten as explicit pre/post hooks
The latest pass through v0.4 was effectively a from-scratch rewrite of every wrapper. More careful, more test-covered, slower to land — but cleaner. There are still possibilities the migrated code will surface edge-case bugs along the way; the testing harness logs every disagreement between the wrapper output and the underlying OAPI ground truth so I can chase them.
What is in motion next
Two parallel ports keeping the team busy:
- CSI ETABS and CSiBridge — same OAPI shape as SAP 2000, mostly mechanical work
- Autodesk Robot Structural Analysis and Revit — Revit in particular has a much larger code base to deal with
Once the SAP 2000 MCP server fully materializes, the plan is to package the converted codebase into something accessible — either as a reference others can read, or as a downloadable starting point. The structural-engineering software ecosystem is small enough that hoarding the work would be a waste.
Thanks
Computers and Structures, Inc., Autodesk, and Anthropic — thanks for building tools, APIs, and protocols open enough that someone outside the original organizations can do this kind of work. The fact that the entire OAPI surface is documented well enough for an LLM to reason about it is the only reason any of this is possible.