Abdoulaye Balde & Jacques-Alexis Verrecchia

Designing a hydrogen-electric aircraft means answering questions that cross every tool boundary an engineering team owns. "Can we fly Paris to Geneva, and what does that do to our requirement baseline?" touches a 7.6 GB PostgreSQL database of real flight history, a PyTorch mission simulator, and a requirements SaaS — three systems that share no protocol, no auth model, and no vocabulary. Today the engineer opens all three by hand, and MATLAB models and the PLM are next in line. We built the layer that lets one agent answer instead, and it has been in production at Beyond Aero since July. The unit of composition is the Model Context Protocol server: one use case = one MCP server = N namespaced tool groups, published to a registry, executed through a single gateway, and switched on per user from a catalogue page — with no redeploy. This talk is the architecture and the scars, in equal measure. How a registry (what exists) and a gateway (how you call it) stay consistent when your cloud provider links neither — the namespace is the only rope, and nothing enforces it. Why a cross-region tool target is rejected outright. Why a single 64-character tool name fails the entire model call rather than just that tool. Why tools/list is paginated and what breaks when you ignore that. And what to do when a vendor's own MCP server refuses the handshake over one unimplemented capability method: we ended up authoring theirs, generating 44 read-only tools from their OpenAPI and cutting schema cost from 19.6k to 5.3k tokens. You will leave with a composition model for heterogeneous engineering tooling, the failure modes we hit in production with dates and measurements attached, and the three things we would wire differently.