DEV Community: Mlight Lee

Letting AI Write Code Against Your Drawings: The mlightcad MCP Server

Mlight Lee — Sun, 25 Oct 2026 09:18:59 +0000

Stop teaching AI 100 CAD tools. Give it a scripting API and let it figure things out.

A few weeks ago, I published Building a CAD Agent: MCP, Tools, or Let AI Write Code?.

The basic argument was simple:

For complex software like CAD, giving AI a scripting API is often better than giving it a shopping list of tools.

Think about it.

If you want an AI agent to work with a CAD drawing, you could give it tools like:

draw_line
draw_circle
query_entities
set_entity_layer
delete_entity

Sounds reasonable, right?

Until someone asks:

"Find all circles near standard bolt-hole sizes, ignore reference layers, group them by component, flag unusual ones, and generate a report."

Oops. Looks like we need another tool.

And another.

At some point, your MCP server starts looking like a restaurant menu with 500 dishes. The AI is still hungry, and you're still adding pages.

So we tried something different.

mlightcad, our open-source browser-based CAD viewer, now supports the Model Context Protocol through @mlightcad/cad-mcp-server.

Instead of exposing every CAD operation as a separate tool, we give the agent a scripting API and let it write JavaScript to perform the actual work.

And then we tested it on three real drawing-processing tasks:

Extracting a BOM from a table drawn entirely with lines and text.
Extracting information from a drawing frame and title block.
Splitting a drawing containing multiple framed sheets into independent DXF files.

All three worked.

Let's see how.

1. The architecture: One brain, multiple ways to use it

The first thing we wanted to avoid was building three separate AI implementations.

One for the in-app chat agent.

One for MCP.

And another one for whatever integration comes next.

That would be a great way to create three bugs for every bug we fix.

Instead, mlightcad uses a shared agent core.

The architecture has three main parts.

`@mlightcad/cad-agent-core` — The engine

This is where the actual CAD intelligence lives.

It provides two capabilities.

1. A scripting environment

The agent can execute JavaScript against a live CAD drawing.

The script receives a single argument:

cad

Think of it as handing the AI a workbench.

It can inspect the drawing:

cad.drawing
cad.entities
cad.tables
cad.blocks
cad.selection

It can measure geometry:

cad.measure

It can edit the drawing:

cad.edit.transaction

And it can save the result:

cad.file.saveDxf

For example, the agent can inspect entities, query layers, find objects inside a bounding box, measure distances, or modify geometry.

It doesn't need a separate MCP tool for every operation.

It just needs to know how to use the API.

Of course, letting an AI execute arbitrary JavaScript inside a CAD application sounds like an excellent way to spend your weekend debugging security problems.

So the scripts run inside a sandbox.

The validator restricts the available API. Scripts cannot import arbitrary modules or access the browser page.

The model gets access to the CAD workbench, not the entire house.

The complete API is documented here:

mlightcad Script API

2. A tool interface

The core also provides a tool catalog.

Currently, it contains exactly one tool:

execute_cad_script

The script runs inside the CAD environment.

If it produces a DXF file or a preview image, the core can attach those results to the tool response.

The important detail is that the model doesn't need to receive the entire drawing or the complete contents of the exported file.

It can receive a summary and file metadata instead.

We'll come back to why that matters.

`@mlightcad/cad-agent-plugin` — The in-app agent

This is the agent users interact with inside cad-viewer and cad-simple-viewer.

It registers the agent chat command and lets users describe drawing tasks in natural language.

The plugin uses the same core.

So the in-app agent and the script panel share the same underlying capabilities.

No separate implementation required.

`@mlightcad/cad-mcp-server` — MCP for external agents

This is the part that lets other AI applications work with mlightcad.

It supports MCP clients such as:

Claude Code
Claude Desktop
Cursor
Codex
Other compatible MCP clients

The server uses stdio and launches Chromium through Playwright when the first tool call arrives.

It runs the same cad-simple-viewer kernel used by our products.

The browser session persists across tool calls.

In headless mode, it automatically closes after an idle timeout. In visible mode, you can watch the agent manipulate the drawing.

The server exposes two tools:

Tool	What it does
`open_drawing`	Opens a local or remote DXF/DWG file, or starts with a blank ISO template
`execute_cad_script`	Executes JavaScript against the current drawing

That's it.

One tool to open the drawing.

One tool to do the actual work.

WebMCP — The next frontend

We also plan to support WebMCP.

Because the MCP tool registration is already separated into a reusable registerCadMcpTools() function, a future WebMCP host can register the same tools inside a browser environment that already owns the CAD document manager.

No need to launch another Chromium instance.

Same core. Same tools. Another frontend.

That's the advantage of this architecture: new capabilities are implemented once and become available to every frontend.

2. Why scripts beat a pile of MCP tools

Let's get back to the original question.

Why not simply expose every CAD operation as an MCP tool?

Because CAD is not a small collection of predictable operations.

It's a programming environment.

Users can combine geometry, layers, blocks, text, measurements, and editing operations in almost unlimited ways.

Trying to anticipate every possible workflow is a losing game.

The tool-sprawl problem

Imagine we start with 20 tools.

Then users ask for:

Finding circles with specific radii.
Grouping entities by layer.
Comparing dimensions.
Extracting text from a particular region.
Finding duplicate geometry.
Exporting selected entities.

We add more tools.

Then someone asks:

"Find all circles smaller than 5, group them by layer, and report their IDs and radii."

Do we create:

find_small_circles_grouped_by_layer_and_report_radius?

Hopefully not.

The problem is that every new workflow becomes another API design and implementation task.

And the more tools we expose, the more information the model has to process before it even starts working.

The scripting alternative

Instead of teaching the AI every possible combination, we let it combine existing capabilities.

For example:

// Find circles smaller than radius 5,
// grouped by layer.

const results = cad.entities
  .where(
    e =>
      e.type === 'Circle' &&
      e.geometry.radius < 5
  )
  .map(e => ({
    handle: e.id,
    layer: e.layer,
    r: e.geometry.radius
  }))

return results

That's the entire workflow.

The model writes the logic.

The CAD environment executes it.

And the result comes back as structured data.

No special-purpose tool required.

Three advantages that matter more than they first appear

1. Fewer tokens

Suppose a drawing contains 100,000 entities.

If the agent has to inspect them individually through tool calls, things get expensive very quickly.

With scripting, the filtering and processing happen inside the CAD environment.

The model receives only the relevant results.

Instead of shipping 100,000 entities back and forth, we can return a small JSON summary.

The drawing stays where it belongs.

The model gets the information it actually needs.

2. Easier verification

AI-generated code can make mistakes.

That's not exactly breaking news.

But scripts can check their own results.

For example:

return cad.measure.report([
  cad.measure.check(
    'radius',
    100,
    cad.measure.radius(id)
  )
])

The agent can perform an operation, inspect the result, and verify whether the expected conditions hold.

We can also separate read-only analysis from drawing modifications.

This makes it easier to build workflows that are not just intelligent, but reasonably trustworthy.

3. Faster execution

Loops, filtering, and batch edits execute inside the CAD environment.

The model doesn't need to make a new tool call for every entity.

Think of the difference between asking someone to inspect 10,000 objects one by one and giving them a program that checks all 10,000 objects in one pass.

Let the model decide what to do.

Let the program do the repetitive work.

So, is MCP still useful?

Absolutely.

MCP is still the connection between the AI agent and external software.

Explicit tools are still useful for lifecycle operations, such as opening a drawing.

Scripts are useful for combining CAD capabilities into custom workflows.

That's why our MCP server has two tools:

One handles the drawing lifecycle.

The other handles everything the agent wants to do with the drawing.

3. Getting started with the mlightcad MCP server

Let's make this practical.

You need:

Node.js 20 or later.
A Playwright Chromium installation.

Install the browser using:

pnpm --filter @mlightcad/cad-mcp-server install-browser

Claude Code / Claude Desktop

Add the following configuration to your MCP settings:

{
  "mcpServers": {
    "cad": {
      "command": "npx",
      "args": [
        "-y",
        "--package=@mlightcad/cad-mcp-server@1.7.8-preview.1",
        "cad-mcp-server"
      ]
    }
  }
}

Cursor

The configuration is essentially the same:

{
  "mcpServers": {
    "cad": {
      "command": "npx",
      "args": [
        "-y",
        "--package=@mlightcad/cad-mcp-server@1.7.8-preview.1",
        "cad-mcp-server"
      ]
    }
  }
}

Inside the mlightcad monorepo, use the bundled scripts/run-published.mjs launcher instead of raw npx.

See the MCP server README for details.

A couple of useful environment variables

Variable	Purpose
`CAD_MCP_VISIBLE=1`	Show a visible Chromium window by default
`CAD_MCP_IDLE_CLOSE_MS`	Configure the headless idle timeout; default is 30,000 ms

The typical workflow

Every task follows the same basic pattern.

Step 1: Open a drawing

Call open_drawing:

{
  "path": "./plan.dxf",
  "mode": "write"
}

You can also pass an HTTP or HTTPS URL.

If you want to watch the agent work:

{
  "path": "./plan.dxf",
  "mode": "write",
  "visible": true
}

Step 2: Execute a script

Here's a small example.

Let's draw a circle with a radius of 100 and verify that it was created correctly.

let id

cad.edit.transaction('circle', tx => {
  id = tx.drawCircle({
    center: { x: 0, y: 0 },
    radius: 100
  })
})

cad.view.zoomExtents()

return cad.measure.report([
  cad.measure.check(
    'radius',
    100,
    cad.measure.radius(id)
  )
])

The script creates the circle, adjusts the view, and checks the radius.

One call.

No draw_circle tool.

No measure_circle tool.

No verify_circle tool.

Just the scripting API.

Saving the result

To save the drawing:

cad.file.saveDxf('./plan-out.dxf')

The MCP server writes the file and returns metadata such as its path and size.

The DXF contents are not sent back to the model.

This is important when working with large drawings.

You don't want the model to spend its context window reading a file it just created.

You want it to know the file exists and whether the operation succeeded.

You can also capture a preview:

cad.view.capturePreview()

The result can be attached as an image to the MCP response.

So the agent can inspect the drawing visually when necessary.

That's the basic workflow.

Open the drawing.

Write a script.

Execute it.

Check the result.

4. Three real experiments

Now for the interesting part.

I tested the MCP server on three drawing-processing tasks.

These weren't three custom tools built specifically for the examples.

They used the same two-tool MCP server and the existing CAD scripting API.

The agent had to figure out how to combine the available capabilities.

4.1 Turning a line-drawn BOM into a Markdown table

The task

In CAD, a table doesn't necessarily exist as a table object.

Sometimes it's just a collection of lines and text.

To a human, it looks like this:

Item	Part No	Description	Qty	Material
1	GP-001	Housing	1	HT250
2	GP-002	Cover	1	HT250
3	GP-003	Shaft	1	45 Steel
4	GP-004	Bolt M8×30	4	8.8
5	GP-005	Base Plate	1	HT200

To software, however, it's a bunch of geometry.

There may be lines forming the grid, text inside each cell, and numbered balloons connecting the BOM to the assembly.

I used a mechanical assembly drawing of a gear pump.

The assembly view occupied most of the sheet, while the BOM sat above the title block.

The task was simple:

Extract the BOM and return it as a Markdown table.

How the agent solved it

There was no extract_bom tool.

The agent wrote a short script to reconstruct the table.

First, it collected text entities:

const texts = cad.entities
  .where(e =>
    ['Text', 'MText', 'Attribute']
      .includes(e.type)
  )
  .map(e => ({
    text: e.geometry.text,
    pos: e.geometry.position
  }))

Next, it grouped text by approximate Y coordinates.

Entities on the same horizontal row should have similar Y values.

const rows = new Map()

for (const t of texts) {
  const key = Math.round(t.pos.y / 10)

  if (!rows.has(key)) {
    rows.set(key, [])
  }

  rows.get(key).push(t)
}

Then it sorted the rows from top to bottom and the text within each row from left to right:

return [...rows.values()]
  .sort(
    (a, b) =>
      b[0].pos.y - a[0].pos.y
  )
  .map(row =>
    row
      .sort(
        (a, b) =>
          a.pos.x - b.pos.x
      )
      .map(t => t.text)
  )

Finally, the script returned structured rows.

The model converted those rows into Markdown.

The result

The BOM was reconstructed as a Markdown table.

The interesting part wasn't that the AI could read text.

It was that the AI figured out how to reconstruct a table that didn't exist as a table object.

The grouping rules were generated on the fly.

If the row spacing or column arrangement was different, the agent could adjust the script and run it again.

Nobody on the development team had to anticipate that particular table layout.

And only the extracted data was returned to the model.

The drawing itself stayed inside the CAD environment.

That's the flexibility we were looking for.

4.2 Reading a drawing frame from top to bottom

The task

Production drawings usually contain a frame and title block.

The title block may contain:

Project name.
Drawing title.
Drawn-by and checked-by information.
Scale.
Date.
Sheet number.
Revision.

Humans can read this information easily.

But to a CAD program, it's just a collection of entities.

I asked the agent to extract all the information from the drawing frame and organize it into a structured record.

How the agent solved it

The script followed three steps.

First, locate the frame.

For this drawing, the agent used the largest closed polyline as the frame.

const frame = cad.entities
  .where(
    e =>
      e.type === 'Polyline' &&
      e.geometry.closed
  )
  .sort(
    (a, b) =>
      (b.extents.max.x - b.extents.min.x) *
      (b.extents.max.y - b.extents.min.y) -
      (a.extents.max.x - a.extents.min.x) *
      (a.extents.max.y - a.extents.min.y)
  )[0]

Second, collect the entities inside the frame.

The API provides inBox() for this:

return cad.entities
  .inBox(
    frame.extents.min,
    frame.extents.max
  )
  .filter(
    e =>
      ['Text', 'MText', 'Attribute']
        .includes(e.type)
  )
  .map(e => e.geometry.text)

Block attributes are included automatically.

That means title blocks built from attributed block inserts can be processed without special handling.

Third, the model organizes the extracted text into a structured object.

The result

{
  "project": "PUMP STATION UPGRADE",
  "title": "PUMP DISCHARGE PIPING",
  "drawnBy": "J. Chen",
  "checkedBy": "L. Wang",
  "scale": "1:50",
  "date": "2026-10-12",
  "sheetNo": "A-102",
  "rev": "B"
}

The drawing geometry was never modified.

This was a read-only operation.

And because the output is structured JSON, it can go directly into a document-management database, search index, or CSV export.

No need to manually read title blocks anymore.

At least, not for this workflow.

4.3 Splitting a multi-sheet drawing into separate DXF files

The task

Some drawings contain multiple independent sheets inside one file.

For example, a drawing might contain three framed sheets arranged side by side.

I asked the agent to:

Find each frame.
Keep the entities belonging to that frame.
Remove everything else.
Export the remaining drawing as an independent DXF.

In other words, turn one drawing into several drawings.

How the agent solved it

This time, the task involved editing the drawing.

The agent used cad.edit.transaction to group the changes into one undoable operation.

First, it located the frames:

const frames = cad.entities
  .where(
    e =>
      e.type === 'Polyline' &&
      e.geometry.closed
  )

Then it selected the second frame as an example:

const box = frames[1].extents

Next, it collected the entities inside the frame:

const inside = cad.entities
  .inBox(box.min, box.max)
  .map(e => e.id)

And identified everything outside:

const outside = cad.entities
  .where(
    e => !inside.includes(e.id)
  )
  .map(e => e.id)

Finally, it removed the unwanted entities and saved the result:

cad.edit.transaction(
  'isolate sheet 2',
  tx => {
    tx.erase(outside)
  }
)

cad.file.saveDxf('./sheet-02.dxf')

return {
  kept: inside.length,
  removed: outside.length
}

The agent then reopened the original drawing and repeated the process for the other frames.

Why reopen the original?

Because we don't want the second export to start from an already modified drawing.

Each sheet should be extracted from the pristine source.

The result

The agent produced:

sheet-01.dxf
sheet-02.dxf
sheet-03.dxf

Each file contained one frame and its associated entities.

The MCP server returned file metadata, including paths and sizes.

The agent could verify that all three exports were non-empty before reporting success.

The entire workflow was assembled from existing API operations.

No one had to write a dedicated multi-sheet splitting tool.

The agent combined entity queries, bounding boxes, transactions, and DXF export into a batch-processing workflow.

That's a pretty useful capability for something we didn't explicitly program as a feature.

5. What can you actually do with this?

The three experiments demonstrate something broader than extracting a BOM.

Once the agent can query, analyze, edit, and export CAD data through scripts, many drawing-processing tasks become combinations of existing capabilities.

Here are some examples.

Information extraction

Extract information from:

BOMs.
Title blocks.
Schedules.
Legends.
Notes.

If the information is represented by text and geometry, the agent can often reconstruct its structure.

Drawing analysis

Generate reports such as:

Entity counts by layer.
Duplicate or overlapping geometry.
Dimension checks.
Unusual geometry.
Drawing statistics.

The model can write scripts that inspect the drawing and return structured results.

Batch editing

Perform operations such as:

Renaming layers.
Moving groups of entities.
Fixing linetypes.
Inserting standard blocks.

Instead of editing entities one at a time, the agent can execute a batch script.

File processing

Automate tasks such as:

Splitting drawings by frame.
Merging sheets.
Converting drawings.
Exporting independent DXF files.

Visual verification

The agent can open a visible browser window and let you watch the drawing being manipulated.

It can also capture a preview image for inspection.

The point is not that every task will work perfectly on the first attempt.

The point is that the agent can compose existing capabilities into workflows that developers never explicitly implemented.

And when the API gets better, the agent gets better too.

Every new method added to cad-agent-core becomes available to the in-app agent, the MCP server, and the planned WebMCP host.

No need to build a new tool for every new idea.

6. The bigger picture: Give AI a workbench, not a menu

We started with a familiar question:

What tools should I expose so AI can use my software?

Our answer is becoming a little different.

Instead of trying to enumerate every possible operation, give AI a documented scripting API, a controlled execution environment, and a small number of tools for connecting to the application.

In mlightcad, that means:

A shared agent core.
A sandboxed JavaScript API.
One tool for opening drawings.
One tool for executing scripts.
Structured results and optional visual previews.

The agent can inspect a drawing, generate code, execute it, verify the result, and save the output.

And developers don't need to anticipate every possible combination of CAD operations.

We still need explicit tools.

We still need MCP.

But we don't need to turn every CAD API method into a separate tool.

Sometimes the best interface for AI isn't a bigger toolbox.

It's a workbench where the AI can write its own instructions.

Try it yourself

The mlightcad MCP server is available here:

Repository: github.com/mlightcad/cad-viewer
MCP server on npm: @mlightcad/cad-mcp-server
Script API documentation: mlightcad Script API
The original design discussion: Building a CAD Agent: MCP, Tools, or Let AI Write Code?

The MCP server currently uses the preview package version 1.7.8-preview.1.

If you're building an AI agent for CAD, I'd be interested to hear how you're approaching the interface.

Are you building a tool for every operation?

Or are you giving the agent a scripting environment and letting it compose the operations itself?

Because in our experience, the second approach gets interesting very quickly.

And it saves us from maintaining a 500-item tool menu.

Which, frankly, is a feature I don't think anyone wants to use.

Building a CAD Agent: MCP, Tools, or Let AI Write Code?

Mlight Lee — Sun, 18 Oct 2026 14:31:47 +0000

If you were building a CAD agent, how would you do it?

The most obvious approach is to wrap CAD APIs as tools and expose them to AI through MCP.

Need to draw a line? Give it a drawLine tool.

Need to create a circle? Add createCircle.

Need to change an entity's layer? Here comes setEntityLayer.

Not enough functionality? Just keep adding tools.

Everything sounds fine until you've built 500 tools and users can still find a hundred things your agent can't do.

Congratulations! You might not be building a CAD agent anymore. You might be building an entirely new CAD API product just for AI.

Okay, that's a bit of an exaggeration. But as coding agents like Codex, Claude Code, and Cursor continue to evolve, I've started thinking seriously about a different approach:

Instead of teaching AI to call hundreds of tools, why not let it write code to operate CAD directly?

1. What's changed in AI agents over the past six months?

In the past, if you asked an AI to fix a bug, the typical workflow was to read the code, figure out what might be wrong, and modify the implementation.

Modern coding agents increasingly take a different approach.

Can't figure out a bug? Write a script to analyze the logs.

Can't reproduce the issue? Write a test program.

Suspect a variable contains the wrong value? Add some debugging code and inspect what actually happens at runtime.

Fixed the bug? Run the tests again to make sure it's really fixed.

AI is no longer just reading and generating code. It's increasingly using code as a tool for solving problems.

That's an important shift.

We used to ask: How can we teach AI to call the capabilities our software provides?

Now we can ask a different question: Can we let AI write programs that combine those capabilities to solve problems on its own?

For complex software like CAD, I think this is a direction worth taking seriously.

2. Can a collection of tools really cover everything?

Imagine a user asks:

Find all circles whose diameters are close to standard bolt-hole sizes, exclude objects on reference layers, group the results by component, identify outliers, and generate a report.

We could provide a collection of tools:

Query entities and retrieve their properties.
Inspect block references and layer information.
Create selection sets and modify entities.
Calculate geometric relationships and measure distances.
Create annotations and export reports.

But what happens when the existing tools don't support the user's particular classification rules?

Build another tool?

And when the user wants to classify components by mounting position instead?

Another tool?

What if they want to compare suspicious holes against a second drawing?

You can probably see where this is going.

The development cycle becomes familiar: users request new capabilities, developers build new tools, and users immediately come up with requirements that those tools don't cover.

Eventually, the tool catalog grows, but the agent's ability to handle unexpected tasks hasn't improved nearly as much as we'd hoped.

To be clear, MCP isn't the problem. It provides a standardized way for AI applications to discover and invoke external capabilities.

The real question is this:

Does every capability of a complex application need to be wrapped as a separate AI tool?

3. Why not let AI write code directly?

Let's try a different approach.

Suppose our CAD application provides a JavaScript or Python scripting environment, with APIs for accessing the drawing database, querying entities, performing geometric operations, and modifying properties.

Instead of calling tools one by one, the AI writes a script.

For example, to find all circles with a radius smaller than 5:

const circles = cad.getEntities({
  type: "CIRCLE"
});

const results = circles.filter(circle =>
  circle.radius < 5
);

return results.map(circle => ({
  handle: circle.handle,
  radius: circle.radius,
  layer: circle.layer
}));

This is illustrative pseudocode. The actual API depends on the CAD application's implementation.

For such a simple task, ordinary tool calling works perfectly well.

The difference becomes more interesting when the task involves analyzing diameter distributions, identifying likely bolt holes, excluding certain layers, classifying components, and finding dimensions that deviate from common sizes.

The AI can write its own loops, filters, statistical calculations, and classification logic.

The first result looks wrong? Modify the script and run it again.

The drawing contains nested blocks? Adjust the traversal logic.

A particular component uses a special naming convention? Incorporate that rule into the program.

Developers don't have to anticipate every possible requirement, and they don't need to build a dedicated tool for each one.

The software provides the capabilities. The AI writes the logic.

That's what makes scripting so interesting as an interface for AI agents.

4. Three underrated advantages of letting AI write scripts

Flexibility is the obvious benefit. But I think there are three other practical advantages: fewer tokens, easier verification, and potentially faster execution.

4.1. Fewer tokens: Don't make AI inspect 100,000 entities one by one

Imagine a drawing with 100,000 entities. The user wants to find objects that satisfy a particular set of conditions.

With a tool-calling workflow, the agent might repeatedly query entities, retrieve results, analyze them, and decide what to do next. Depending on the API design, large amounts of intermediate data and tool-call history can end up in the model's context.

If the tools aren't designed well, the AI can spend a surprising amount of its token budget just moving information around before it even starts solving the problem.

A script can iterate through the entities, perform calculations, and filter the results directly inside the execution environment. Only the useful findings need to be returned to the model.

Suppose the script finds three suspicious entities among 100,000. The agent may only need to inspect those three entities and a few summary statistics, rather than processing details about all 100,000.

Of course, tools can support batch queries, and scripts consume tokens too. But for data-intensive tasks, letting code process the data while the model focuses on the results is often more economical.

Don't make AI do the manual labor. Let it write a program to do the manual labor.

4.2. Easier verification: Don't just say it worked. Show me the evidence.

Suppose an AI tells you it found 20 suspicious objects.

Are you ready to trust it?

If those objects are part of a mechanical design, perhaps let's not celebrate just yet.

With scripts, we can express verification logic directly in the program.

For example, we can:

Check whether the selected entities satisfy the specified geometric conditions.
Verify that the number of modified entities is reasonable.
Confirm that entity handles are still valid.
Check whether the updated properties match the expected values.
Run assertions or regression tests against important results.

We can also separate analysis from modification. First, run a read-only script that produces a proposed change list. Validate the list, and only then apply the changes.

If the results don't match expectations, the agent can inspect error messages and intermediate data, modify the script, and try again.

There's another advantage: verified scripts can be saved and reused. For recurring drawing-inspection tasks, they can gradually become a library of reusable automation rules.

Tool-based workflows can certainly be verified too, but they may require additional mechanisms to validate the results of many separate calls and decisions.

AI is allowed to make mistakes. But it should at least have a way to use code to check whether it's right.

4.3. Faster execution: Fewer meetings, more work

Imagine processing 5,000 entities.

One approach is to let the AI repeatedly call tools, inspect each response, and decide what to do next.

Another is to let the AI write a loop and a set of filtering rules, then execute the whole thing in one go.

Which approach is more likely to be faster?

Usually, the second one.

The reason isn't just that code executes quickly. It's also that the model doesn't need to participate in every individual operation.

Each round of model inference, tool invocation, and result processing can introduce additional latency. When a task requires dozens or hundreds of sequential interactions, the overhead adds up.

Loops, conditionals, geometric calculations, and batch operations can instead run directly in the execution environment.

Of course, if the task is simply to draw one line, calling a dedicated tool may be simpler and faster. There's no need to write an entire automation program just to draw a line.

Scripting becomes particularly attractive when tasks involve large datasets, complex logic, or repeated calculations.

Let the model think and let the program execute. Don't make an expensive brain spend its time deciding whether every single circle deserves to be selected.

5. Does this mean MCP and tools are obsolete?

Of course not.

I don't think future software agents should abandon MCP or tools. They solve different problems.

MCP is useful for connecting external systems and exposing remote capabilities through a standardized interface.
Tools are useful for clearly defined operations, such as opening a drawing, exporting a file, or requesting user approval.
Scripts are useful for combining APIs into complex analysis, calculations, and automation workflows.

These mechanisms can coexist.

For example, a CAD agent might use a tool to open a drawing, MCP to query an external parts database, and JavaScript to analyze the drawing geometry against the retrieved component data.

This architecture combines the convenience of explicit tools with the flexibility of code.

Naturally, a scripting environment needs proper safeguards. These include restricting file and network access, setting execution time limits, controlling modification permissions, and supporting transactions and undo operations.

Letting AI write code doesn't mean giving it an unrestricted bulldozer and hoping for the best.

6. This isn't just a CAD problem

I think the same approach applies to GIS, 3D modeling, simulation software, and even office applications.

These applications often have complex data models and rich sets of underlying operations. But developers cannot anticipate every possible task users might eventually ask an AI to perform.

Instead of continuously adding specialized AI tools, we could provide a well-designed, well-documented API and a reliable scripting environment that AI can use.

Need a new analysis method? AI writes code.

Need a custom filtering rule? AI writes code.

Need to combine a dozen operations into a workflow? AI writes code again.

Software vendors no longer need to implement a dedicated feature for every new requirement, and agents aren't restricted to a predefined list of tools.

Of course, generated code isn't automatically correct. Engineering tasks and modifications to important data still require appropriate verification and, where necessary, human review.

But at least the agent has a more general way to attempt solving the problem.

Conclusion: Don't just give AI a hammer. Give it a toolbox and a workbench.

We used to ask:

What tools should I provide so that AI can use my software?

Now I think a more interesting question is:

What kind of programming environment should I provide so that AI can solve problems on its own?

The evolution of coding agents suggests that code is becoming a general-purpose problem-solving mechanism. It's no longer just the final product of software development. It's also a way to investigate problems, test hypotheses, process data, and automate operations.

For CAD agents, I favor an approach built around a dynamic language such as JavaScript or Python, a sufficiently complete CAD API, and an environment where AI can write, execute, debug, and iterate on its code.

MCP and tools still have an important role, but they shouldn't be the only way AI interacts with complex software.

After all, we can't possibly build every CAD feature our users will ever need.

Instead of endlessly adding new tools for AI to call, why not let AI use existing capabilities to write programs that solve problems we haven't anticipated?

For software developers, this might mean writing less repetitive glue code.

For AI, it means no longer having to raise its hand every time it encounters a new problem and ask:

"Excuse me, is there a tool specifically designed for this?"

Beyond Desktop CAD in the Browser: CADCraft vs. OpenCAD Studio vs. MLightCAD CAD Viewer

Mlight Lee — Thu, 15 Oct 2026 02:44:32 +0000

Why Browser-First Architecture Matters for Real-World CAD Performance

The evolution of WebAssembly, WebGL, and modern browser runtimes has made it increasingly practical to bring professional CAD capabilities to the web.

Today, users expect more than an online drawing preview. They want to open DWG and DXF files, inspect complex engineering drawings, create and modify entities, manage layers, measure geometry, and edit drawings—all without installing a traditional desktop CAD application.

Three projects illustrate different approaches to this challenge: CADCraft, OpenCAD Studio, and MLightCAD CAD Viewer.

All three bring CAD capabilities to the browser, but they differ in their architectural priorities.

CADCraft and OpenCAD Studio emphasize cross-platform applications that can run on desktop and web environments. MLightCAD CAD Viewer takes a more browser-oriented approach, focusing on CAD rendering, editing, performance optimization, and integration into web applications.

That distinction becomes particularly important when working with large drawings.

In my hands-on testing, CADCraft and OpenCAD Studio experienced substantial lag when opening and editing large drawings. MLightCAD CAD Viewer, by comparison, delivered a noticeably smoother experience.

This observation is consistent with MLightCAD's published engineering work on geometry batching, rendering optimization, text processing, and large-scale entity interaction.

This article compares the three products across architecture, technology stack, performance, file handling, editing capabilities, integration, deployment, and product positioning—with particular emphasis on browser-based CAD.

1. Three Products, Three Different Priorities

CADCraft: Lightweight CAD with a Shared Cross-Platform Core

CADCraft is an open-source CAD application built primarily with Rust. Its architecture separates geometry processing, drawing data, file handling, rendering, and command functionality into distinct modules.

It provides desktop and browser versions, using WebAssembly to bring core CAD functionality into the web environment.

Its main strengths include:

A shared core that can support multiple deployment targets.
Rust-based geometry and drawing-data processing.
Lightweight 2D drafting workflows.
DXF-oriented file handling and editing.
Command-based drawing operations and familiar CAD concepts.
The ability to use CAD capabilities without installing a conventional desktop application.

CADCraft is an appealing option for users who want a lightweight 2D CAD tool and the flexibility to run it on either desktop or web platforms.

However, cross-platform architecture and browser performance are separate engineering challenges. Sharing the same core logic does not automatically guarantee that large drawings will open quickly or remain responsive during editing.

Project repository: CADCraft on GitHub

OpenCAD Studio: A General CAD Environment Across Desktop and Web

OpenCAD Studio also uses Rust and WebAssembly to provide CAD functionality across desktop and browser environments. Its scope extends beyond 2D drafting to include selected 3D solid-modeling capabilities.

Its publicly described features include:

DWG and DXF file support.
Command-oriented 2D drafting.
Layers, layouts, and drawing management.
GPU-accelerated viewport rendering.
Selected 3D modeling capabilities.
Desktop and browser deployment options.

This broader scope makes OpenCAD Studio attractive to users looking for a general-purpose CAD environment rather than a narrowly focused browser editor.

However, desktop capabilities do not automatically translate into the same experience in a browser. Browser execution introduces its own constraints involving memory, task scheduling, file processing, and UI responsiveness.

OpenCAD Studio's suitability for large browser-based drawings should therefore be evaluated separately from its desktop capabilities.

Project website: OpenCAD Studio

MLightCAD CAD Viewer: A Browser-Native CAD Editor and Rendering Engine

The name "MLightCAD CAD Viewer" can be misleading. It may sound like a read-only viewer, but the product supports genuine CAD editing workflows, including creating, modifying, and deleting drawing entities.

Its browser-oriented capabilities include:

DWG/DXF loading and drawing display.
Entity selection and editing.
Layer and property management.
Measurement and annotation workflows.
WebGL-based rendering through the Three.js ecosystem.
Component and SDK integration into web applications.
Modular extensions for additional drawing and export workflows.

Rather than treating the browser as simply another platform for a desktop application, MLightCAD focuses on delivering CAD functionality within the browser's native application and graphics environment.

The objective is not merely to make an existing CAD core run on the web. It is to provide practical web-based CAD capabilities that can be used directly by end users or embedded into other software.

Official resources:

2. Architecture and Technology Stack

The most useful way to compare these products is to examine how their architectures address the needs of their target environments.

Dimension	CADCraft	OpenCAD Studio	MLightCAD CAD Viewer
Product positioning	Lightweight 2D CAD	General-purpose CAD environment	Browser-oriented CAD editor and rendering engine
Primary focus	Cross-platform drafting	2D drafting and selected 3D modeling	Web-based CAD editing and integration
Architecture	Shared cross-platform core	Shared cross-platform core	Browser-oriented rendering and editing architecture
Core technologies	Rust and WebAssembly	Rust and WebAssembly	JavaScript/TypeScript, Three.js, WebGL
Desktop support	Yes	Yes	Browser-first
Browser support	Yes	Yes	Yes
Rendering approach	Depends on the implementation and build	GPU-accelerated viewport rendering	WebGL-based rendering with CAD-specific optimization
Large-drawing optimization	Evaluate against representative workloads	Evaluate against representative workloads	Documented work on geometry batching, text rendering, and entity interaction
Integration model	Standalone application approach	Standalone application approach	Web application and SDK-oriented integration

The key distinction is not simply the programming language. Rust and WebAssembly can provide an excellent foundation for CAD, while JavaScript and WebGL can also support demanding workloads.

What matters is how the complete system handles geometry processing, rendering overhead, browser responsiveness, and incremental updates.

2.1 The Strengths of Rust and WebAssembly

Rust is well suited to computationally intensive software, including geometry operations, drawing databases, and CAD algorithms. WebAssembly makes it possible to execute compiled code inside a browser, allowing developers to reuse substantial portions of a native application core.

This approach has several benefits:

Core algorithms can be shared across desktop and browser versions.
Geometry processing can remain in a compiled implementation.
Multiple deployment targets can use common data structures and business logic.
Developers can avoid maintaining entirely separate implementations of every CAD operation.

These are meaningful architectural advantages. However, they do not eliminate browser-specific constraints.

WebAssembly applications still need to manage browser memory, JavaScript interoperability, file access, graphics APIs, and task scheduling.

A drawing operation that performs well on the desktop can behave differently in a browser, especially when expensive work competes with UI updates on the main thread.

The important distinction is that cross-platform code reuse is not the same thing as large-drawing performance optimization.

2.2 The Browser-First Approach

MLightCAD uses browser graphics technologies, including Three.js and WebGL, as part of its rendering architecture.

Its engineering work addresses problems that are particularly important for CAD: large numbers of line and point entities, repeated geometry, text-heavy drawings, complex line styles, entity selection, and large coordinate ranges.

A browser-first architecture can also simplify integration with existing web applications. The CAD engine can become one component of a larger product rather than a separate application that users must launch independently.

This approach is particularly attractive for:

Engineering project-management systems.
Online drawing review and collaboration platforms.
Manufacturing and product-data applications.
Industry-specific SaaS products.
Web applications that need CAD editing without building an entire CAD engine from scratch.

Browser-first design does not guarantee superior performance by itself. Its value comes from combining the appropriate runtime, rendering strategy, data structures, and interaction model for browser-based workloads.

3. Large Drawings Are the Real Performance Test

A CAD application can perform well on a simple floor plan and still struggle badly with a large engineering drawing.

Unlike a conventional image, a CAD drawing contains structured entities: lines, arcs, polylines, hatches, text, dimensions, blocks, and other objects.

These entities may need to be parsed, transformed into display geometry, rendered, indexed for selection, and updated when the user edits them.

A drawing with tens of thousands of entities can generate a much larger amount of rendering data, particularly when it contains complex hatches, detailed text, or repeated geometry.

Several bottlenecks can emerge.

3.1 Geometry Generation

CAD entities are not always directly renderable. Complex polylines, arcs, and hatch patterns may need to be converted into display geometry.

A relatively compact drawing file can therefore generate a large number of vertices and indices.

If geometry must be regenerated unnecessarily during zooming, editing, or layer changes, the cost can grow quickly.

3.2 Draw-Call Overhead

If every entity is represented by an independent rendering object, a large drawing can create a substantial number of draw calls.

Each draw call introduces CPU-side overhead, including rendering-state changes, buffer bindings, and communication with the GPU.

At sufficient scale, these costs can become a bottleneck even when the GPU has ample processing power.

3.3 Text and Font Processing

Engineering drawings often contain thousands of labels, dimensions, notes, and table entries.

CAD text may require specialized parsing and layout, while SHX fonts can require stroke-based processing rather than ordinary browser text rendering.

Consequently, text handling can affect loading time, memory usage, and rendering responsiveness.

3.4 Selection and Editing

An editor must do more than display geometry. It must also identify selectable entities, handle user interaction, update object properties, and reflect edits on screen.

If selecting an entity requires checking too many objects, or modifying one object triggers an unnecessarily broad scene rebuild, interaction latency becomes noticeable.

3.5 Browser Main-Thread Blocking

Long-running parsing or geometry-generation tasks can prevent the browser from responding promptly to mouse and keyboard events.

The result is the familiar experience of a frozen canvas, delayed zooming, or an interface that appears unresponsive.

These problems require more than a faster programming language. They require deliberate optimization across parsing, geometry generation, rendering, caching, selection, and incremental updates.

4. Large-Drawing Performance: Hands-On Observations

In my hands-on testing, CADCraft and OpenCAD Studio showed substantial lag when opening and editing large drawings. MLightCAD CAD Viewer performed considerably better.

The following table summarizes my observations alongside the architectural factors relevant to each product.

Performance Dimension	CADCraft	OpenCAD Studio	MLightCAD CAD Viewer
Opening large drawings	Significant lag observed in my testing	Significant lag observed in my testing	Noticeably smoother in my testing
Editing large drawings	Significant interaction lag observed	Significant interaction lag observed	More responsive in my testing
Geometry batching	Must be evaluated in the tested version	Must be evaluated in the tested version	Documented batching architecture
Text rendering optimization	Requires workload-specific validation	Requires workload-specific validation	Dedicated text-rendering engineering documented
Incremental entity updates	Requires workload-specific validation	Requires workload-specific validation	Entity-level metadata and update mechanisms documented
Browser responsiveness	Sluggish with the tested large drawings	Sluggish with the tested large drawings	Comparatively smooth with the tested drawings
Overall assessment	Less suitable for the tested large-drawing workload	Less suitable for the tested large-drawing workload	Strongest result in my hands-on comparison

These results are observations from practical use, not the outcome of a standardized benchmark. Performance can vary depending on file complexity, browser version, hardware, and software release.

Nevertheless, large-drawing responsiveness is an important product-selection criterion. Successfully opening a drawing is not enough; users must also be able to zoom, select entities, and edit geometry without excessive delays.

4.1 CADCraft: A Lightweight Core Still Needs Workload-Specific Optimization

CADCraft's modular Rust architecture and WebAssembly deployment provide a foundation for efficient 2D CAD functionality.

However, the use of Rust does not automatically eliminate rendering overhead or browser scheduling limitations.

If complex entities generate substantial display geometry, if rendering data is rebuilt unnecessarily, or if expensive tasks block UI updates, a lightweight application can still struggle with large drawings.

In my tests, the version of CADCraft I evaluated did not provide the responsiveness I expected when opening and editing large drawings.

This should not be interpreted as evidence that Rust or WebAssembly is unsuitable for large-scale CAD.

Rather, it demonstrates that a shared cross-platform core must be accompanied by workload-specific optimization to deliver a consistently responsive browser experience.

4.2 OpenCAD Studio: Desktop Capabilities Do Not Automatically Translate to the Browser

OpenCAD Studio's broader CAD functionality is attractive, particularly for users who need both 2D drafting and selected 3D modeling features.

However, large-drawing parsing, geometry generation, and data updates can compete for execution time with UI work if they are not appropriately managed.

In my testing, OpenCAD Studio also showed significant lag when opening and editing large drawings.

The conclusion is not that the product lacks all performance optimizations, but that its observed behavior in these workloads was less suitable for the large-drawing browser experience I wanted.

Teams considering OpenCAD Studio should test the browser build with representative production drawings rather than assuming desktop performance will translate directly to the web.

4.3 MLightCAD: Performance Engineering Focused on Browser CAD

MLightCAD delivered a noticeably smoother experience in my tests.

Its published technical material addresses several of the same bottlenecks that commonly affect large browser-based drawings, including geometry batching, text processing, rendering materials, large-coordinate handling, and entity interaction.

This does not prove that every performance difference is caused by a particular optimization. It does, however, provide a useful technical context for the observed experience.

The next section examines these engineering approaches in more detail.

5. How MLightCAD Optimizes Large-Drawing Rendering

MLightCAD's published engineering work is particularly relevant because it addresses specific bottlenecks in CAD rendering rather than relying solely on general-purpose graphics abstractions.

Its technical resources cover geometry batching, custom rendering materials, text-rendering optimizations, entity metadata, large-coordinate rendering, and selection performance.

These techniques address different stages of the rendering and editing pipeline.

5.1 Batched Geometry: Reducing Draw Calls

One of the most important techniques in MLightCAD's rendering architecture is geometry batching.

A naive renderer may create a separate rendering object for each CAD entity. For a drawing containing tens of thousands of entities, this can produce a large number of individual draw calls.

MLightCAD's technical documentation describes a batching system that organizes compatible geometry into shared vertex and index buffers while retaining metadata associated with individual entities.

This approach can reduce the number of draw calls required to render a drawing and limit repeated state changes and buffer-management overhead.

The benefits include:

Fewer draw calls for large collections of compatible geometry.
Less CPU-side rendering overhead.
More efficient reuse of GPU buffers.
Entity-level metadata for visibility and updates.
A foundation for updating selected geometry without rebuilding everything.

The distinction between general-purpose 3D rendering and CAD rendering matters here. CAD drawings contain extensive line and point geometry, so a solution designed specifically around CAD entities can address requirements that generic mesh-batching approaches do not fully cover.

Technical reference: MLightCAD CAD Viewer Wiki

5.2 GPU Shaders for Line Styles and Hatch Patterns

CAD line styles can include dashed and dotted patterns, while hatch entities may contain intricate repeated patterns.

If every visual effect must be expanded into large amounts of CPU-generated geometry, both memory use and processing time can increase.

MLightCAD uses custom rendering materials based on Three.js's shader capabilities for certain line and fill effects.

This allows the GPU to participate directly in producing the required appearance and can reduce some of the overhead associated with generating separate geometry for every visual detail.

The result depends on the specific entity and rendering path, and shaders do not eliminate all CPU work. Parsing, boundary processing, and geometry preparation may still be necessary.

Nevertheless, GPU-assisted rendering combined with batching provides a more targeted strategy for complex CAD displays.

5.3 Text Rendering and Font Caching

Text-heavy drawings can be particularly demanding.

MText formatting, SHX stroke fonts, and large numbers of labels introduce processing costs beyond ordinary line rendering.

MLightCAD's technical resources describe dedicated handling for CAD text and font processing, including caching strategies.

Caching can reduce repeated resource loading and parsing, particularly when users revisit drawings or reuse the same fonts across multiple sessions.

Specialized text processing also allows the implementation to address CAD-specific formatting and rendering requirements.

These details matter because an editor that renders linework quickly can still feel slow if text layout and font processing dominate the loading or redraw pipeline.

Technical reference: MLightCAD CAD Viewer Wiki

5.4 Entity Metadata and Incremental Updates

Rendering performance is only half of the problem. An editor must also remain responsive when a user modifies a drawing.

MLightCAD's batching architecture retains information about individual entities, including their positions and geometry ranges within shared buffers.

Its documented approach supports entity-level operations such as adding, updating, removing, and controlling visibility.

This creates a foundation for more targeted updates.

For example, when one entity changes, an implementation can identify the affected geometry rather than automatically rebuilding every unrelated object.

Layer visibility and selected-entity highlighting can also benefit from carefully managed entity metadata.

Not every edit can be reduced to a small buffer update; complex geometry may still require regeneration.

The important point is that the rendering architecture provides mechanisms for avoiding unnecessary work across the entire drawing.

5.5 Large Coordinates and Entity Selection

Professional drawings may use large world-coordinate values.

A browser renderer must maintain stable visual output while transforming those coordinates into a viewport suitable for display.

Selection is another important challenge. An editor needs to identify the intended entity quickly, even when a drawing contains a very large number of objects.

MLightCAD's published technical resources address large-coordinate rendering and large-scale entity selection as dedicated engineering concerns.

These capabilities matter because smooth rendering alone does not make an editor practical: users must also be able to select, inspect, and modify objects without frustrating delays.

Taken together, these optimizations demonstrate a broader design philosophy.

MLightCAD treats large-drawing performance as a pipeline problem involving geometry, rendering, text, data structures, and interaction—not simply as a question of how fast the GPU can draw a frame.

Explore the technical topics in the official CAD Viewer Wiki.

6. File Parsing Is as Important as Rendering

A CAD viewer's performance begins before the first entity appears on screen.

The application must parse the file, construct its drawing representation, resolve relevant entities, and prepare data for rendering.

If these steps are inefficient, even an excellent rendering engine cannot fully compensate.

MLightCAD's repository documents different approaches to DWG parsing, including an optional LibreDWG-based converter and a proprietary DWG parser.

These options involve trade-offs in package size, licensing, deployment, compatibility, and operational requirements.

The parser is therefore part of the performance architecture.

A parser that loads a large runtime, uses excessive memory, or struggles with complex entities can create bottlenecks before rendering begins.

File compatibility and performance must be evaluated together.

For users working with real engineering drawings, important validation cases include:

Large files with many entities.
Complex hatch patterns.
Extensive text and dimensions.
Nested blocks and external references.
Different DWG/DXF versions.
Repeated editing and save/reopen cycles.

No file extension alone guarantees complete compatibility. The relevant question is how well the application preserves and processes the specific entity types used in the target workflow.

For implementation details, consult the MLightCAD CAD Viewer repository and its official documentation.

7. Feature Comparison: Viewing Is Not the Same as Editing

The three products offer overlapping functionality, but their strengths and implementation priorities differ.

Capability	CADCraft	OpenCAD Studio	MLightCAD CAD Viewer
2D drafting	Yes	Yes	Yes
DWG/DXF workflows	Verify version-specific compatibility	Verify version-specific compatibility	Supported workflows depend on parser and configuration
Entity selection and editing	Available drafting workflows	Available drafting workflows	Entity editing supported
Layer management	Supported CAD workflows	Supported CAD workflows	Supported
Measurement and annotation	Depends on available tools	Depends on available tools	Supported workflows documented
3D modeling	Primarily 2D-focused	Selected 3D modeling capabilities	Primarily focused on browser-based drawing workflows
Browser embedding	Cross-platform application approach	Cross-platform application approach	Designed for web application integration
Self-contained HTML export	Not a primary differentiator	Not a primary differentiator	Available for supported sharing and viewing workflows

Feature availability may vary by release, build, and configuration. DWG/DXF compatibility should be validated using representative production drawings rather than inferred from file extensions alone.

7.1 CADCraft: Lightweight 2D Drafting

CADCraft is worth considering when a lightweight 2D CAD environment, shared core logic, and desktop/web availability are the primary requirements.

Its main appeal is the combination of a lightweight CAD workflow with cross-platform deployment.

For browser users, however, performance should be evaluated using the size and complexity of the drawings they expect to work with.

7.2 OpenCAD Studio: A Broader CAD Environment

OpenCAD Studio is attractive when users need 2D drafting combined with selected 3D modeling features and a general-purpose CAD workspace.

Its broader scope may be an advantage for users who want a more general CAD environment.

Teams considering it for browser-based workflows should separately assess loading times, memory consumption, editing responsiveness, and compatibility with complex drawings.

7.3 MLightCAD: Browser-Based Editing and Application Integration

MLightCAD is particularly relevant when the requirement is to provide CAD functionality inside a browser-based workflow.

Its value is not limited to displaying a drawing: users can work with entities and integrate CAD functionality into a broader web product.

For example, an engineering platform could embed the editor in a project page, associate drawing entities with business records, or provide measurement and annotation tools directly within an online review workflow.

This is a different product proposition from simply offering a browser build of a standalone CAD application.

For a detailed feature overview, see the MLightCAD CAD Viewer documentation.

8. Browser Experience, Privacy, and Deployment

8.1 No Installation Is Only the Beginning

All three products provide browser-based capabilities, so it would be inaccurate to claim that only MLightCAD can run without a desktop installation.

The more meaningful difference is how each product approaches the browser as its primary environment.

For users, a browser-based editor reduces installation and update friction. For developers, it can make CAD functionality easier to deliver across operating systems and devices.

MLightCAD's browser-oriented design is especially attractive when CAD needs to be part of an existing web application rather than a separate destination that users must open and manage.

8.2 Client-Side Processing and Data Privacy

MLightCAD emphasizes client-side drawing processing without requiring a dedicated CAD server to convert drawings before display.

This can reduce network transfer and infrastructure dependencies and may be particularly useful for sensitive engineering documents.

However, client-side processing should not be confused with a guarantee that an application makes no network requests.

Remote fonts, resources, file URLs, authentication, or application integrations may still involve network activity.

Organizations with strict confidentiality requirements should validate actual network behavior and deployment configuration.

The distinction is that the CAD parsing and rendering workflow can run locally in the browser without uploading the drawing to a dedicated CAD processing service.

8.3 Self-Contained HTML and Sharing

MLightCAD also provides a self-contained HTML export workflow intended to make drawings easier to share without requiring recipients to install a conventional CAD application.

Such a deliverable can be useful for lightweight viewing and review.

The exported HTML can support viewing workflows such as panning, zooming, layer visibility, and measurement, depending on the export configuration.

It should not automatically be treated as equivalent to a full editing environment or as a replacement for the original DWG/DXF file.

For more information, see the official CAD Viewer repository.

8.4 Deployment and Integration Comparison

Dimension	CADCraft	OpenCAD Studio	MLightCAD CAD Viewer
Desktop deployment	Yes	Yes	Browser-first approach
Browser deployment	Yes	Yes	Yes
Browser installation requirements	No conventional desktop installation required	No conventional desktop installation required	No conventional desktop installation required
Integration into an existing web product	Depends on exposed interfaces	Depends on exposed interfaces	SDK- and component-oriented integration
Client-side drawing processing	Depends on implementation	Depends on implementation	Supported workflows can process drawings in the browser
Dedicated CAD conversion server	Depends on deployment architecture	Depends on deployment architecture	Can reduce the need for a dedicated conversion server
Self-contained drawing sharing	Not a primary differentiator	Not a primary differentiator	Supported HTML export workflow
Extensibility	Depends on project interfaces	Depends on project interfaces	Modular integration and extension approach

Client-side CAD processing can reduce the need for server-side conversion, but a production system may still require backend services for authentication, project management, permissions, auditing, persistence, collaboration, and version history.

9. Developer Experience: Integrating CAD into Web Applications

For a standalone CAD application, the most important questions may concern drawing compatibility and drafting features.

For a SaaS product or engineering platform, integration costs can be equally important.

Developers should evaluate:

The availability and stability of public APIs.
Control over toolbars, panels, and interaction state.
Integration with existing frontend frameworks.
Access to drawing entities and their properties.
Save, versioning, and permission workflows.
Extensibility and customization.
The effort required to maintain custom UI adaptations.

Rust and WebAssembly provide a strong foundation for sharing core logic, but embedding a standalone application into an existing web product can require additional work if the public integration interfaces do not match the host application's needs.

MLightCAD offers a component- and SDK-oriented integration path. Its architecture is designed to let developers embed CAD functionality into their own web applications and extend the experience with plugins and custom interfaces.

This is important for larger drawings because responsiveness depends not only on how efficiently geometry is rendered, but also on whether expensive tasks interfere with browser interaction.

A modular architecture can also let developers choose the level of functionality appropriate to each page. A lightweight review page does not necessarily need the same UI as a full editing environment.

For teams building web-first products, this can reduce the cost of turning CAD into a reusable application capability.

Explore the MLightCAD CAD Viewer Wiki for architecture, integration, configuration, and API guidance.

10. Cost, Licensing, and Operational Considerations

Technology selection should account for the complete lifecycle cost, not only the initial software license.

Relevant factors include:

Client-side package size and initialization cost.
Server infrastructure requirements.
Integration and customization effort.
Maintenance across browser versions.
File compatibility testing.
Security and privacy requirements.
Licensing obligations for the core project and its dependencies.

10.1 Cost and Licensing Comparison

Dimension	CADCraft	OpenCAD Studio	MLightCAD CAD Viewer
Initial adoption cost	Check current project terms	Check current product terms	Check current product and SDK terms
Self-hosting	Depends on license and implementation	Depends on license and implementation	Depends on selected components and deployment
Server infrastructure	Depends on deployment architecture	Depends on deployment architecture	Can reduce dedicated CAD conversion requirements
Integration effort	Depends on required customization	Depends on required customization	Designed for web application integration
Dependency licensing	Must be reviewed	Must be reviewed	Must be reviewed, especially for DWG parser options
Production suitability	Validate performance and compatibility	Validate performance and compatibility	Strong candidate for browser-first CAD workloads

Client-side CAD processing can reduce the need for dedicated conversion services and associated server resources.

However, a production system may still require backend services for authentication, project management, permissions, auditing, persistence, collaboration, and version history.

Licensing also requires careful review.

The MLightCAD CAD Viewer repository is primarily MIT licensed, but DWG parsing options can have different licensing conditions. For example, using a GPL-licensed converter in a commercial distribution can introduce obligations that differ from those associated with a proprietary parser.

Teams should verify the license of the exact package, dependencies, redistribution model, and deployment architecture they plan to use.

For a web-first CAD product, the best choice is the one that minimizes total engineering and operational cost while meeting the required performance, compatibility, and feature standards.

11. Which Product Should You Choose?

The best choice depends on the environment, feature requirements, and drawing sizes that matter most to your users.

Requirement	Recommended Product to Evaluate
Lightweight 2D CAD with cross-platform deployment	CADCraft
General CAD environment with selected 3D modeling features	OpenCAD Studio
Browser-based CAD editing	MLightCAD CAD Viewer
Large-drawing browser workflows	MLightCAD CAD Viewer
Embedding CAD into an existing web application	MLightCAD CAD Viewer
Reducing dependence on a dedicated CAD conversion server	MLightCAD CAD Viewer, subject to deployment requirements

Choose CADCraft If...

You want a lightweight 2D CAD application.
You value a shared core for desktop and browser deployment.
Your drawing sizes and editing requirements are compatible with its current performance.
You prefer a straightforward drafting environment.

Choose OpenCAD Studio If...

You want a broader CAD environment.
You need selected 3D modeling capabilities alongside 2D drafting.
Desktop and browser deployment are both important.
Your team can validate its performance against representative production drawings.

Choose MLightCAD CAD Viewer If...

Your primary target is the browser.
You need actual editing capabilities rather than read-only preview.
Large drawings are part of your normal workflow.
You want to integrate CAD into an existing web application.
You want to reduce dependence on a dedicated CAD conversion server.
You value a modular architecture and browser-based deployment.

For demanding browser-based CAD workflows, MLightCAD is the option I would evaluate first.

12. Conclusion: If You Need CAD in the Browser, Start with MLightCAD

CADCraft, OpenCAD Studio, and MLightCAD CAD Viewer represent different approaches to bringing CAD functionality to modern users.

CADCraft focuses on lightweight 2D CAD and a shared cross-platform core. OpenCAD Studio offers a broader CAD environment, including selected 3D modeling capabilities. MLightCAD places greater emphasis on browser-based drawing processing, rendering performance, editing, and integration into web applications.

For small drawings, the differences between these approaches may not always be obvious.

With larger engineering files, however, rendering architecture, caching, geometry batching, text handling, incremental updates, and task scheduling can have a substantial impact on the user experience.

In my hands-on testing, CADCraft and OpenCAD Studio showed significant lag when opening and editing large drawings, while MLightCAD CAD Viewer performed considerably better.

MLightCAD's published engineering work provides a technical context for that observation, particularly its work on batched geometry, GPU-assisted rendering, text processing, and large-scale entity interaction.

This is not a claim that MLightCAD will outperform every competitor on every drawing or every device. A rigorous performance ranking requires controlled benchmarks using the same files, hardware, browser versions, and operations.

Nevertheless, the observed results and documented design priorities make MLightCAD a compelling choice for demanding browser-based CAD workflows.

The key distinction is not simply whether an application uses Rust, WebAssembly, JavaScript, or WebGL. It is whether its architecture and optimization work address the actual requirements of its target environment.

If you need a cross-platform standalone CAD application, CADCraft and OpenCAD Studio are both worth evaluating according to your required feature set.

If your goal is to build or use a browser-first CAD editor that can handle large drawings, supports real entity editing, reduces dependence on dedicated CAD conversion servers, and integrates naturally into web applications, MLightCAD CAD Viewer is the stronger choice to evaluate first.

For web CAD, being able to open a drawing is only the starting point.

The real challenge is making complex drawings practical to work with—and that is where browser-oriented performance engineering makes the difference.

DWG in the Browser? Meet MLightCAD CAD Viewer

Mlight Lee — Wed, 07 Oct 2026 11:06:54 +0000

If you have ever worked with CAD files on the web, you probably know the problem.

A .dwg or .dxf file is not just another document format. Unlike images or PDFs, CAD drawings are interactive engineering data containing layers, blocks, dimensions, text, geometry, and many other entities.

Traditionally, viewing these files means installing a desktop CAD application or uploading the file to a server for processing.

MLightCAD CAD Viewer takes a different approach: open and interact with DWG/DXF files directly in the browser.

No CAD application.
No backend server.
No file upload required.

The project is open source and available on GitHub under the MIT license.

What is MLightCAD CAD Viewer?

MLightCAD CAD Viewer is a web-based DWG/DXF viewer and editor designed to bring CAD workflows into the browser.

It can load, parse, render, and interact with CAD drawings entirely on the client side. This makes it possible to build CAD-related web applications without maintaining a dedicated CAD processing server.

It is also designed to be more than just an online file viewer.

You can use it as:

A standalone DWG/DXF viewer
A Vue 3 component inside your own application
A CAD visualization SDK
A component embedded into another website or application
An offline CAD viewer
A foundation for building browser-based CAD applications
A command-line workflow for processing CAD drawings
A portable single-file CAD review application

The goal is simple:

Make CAD data as accessible on the web as other digital content.

Open a DWG or DXF Directly in Your Browser

The most important feature is also the simplest one.

Drop a DWG or DXF file into the viewer and start working with it.

There is no need to first convert the drawing into SVG, PDF, PNG, or another intermediate format. The browser handles the CAD data directly. This is particularly useful when building applications where CAD drawings are just one part of a larger workflow.

For example, imagine a construction management application where users need to inspect floor plans, or a manufacturing platform where users need to preview engineering drawings associated with a part.

Instead of asking users to download the drawing and open it with another application, the drawing can simply become part of the web application.

A Familiar CAD Experience

MLightCAD CAD Viewer is not designed to be just a canvas displaying some lines. It provides many of the interactions that CAD users expect.

Navigation

Users can:

Zoom in and out
Pan around the drawing
Zoom to extents
Select drawing entities
Navigate large drawings interactively

The interaction model is designed to feel familiar to people who already work with CAD software. It also supports touch interaction, making the viewer suitable for tablets and mobile devices.

Layer Management

CAD drawings often contain hundreds of layers.

The viewer provides a layer management interface that allows users to:

Show or hide layers
Inspect layer information
Focus on specific parts of a drawing
Work with drawings containing complex layer structures

This makes it much more useful for real engineering drawings than a simple geometry renderer.

Measurement

The viewer also provides measurement capabilities for reviewing drawings. For example, users can measure distances directly on the drawing without exporting it to another application.

The goal is not to replace a full desktop CAD system, but to provide the essential tools needed for viewing, reviewing, inspecting, and sharing drawings on the web.

CAD-Style Command Line

For users who are comfortable with AutoCAD-style workflows, CAD Viewer also includes a command-line interface. This provides an interesting bridge between traditional CAD applications and modern web applications. Instead of treating CAD as an unfamiliar web canvas, the project brings some familiar CAD concepts into the browser.

Designed for Large CAD Drawings

One of the biggest challenges in browser-based CAD is performance. A CAD drawing can contain tens of thousands, hundreds of thousands, or even millions of graphical elements. Rendering every entity independently would quickly become expensive in a WebGL environment.

MLightCAD CAD Viewer therefore puts significant effort into efficient rendering and geometry batching. The result is a viewer designed to remain interactive even when working with relatively large and complex drawings.

This matters because a browser-based CAD viewer is only useful if it remains responsive when users open the drawings they actually use in production.

Performance is therefore treated as a core part of the architecture rather than an optimization added later.

Privacy by Design

One of the most interesting consequences of browser-side CAD processing is privacy. When a user opens a drawing locally, the file does not have to be uploaded to a remote CAD processing service. This is important for engineering organizations. CAD drawings can contain:

Product designs
Manufacturing information
Building layouts
Mechanical details
Customer information
Proprietary engineering data

For many organizations, sending such files to an external server simply to generate a preview is undesirable or even impossible. With browser-side processing, applications can keep the drawing on the user's machine.

This also makes CAD Viewer suitable for environments where network access is limited or completely unavailable.

From Online Viewer to Offline CAD Application

There is another interesting capability that comes from this architecture.

A drawing can be exported into a single self-contained HTML file.

The resulting file contains the drawing data together with the viewer runtime. You can send that HTML file to someone else. They can open it in a modern browser without installing CAD software, running a server, or connecting to your application.

Want to try it yourself? You can use the DWG to HTML Converter to convert a DWG file into a self-contained HTML file directly in your browser.

The recipient can still:

Open the drawing
Pan and zoom
Control layers
Inspect the drawing
Measure distances

This turns a CAD drawing into a portable web document. Think about sending a CAD drawing to a customer.

Instead of saying:

"Please install this CAD viewer."

you can simply send:

"Open this HTML file."

This can also be useful for:

Design reviews
Project archives
Documentation
Customer communication
Offline environments
Air-gapped environments
Long-term drawing archives

Embed CAD into Your Website with One Line of Code

You don't even need to build a CAD application from scratch. MLightCAD CAD Viewer can also be embedded directly into an existing website or web application. In many cases, you can add a DWG/DXF viewer with just a single line of HTML code.

For example, an application can simply embed the viewer as an iframe:

<iframe
  src="https://mlightcad.com/iframe-plugin.html?url=YOUR_DWG_OR_DXF_URL"
  width="100%"
  height="600"
  frameborder="0">
</iframe>

This makes it possible to add CAD viewing capabilities to websites, documentation systems, project management platforms, CMSs, customer portals, or internal engineering applications without implementing a CAD rendering engine yourself.

You can try the one-line DWG/DXF embedding experience here: MLightCAD IFrame Plugin.

The idea is simple: your application provides the CAD file, and MLightCAD provides the CAD viewing experience. This makes CAD content much easier to integrate into the web.

CAD on Any Website

Another important aspect of CAD Viewer is that it does not have to be used as a standalone application.

It can be integrated into an existing web application.

For example, you could have:

Your Application
       │
       ├── Project Management
       ├── Documents
       ├── BOM
       ├── Engineering Data
       │
       └── MLightCAD CAD Viewer
                │
                ├── DWG
                └── DXF

This makes CAD drawings another type of content inside your application.

A project management system can display its engineering drawings.
A document management system can preview DWG files.
A manufacturing platform can display drawings next to product information.
A collaboration system can provide drawing review without requiring users to leave the application.

And because the viewer runs in the browser, the integration can remain entirely web-based.

Data Sources Are Not Limited to Local Files

The viewer can also be integrated with different data sources.

A DWG/DXF file does not necessarily have to come from a local file picker.

It can come from a web application, cloud storage, document management system, or another data source.

This makes it possible to build integrations such as:

CAD files stored in OneDrive
CAD files stored in Google Drive
CAD drawings inside a document management system
CAD previews inside collaboration platforms
CAD drawings inside CMS systems
CAD files served from your own API

For example, you can try opening DWG/DXF drawings directly from your OneDrive using the MLightCAD OneDrive integration.

The viewer becomes the CAD rendering layer, while your application decides where the CAD data comes from.

This separation is important because it means you don't need to build a CAD engine every time you want to add CAD support to a product.

Build Your Own CAD Application

For developers, CAD Viewer can be used at different levels.

If you simply need a ready-to-use viewer, you can use the complete application.
If you are building a Vue 3 application, you can integrate the CAD viewer as a component.
And if you want more control, the project also provides lower-level building blocks for creating your own CAD experiences.

This opens the door to applications such as:

Online CAD viewers
CAD review systems
Engineering document platforms
Construction management applications
Manufacturing platforms
CAD collaboration tools
CAD asset management systems
Digital twins
GIS/CAD applications
AI-assisted CAD tools

The important idea is that the viewer does not have to be the final product.

It can be the CAD engine inside another product.

A Web-Native CAD Ecosystem

This is perhaps the larger vision behind MLightCAD CAD Viewer.

The project is not trying to recreate the entire desktop CAD world inside a browser overnight.

Instead, it provides a foundation for bringing CAD data into the web.

The architecture allows different pieces of the ecosystem to evolve independently:

CAD data → CAD model → rendering → interaction → application

That means developers can build specialized experiences on top of the same CAD foundation.

One application might focus on document preview.

Another might focus on engineering review.

Another might focus on measurement.

Another might integrate CAD with GIS.

Another might use CAD data as part of an AI workflow.

The CAD viewer becomes infrastructure rather than just an application.

Command Line and Automation

CAD Viewer is also useful outside the browser UI.

The project provides command-line tooling for CAD-related workflows.

For example, CAD drawings can be processed in batches and converted into images or other web-friendly representations.

This can be useful for:

Generating previews
Creating thumbnails
Building document indexes
Preparing datasets
Automating CAD workflows
Preparing data for AI/ML applications

This is particularly interesting as CAD increasingly becomes part of automated and AI-driven workflows.

Why Browser-Based CAD Matters

The web has changed how we work with almost every other type of content.

We can open documents in a browser.

We can edit images in a browser.

We can collaborate on spreadsheets in a browser.

We can review videos in a browser.

But CAD has remained heavily tied to desktop software.

There are good reasons for this. CAD files are complicated, and high-performance rendering is difficult.

But modern browsers now provide technologies such as WebAssembly, WebGL, Web Workers, and increasingly powerful JavaScript runtimes.

These technologies make a different model possible.

Instead of:

CAD File
   ↓
Upload to Server
   ↓
CAD Processing
   ↓
Server Rendering
   ↓
Browser

you can have:

CAD File
   ↓
Browser
   ├── Parse
   ├── Process
   ├── Render
   └── Interact

That changes the architecture of web-based CAD applications.

It can reduce server infrastructure, improve privacy, support offline scenarios, and make CAD much easier to embed into existing web products.

Open Source

MLightCAD CAD Viewer is open source and released under the MIT license.

The project is available on GitHub and welcomes developers who want to experiment with browser-based CAD.

If you are building something around DWG/DXF, you don't necessarily need to start by implementing a CAD engine from scratch.

You can start with a working browser-based CAD foundation and build your own application around it.

What's Next?

The current viewer is only one step toward a broader vision.

The direction is to gradually move from:

CAD Viewer → CAD Review → CAD Editing → CAD Applications

and eventually connect CAD with other parts of the modern software ecosystem.

That includes cloud storage, document management, collaboration, AI, GIS, mobile applications, and offline workflows.

The interesting part is not simply putting AutoCAD drawings into a browser.

It is making CAD data a first-class citizen of the web.

Try It

If you work with DWG/DXF files or are building a web application that needs CAD support, give MLightCAD CAD Viewer a try.

You can explore the source code, run the demo, or integrate the viewer into your own application.

GitHub: mlightcad/cad-viewer

If you're building something interesting with it, I'd love to hear about it.

And if you have ideas, feature requests, or integration scenarios, feel free to open an issue or start a discussion.

The future of CAD may not be another desktop application.

It might be the browser.

DEV Community: Mlight Lee

Letting AI Write Code Against Your Drawings: The mlightcad MCP Server

Stop teaching AI 100 CAD tools. Give it a scripting API and let it figure things out.

1. The architecture: One brain, multiple ways to use it

@mlightcad/cad-agent-core — The engine

@mlightcad/cad-agent-plugin — The in-app agent

@mlightcad/cad-mcp-server — MCP for external agents

WebMCP — The next frontend

2. Why scripts beat a pile of MCP tools

The tool-sprawl problem

The scripting alternative

Three advantages that matter more than they first appear

So, is MCP still useful?

3. Getting started with the mlightcad MCP server

Claude Code / Claude Desktop

Cursor

A couple of useful environment variables

The typical workflow

Saving the result

4. Three real experiments

4.1 Turning a line-drawn BOM into a Markdown table

4.2 Reading a drawing frame from top to bottom

4.3 Splitting a multi-sheet drawing into separate DXF files

5. What can you actually do with this?

Information extraction

Drawing analysis

Batch editing

File processing

Visual verification

6. The bigger picture: Give AI a workbench, not a menu

Try it yourself

Building a CAD Agent: MCP, Tools, or Let AI Write Code?

1. What's changed in AI agents over the past six months?

2. Can a collection of tools really cover everything?

3. Why not let AI write code directly?

4. Three underrated advantages of letting AI write scripts

4.1. Fewer tokens: Don't make AI inspect 100,000 entities one by one

4.2. Easier verification: Don't just say it worked. Show me the evidence.

4.3. Faster execution: Fewer meetings, more work

5. Does this mean MCP and tools are obsolete?

6. This isn't just a CAD problem

Conclusion: Don't just give AI a hammer. Give it a toolbox and a workbench.

Beyond Desktop CAD in the Browser: CADCraft vs. OpenCAD Studio vs. MLightCAD CAD Viewer

Why Browser-First Architecture Matters for Real-World CAD Performance

1. Three Products, Three Different Priorities

CADCraft: Lightweight CAD with a Shared Cross-Platform Core

OpenCAD Studio: A General CAD Environment Across Desktop and Web

MLightCAD CAD Viewer: A Browser-Native CAD Editor and Rendering Engine

2. Architecture and Technology Stack

2.1 The Strengths of Rust and WebAssembly

2.2 The Browser-First Approach

3. Large Drawings Are the Real Performance Test

3.1 Geometry Generation

3.2 Draw-Call Overhead

3.3 Text and Font Processing

3.4 Selection and Editing

3.5 Browser Main-Thread Blocking

4. Large-Drawing Performance: Hands-On Observations

4.1 CADCraft: A Lightweight Core Still Needs Workload-Specific Optimization

4.2 OpenCAD Studio: Desktop Capabilities Do Not Automatically Translate to the Browser

4.3 MLightCAD: Performance Engineering Focused on Browser CAD

5. How MLightCAD Optimizes Large-Drawing Rendering

5.1 Batched Geometry: Reducing Draw Calls

5.2 GPU Shaders for Line Styles and Hatch Patterns

5.3 Text Rendering and Font Caching

5.4 Entity Metadata and Incremental Updates

5.5 Large Coordinates and Entity Selection

6. File Parsing Is as Important as Rendering

7. Feature Comparison: Viewing Is Not the Same as Editing

7.1 CADCraft: Lightweight 2D Drafting

7.2 OpenCAD Studio: A Broader CAD Environment

7.3 MLightCAD: Browser-Based Editing and Application Integration

8. Browser Experience, Privacy, and Deployment

8.1 No Installation Is Only the Beginning

8.2 Client-Side Processing and Data Privacy

8.3 Self-Contained HTML and Sharing

8.4 Deployment and Integration Comparison

9. Developer Experience: Integrating CAD into Web Applications

10. Cost, Licensing, and Operational Considerations

10.1 Cost and Licensing Comparison

`@mlightcad/cad-agent-core` — The engine

`@mlightcad/cad-agent-plugin` — The in-app agent

`@mlightcad/cad-mcp-server` — MCP for external agents