Roadway Design Compiler

Inspiration

Roadway design has an unusually clear line of authority: a licensed Professional Engineer reviews, approves, and seals the work and carries personal legal responsibility for it. An agent can calculate geometry, generate alternatives, and prepare deliverables, but it cannot inherit that accountability.

That made roadway engineering a strong test for WebMCP. The question was not simply “how much can the agent do?” It was: how can a website let an agent do real engineering work right up to, but never past, the point where a qualified human must decide?

What it does

Roadway Design Compiler is an agent-native conceptual roadway design studio with 39 WebMCP tools. From a supported agent, a user can ask the site to:

read an existing design, alignment limits, curve and profile tables, cross sections, superelevation, terrain, and roadside quantities;
author horizontal geometry, vertical profiles, cross-section templates, materials, template drops, coordinate systems, superelevation, and roadside items;
import LandXML alignments, surfaces, site features, and as-designed reference sections;
check configurable design criteria and propose multiple alternatives;
create portable share links and prepare LandXML or construction-staking CSV deliverables.

The key is the safety boundary. Every agent-applied change is stamped agent-proposed and enters a visible change ledger. While any proposal is unconfirmed, the site refuses both LandXML and staking exports. There is deliberately no WebMCP tool that can clear that gate. A person must review and confirm the change in the UI.

This is conceptual design tooling, not construction software. The built-in criteria defaults are illustrative rather than an adopted agency standard, and every design still requires review and sealing by a licensed Professional Engineer.

Why WebMCP is the right fit

Traditional browser automation can manipulate fields, but it does not give an agent a trustworthy engineering contract. WebMCP lets the site expose typed, domain-specific actions and explicit refusal states. The agent chooses what to ask for; a deterministic engineering kernel decides what is geometrically and mathematically true; the human retains authority over adoption and export.

That division creates a better experience for both sides:

The agent can inspect the complete design instead of guessing from pixels or scraping a complex interface.
It can preview a change, explain consequences, and request a commit through a typed tool.
The user sees the exact proposal and its provenance in the same UI used for manual design.
Safety does not depend on a prompt. The site itself enforces the confirmation and export rules.

People and agents can now collaborate on a complete roadway concept—geometry, profile, corridor, criteria, terrain, alternatives, and interoperable deliverables—without pretending that the agent can take the engineer's legal role.

How we built it

Prior work and hackathon additions

Roadway Design Compiler is an existing project that we meaningfully extended with WebMCP during the submission period (August 25–September 3, 2026). Before this period, it included a deterministic roadway geometry kernel, the RoadDesign schema and validation, a form-based Studio, LandXML export, and initial RoadBench benchmark tests. It had no agent interface.

During the submission period, we built all 39 WebMCP tools and their registration bridge, preview-and-commit workflows, structured refusals, the agent activity log, and the agent-proposed change ledger with its human confirmation gate. We also added design alternatives, undo for unconfirmed changes, portable design documents, LandXML import, terrain and reference-section visualization, pavement and roadside authoring, coordinate-system support, and construction-staking CSV export.

Only work added during the submission period is offered for evaluation. Our repository's prior-work breakdown and dated commit history document the distinction between the existing foundation and the hackathon additions.

The application is TypeScript end to end. It registers 39 tools through document.modelContext.registerTool and validates their inputs and the cross-field design document with Zod. Tool execution returns typed results and typed refusals, while an agent activity log records calls from inside the WebMCP execute path so judges can distinguish real tool use from DOM automation.

The authoritative geometry layer is a pure deterministic kernel for horizontal alignment, vertical curves, corridor sections, design criteria, superelevation, and terrain sampling. No model sits in that path. A Three.js view renders the authored corridor and imported ground; plan, profile, curve, and section views provide inspectable engineering outputs.

The LandXML 1.1/1.2 importer handles alignments, TIN surfaces, site features, and reference sections. It computes geometry from coordinates instead of trusting inconsistent direction metadata, refuses unsupported spirals rather than approximating them, and pre-scans very large files before building a DOM. Before the hackathon, the exporter had been round-tripped into Bentley OpenRoads Designer as a native alignment and profile; Bentley's own annotation reproduced the curve table to 0.01 ft.

The app runs on Vite and is deployed on Cloudflare. The repository includes 525 automated tests plus driver-owned browser harnesses for WebMCP registration, preview isolation, refusal→solve→commit workflows, superelevation, sealing gates, import, terrain, persistence, share links, and live deployment verification.

Challenges we faced

Drawing a boundary that code can actually enforce

A warning in a system prompt was not enough. The difficult part was making preview, commit, provenance, confirmation, undo, and export operate as one coherent transaction model. The safest capability is sometimes an intentional omission: there is no agent tool for human confirmation.

Handling real-world LandXML without fabricating data

Public LandXML files vary widely. Some direction values are radians, others are degrees, and many do not say which. Some files contain hundreds of thousands of surface elements but no usable alignment. Spirals appear frequently, but this kernel does not model them yet. We chose explicit refusals over silent approximation, because a wrong road that looks plausible is more dangerous than a clear error.

Keeping engineering truth deterministic

The agent should decide what question to ask, not what the answer should be. Geometry, stopping-sight-distance relationships, K values, superelevation, runoff, cut/fill sign conventions, and export contents are computed by tested code with every coefficient disclosed as an input.

What we learned

WebMCP is most powerful when a tool description is not just an API hint but a declaration of responsibility. Typed refusals, preview-only execution, and site-enforced authority boundaries make agent behavior easier to understand and audit. We also learned that imported context must preserve provenance: existing survey features, terrain, and another designer's sections should remain clearly distinguishable from the active design.

Accomplishments we are proud of

A complete human/agent roadway workflow across 39 tools.
A hard, demonstrable export gate that an agent cannot bypass.
525 automated tests and a live activity log proving WebMCP execution.
Interoperable LandXML validated in production roadway-design software before the hackathon, providing the foundation for the new WebMCP export workflow.
Fast indexed terrain sampling, portable no-account design links, and explicit refusals for unsupported or unsafe cases.

What's next

Next steps include clothoid spiral support, end-area earthwork volumes, agency-specific criteria packs supplied by the user, broader LandXML interoperability fixtures, collaborative review, and additional CAD round-trip validation.

Live app: https://roadway-design-compiler.gandidhyaneswar.workers.dev/

Source: https://github.com/Dhyaneswar/roadway-design-compiler