Engineering analysis, agent-delivered.
Open-source MCP servers connecting AI agents to real aerospace tools: aerodynamics, structures, propulsion, and mission design. No approximations. The agent runs the same code you would.
$ claude mcp add --transport http oas https://mcp.lakesideai.dev/oas/mcp [ok] added server "oas" (keycloak: oidc) $ claude # minimize CD at CL=0.5 on a 28 m-span wing, # cap struct mass at 3000 kg, ny=21, nx=3 -> create_surface(name="wing", span=28.0, ...) -> run_optimization(dvs=[twist_cp, thickness_cp, alpha]) run_id : run-20260414T145425-65b0174e converged : yes (28 iters, SLSQP) CD : 0.02213 CL : 0.500 L/D : 22.60 struct_mass: 3000 kg provenance : /oas/runs/.../dag.html
Advanced concepts. Physics-based models. Manual plumbing. Unexplored design space.
Assembling a design study typically means hand-wiring scripts, moving files, and bug-checking glue. Engineers spend more time on plumbing than concepts.
// the shiftOff-the-shelf, scriptable MDAO infrastructure is changing that. Engineers can direct and review concept work instead of wrestling files and configs.
$ mdao --state --concept-design - per-tool python scripts; setup takes hours - analysis loops hand-written, brittle to re-run - provenance ad-hoc if anything - cross-tool composition requires bespoke glue - agents can't author; engineers copy-paste examples + plans, not scripts + any tool behind one protocol + every run records a provenance graph + composition is a plan primitive + agents author, diff, and re-run
The Hangar is where these tools live together. Each MDAO tool is defined, tested, and demonstrated in its own package; composition happens through a shared plan format. Every run carries a provenance graph, so engineers lead review instead of chasing files.
One plan. Any tools. One run.
hangar-omd is a YAML-first OpenMDAO plan runner. Describe a trade study or MDO problem once; get a reproducible run with recordings, an N2 diagram, a provenance graph, and plots. Today, components from OAS, OCP, pyCycle, and evt (eVTOL) compose inside one plan.
# brelje 2018a fig 5 headline cell metadata: id: brelje-fuel-mdo name: King Air series-hybrid MDO components: - id: mission type: ocp/FullMission config: aircraft_template: kingair architecture: twin_series_hybrid mission_params: mission_range_NM: 500 battery_specific_energy: 450 design_variables: - name: ac|weights|MTOW lower: 4000.0 upper: 5700.0 units: kg # ...9 more DVs, 16 constraints objective: {name: mixed_objective} optimizer: type: SLSQP options: {maxiter: 150, tol: 1e-6}
A plan describes an OpenMDAO problem without the boilerplate: components, solvers, DVs, constraints, optimizer. Check it into git, re-run it anywhere, diff it against a prior version. The same plan is agent-authorable and human-readable.
- cross-tool composeOCP mission + OAS VLM drag + pyCycle surrogate propulsion + evt eVTOL sizing in one plan
- native gradientsthe evt/Sizing factory closes MTOW with a Newton solver and analytic complex-step partials — not a finite-differenced black box
- lane patternsame math three ways: direct Python (A), plan YAML (B), agent-interactive (C)
- provenance by defaultPROV-Agent graph, OpenMDAO recorder .sql, N2 HTML, decisions log
- plots ship with factoriesplanform / lift / von-mises for OAS; station properties for pyCycle; segment energy / mass breakdown for evt
- export to Pythonomd-cli export emits a standalone OpenMDAO script for deep debugging
$ omd-cli run plan.yaml --mode optimize $ omd-cli plot <run_id> --type all $ omd-cli provenance brelje-fuel-mdo --format html
Five servers. One protocol. One endpoint each.
Four wrap a proven open-source analysis tool built on OpenMDAO; omd composes them into one OpenMDAO problem. Tool calls return structured envelopes with physics validation, artifact references, and a run_id for provenance.
Aerostructural analysis and optimization of lifting surfaces. Couples vortex-lattice aerodynamics with finite-element structures for wing planform design and trade studies.
Aircraft conceptual design and mission analysis. Fuel burn, takeoff performance, and battery state-of-charge across full flight profiles for conventional and hybrid-electric architectures.
Gas turbine engine cycle analysis. Design-point sizing and off-design performance with full thermodynamic station modeling. Turbojet today; HBTF, turboshaft, afterburning, and mixed-flow turbofan archetypes in progress.
Electric-VTOL sizing and mission-energy analysis. Converges MTOW and resolves per-segment energy, power, and a full mass breakdown across hover, transition, and cruise for distributed-electric lift+cruise architectures. Composes into omd as a native, gradient-capable OpenMDAO formulation.
General-purpose OpenMDAO plan runner and composition layer. Authors and runs YAML optimization plans through a factory registry, wiring OAS, OCP, pyCycle, and evt components into one multidisciplinary problem with a full provenance graph, N2 diagram, and plots.
Add the servers to your agent.
One command per server. First connection triggers Keycloak OIDC in the browser.
$ claude mcp add --transport http oas https://mcp.lakesideai.dev/oas/mcp $ claude mcp add --transport http ocp https://mcp.lakesideai.dev/ocp/mcp $ claude mcp add --transport http pyc https://mcp.lakesideai.dev/pyc/mcp $ claude mcp add --transport http evt https://mcp.lakesideai.dev/evt/mcp $ claude mcp add --transport http omd https://mcp.lakesideai.dev/omd/mcp
# claude.ai -> settings -> integrations -> add mcp server # paste the endpoint URL for each tool: https://mcp.lakesideai.dev/oas/mcp https://mcp.lakesideai.dev/ocp/mcp https://mcp.lakesideai.dev/pyc/mcp https://mcp.lakesideai.dev/evt/mcp https://mcp.lakesideai.dev/omd/mcp # sign in when redirected to Keycloak
$ codex mcp add oas --url https://mcp.lakesideai.dev/oas/mcp $ codex mcp add ocp --url https://mcp.lakesideai.dev/ocp/mcp $ codex mcp add pyc --url https://mcp.lakesideai.dev/pyc/mcp $ codex mcp add evt --url https://mcp.lakesideai.dev/evt/mcp $ codex mcp add omd --url https://mcp.lakesideai.dev/omd/mcp # authenticate each server $ codex mcp login oas --scopes mcp:tools $ codex mcp login ocp --scopes mcp:tools $ codex mcp login pyc --scopes mcp:tools $ codex mcp login evt --scopes mcp:tools $ codex mcp login omd --scopes mcp:tools
omd-cli.What the hangar is.
The Hangar wraps established aerospace tools as MCP servers so AI agents can call them directly. Agents compute aerodynamic coefficients, structural loads, fuel burn, engine performance, and full mission profiles using the same code an engineer would run locally.
##the problem
Tools like OpenAeroStruct, OpenConcept, and pyCycle are capable but slow to wield. Building OpenMDAO problems, defining meshes, connecting subsystems, setting solver options, and extracting results takes domain fluency and hours per iteration. Early-stage design exploration is expensive when it should be cheap.
##what mcp gives us
MCP (Model Context Protocol) is an open standard for exposing tools to AI applications with structured input and output. The Hangar uses it to present each analysis tool as a set of callable MCP operations with input validation, physics checks, and versioned result envelopes.
##what an agent can do
- explore design space: "fuel burn vs aspect ratio from 9 to 14". Agent creates the surface, runs analyses at each AR, reports the trend.
- compare architectures: "turboprop vs series-hybrid, 500 nmi regional mission". Computed, not estimated.
- size an eVTOL: "converge MTOW for a lift+cruise eVTOL over a 45 mi mission". evt resolves per-segment energy, peak power, and the mass breakdown.
- compose across tools: size an engine with pyCycle, feed TSFC into an OCP mission, optimize the wing with OAS.
- optimize with gradients: define DVs, set constraints, run SNOPT or SLSQP, interpret convergence.
##what you get back
Every tool call returns a versioned envelope: results, physics validation (convergence, bounds, sanity checks), telemetry, and a run_id for provenance. Every run produces an N2 diagram, an OpenMDAO recorder .sql, and a PROV-Agent graph entry. The agent handles setup boilerplate. You stay on the engineering.
Reproducing peer-reviewed MDAO.
End-to-end engineering workflows executed by agents through The Hangar. Each study ships with plots, provenance graph, N2 diagram, and the decisions log.
CD +---+---+---+---+---+ | | | oooo | | oo | | oo | | oo | | oooo | +---+---+---+---+---+ 0 7 14 21 28 iter converged L/D=22.6 m=3000kg
Regional 28m wing optimization
Aerostructural CD-min for an E190-class wing with a structural-mass cap. 28 SLSQP iterations, CL=0.500, L/D=22.6, struct_mass=3000 kg.
Brelje 2018a figs 5 & 6 reproduction
King Air twin series-hybrid MDO over range x battery specific energy. Fuel and cost objectives, 5x5 grid run end-to-end through the omd Lane B plan pipeline. Matches paper trends across both objectives.
oas/vlm drag --+ +-- ocp mission --> fuel pyc/hbtf prop --+ B737-800 one omd plan, three tools Lane A == Lane B to 0.1%
Three-tool mission composition
A B737-800 mission where OpenConcept's parabolic drag polar is swapped for an OpenAeroStruct VLM model and its turbofan for a pyCycle HBTF engine — three physics tools wired into one omd plan. The direct-Python lane and the YAML plan lane agree on mission fuel burn to 0.1%. MTOW 79,002 kg, OEW 41,871 kg.
eVTOL fleet sizing — AIAA SciTech 2026
Reproduces the non-ABU tables of Nguyen et al. (AIAA SciTech 2026): three production-class eVTOLs — Archer Midnight, Joby S4, Supernal S-A2 — across 2 cruise altitudes and 3 ranges (18 cases). Mission energy matches the paper to ≤0.01%; three lanes (direct evtolpy, hangar-evt tools, agent study) agree to floating-point round-off.
MTOW +---+---+---+---+---+ kg |o | | oo | | ooo | | ooo | | oooooooo | +---+---+---+---+---+ 0 5 10 15 20 iter sized 2019.5kg dMTOW/dpayload OK
Gradient-capable eVTOL sizing
Sizes an Archer Midnight lift+cruise eVTOL through evt's native OpenMDAO formulation: a Newton MTOW closure with analytic complex-step partials. d(MTOW)/d(payload) validated against finite difference. Sized MTOW 2019.5 kg, 65.95 kW·hr, 846.5 kW peak — same answer three ways (Python / plan / agent).
Cite the original work.
The Hangar wraps these open-source projects. If you use them in published work, cite the original authors.
Add your tool today.
The Hangar supports new analysis tools beyond the initial three. The SDK provides shared infrastructure for response envelopes, provenance tracking, validation, and artifact storage, so you can focus on the tool-specific logic.
Check the issues and discussions to see what's being considered, propose new ones, or pick up an existing request.