All posts
Sep 4, 20256 min readAfrasayab MahsudResearch

v0.8 — A Custom MCP Client and Server, and a 5-Tower Demo

Two months in, the prototype no longer needs Claude Desktop. v0.8 ships a custom MCP client running directly against the Claude API, paired with a custom MCP server. The demo: five towers, 30–80 floors each, cable-stayed sky bridges. 42,429 elements. Under 10 minutes versus 30+ hours of manual modeling.

Continuing the affiliation-with-CSI-tools series — this is v0.8, and it is the first version where the prototype stops borrowing other people’s frontends. v0.8 ships a custom MCP client that runs directly against the Claude API, paired with a custom MCP server. No more Claude Desktop. No more Windsurf as a host. The chat window, the model orchestration, and the SAP 2000 / ETABS bridge all live in one process.

It took longer than I wanted. I will be honest — during testing I was manually refreshing the SAP window to see the latest changes propagate. The integration is real, but parts of it are still inelegant. The good news is the inelegance is on the surface; the architecture underneath is the most coherent it has been since the prototype started two months ago.

What v0.8 actually is

Two new components, replacing one borrowed dependency:

  • A custom MCP client that calls the Claude API directly, owns the chat UI, and orchestrates tool calls without going through any third-party desktop app
  • A custom MCP server that exposes the SAP 2000 / ETABS OAPI as MCP tools, sized for v0.8 with the validator and pre-flight checks baked in from earlier phases

The reason for the rewrite: the user experience needed to be a single application install, not a stack of tools the engineer has to assemble themselves. v0.8 is the first version where I can imagine handing it to someone, having them double-click an installer, and watching them type a prompt without configuring anything.

The demo build

For v0.8 I wanted a model the prototype could not have built three weeks ago. The result was a multi-tower complex with cable-stayed sky bridges, sweeping Bezier curve tower facades, and suspension elements connecting the upper levels. Five towers, ranging 30 to 80 floors. The full element count:

  • 42,429 distinct structural elements
  • 8,419 nodes
  • 21,752 frame elements
  • 8,667 area elements
  • 304 cables
  • 3,120 tendons

Total wall-clock time from prompt to finished model: under 10 minutes. Manual modeling of the same geometry by a structural engineer would run 30+ hours, conservatively.

The headline accuracy number

First-pass accuracy on a build this complex was around 95%. Most of the model went down on the first attempt; the remaining ~5% was caught by the validator and corrected on retry. The reason this works is the iteration loop is fast — when the LLM is wrong, being wrong is cheap because the validator catches it before any permanent state hits SAP. The pipeline is fast even when the model needs corrections, because the cost of a correction is a few hundred milliseconds rather than a re-build.

That ratio — high first-pass accuracy plus a cheap retry loop — is the architectural bet, and v0.8 is the first version where you can see it pay off on a building this large.

The component-architecture insight

Building something this big surfaced a clear lesson. Today’s MCP tools encourage one-API-call-at-a-time thinking — the LLM picks a method, fills in parameters, calls it, gets a result, picks the next method. For a single column or a single load, that is fine. For 21,752 frame elements, calling them one at a time is like assembling a high-rise with a manual screwdriver.

The architecture I keep wanting is component-based: the LLM should reason about a "tower," a "sky bridge," or a "cable-stayed span" as a unit, then expand it into the underlying OAPI calls in a planned, batched way. Some of that is solvable at the tool-design layer; some of it needs the LLM to be more aggressive about composing higher-level intents before delegating to lower-level tools.

Seeking research collaborations

This is a proof of concept, not a finished product. If you are an engineer, an AI/ML researcher, an LLM-tooling expert, or someone who has spent serious time thinking about how natural language and engineering software should fit together — I would like to talk. The structural-engineering-AI space is small enough that two or three serious people working on this together would meaningfully change the trajectory.

Reality check: this is meaningful progress, not magic. The system creates one specific complex design — it is not yet fully adaptable to arbitrary architectural intent. The work ahead is building the foundation for AI-assisted structural design that understands architectural intent and translates it into engineering reality. That foundation is the bigger project. v0.8 is one step on the way there.

Thanks

Computers and Structures, Inc. — thank you for the cool tools. Anthropic — thank you for the Claude API and for MCP. Both of those, taken together, are what make a custom-client-and-server architecture viable for a project this size.