Why CLI-first, not MCP-first?

One-sentence answer

sim-cli is CLI-first because engineering simulation is file-based, scriptable, local, artifact-heavy, and long-running — a CLI command surface composes with solver executables, model files, scripts, logs, and checkpoints, and matches how Codex CLI and Claude Code already operate.

The long-form rationale

sim-cli is CLI-first because engineering simulation is file-based, scriptable, local, artifact-heavy, and long-running.

CAE agents need to work with solver executables, model files, Python/Java/journal scripts, shell commands, logs, checkpoints, plots, and artifacts. A CLI command surface composes with all of that and matches how Codex CLI, Claude Code, and other coding agents already operate.

MCP is useful for API-style integrations and remote tool discovery, but a broad MCP surface can add context overhead and wrapper maintenance. For COMSOL, Abaqus, Ansys Workbench, OpenFOAM, LTspice, and similar solvers, sim-cli keeps the source of truth as a small, auditable command loop.

The workflow

Every solver workflow through sim-cli follows the same bounded loop:

check readiness → attach to live session → inspect model state
→ run one bounded CAE step → verify result/state → save checkpoint/artifacts

This is the loop Codex, Claude Code, and other coding agents already know how to drive. The CLI surface is small, the steps are inspectable, and every step produces an artifact a human can review.

What CLI-first means in practice

The agent calls sim check <solver> before doing anything that touches the real solver, so a missing license or missing install is caught up front rather than in the middle of a long run.
The agent calls sim connect to open a bounded, persistent session against a real solver, then sim exec / sim inspect to drive it one bounded step at a time.
Long-running solves don’t block the agent’s reasoning loop — the CLI hands back logs, status, and artifact paths the agent can inspect later.
Skills (.agents/skills, .claude/skills) live on disk where any coding agent harness already loads them; the agent learns solver conventions from the skill instead of from a wrapper protocol.

When MCP makes sense (and when it doesn’t, for CAE)

MCP shines for API-style services with small, stable, type-safe surfaces — a database query tool, a calendar tool, a code-search tool. A CAE solver isn’t that. A CAE solver is a long-running native process that reads and writes large model files on local disk, emits logs and artifacts to a working directory, and has a solver-specific Python / Java / journal scripting language that the agent must learn anyway.

For that shape of problem, a CLI loop is shorter and more auditable than the equivalent MCP surface.