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

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?"

Comments

[BenchSmoke]

This lines up with something we saw in our own agent tests: when the file-write tool was denied, the model just wrote the same file through a shell command. Once an agent can run code, the tool list stops being the real permission boundary, so a script-based approach needs its own sandbox and an explicit allowlist for write operations. Curious how you're scoping the write side of the CAD scripting API?