Engineering Intelligence as MCP Tools: The Specialist Layer Agents Reach For

In the last post I argued that engineering software is shifting from assisting work to driving decisions - that the bottleneck in engineering practice is moving from operating tools to supervising the decisions tools make. I left off with a question I want to take up here: when the platforms get smart enough to orchestrate work across products, what happens to the specialist tools they call? The short answer: the specialists become more valuable, not less. But only if they're built right. Here's the longer answer.

In late 2024, Anthropic introduced the Model Context Protocol - an open standard that lets AI agents discover and invoke external tools through natural language, without hard-coded integrations. By 2025 it had become the de facto way agents talked to tools. By 2026, every major platform vendor had picked it up.
Autodesk is now building a Design and Make MCP marketplace. Fusion, Revit, Fusion Data, and the Product Help system all have MCP servers shipping. Autodesk Assistant - the AI agent embedded across Fusion, Inventor, Moldflow, Vault, and ACC - runs on this infrastructure. The marketplace exists. to third-party developers; partners can publish their own MCP servers alongside Autodesk's.
This is not a marketing positioning exercise. It's an architectural statement.
The statement is: the platform doesn't try to be smart at everything. It tries to be smart at orchestrating - at understanding intent, breaking tasks into steps, calling the right tools in the right order, and returning a coherent answer. The specialist capability - running a CFD simulation, validating a mesh, checking energy compliance, simulating a hydraulic network - sits in tools the platform doesn't own. The agent calls those tools through MCP.
If you're building engineering software in 2026, this changes how you think about your product.

Imagine a building designer working in Revit. They're roughing out the layout of a mid-sized office building. They turn to Autodesk Assistant and ask: "Check this design for NZEB compliance and tell me where it's likely to fail."
This is not one task. It's many. Parse the Revit model. Identify the relevant compliance standard. Run an energy performance simulation against the geometry. Compare results against the standard. Identify zones of risk. Generate a report with reasoning. Maybe even propose modifications. A platform like Autodesk could try to do all of this in-house. It can't. Energy simulation is a specialist domain - there are firms that have spent twenty years building the codebases that do this well. Mesh validation is a specialist domain. CFD is a specialist domain. Hydraulic network simulation is a specialist domain. Platforms have absorbed specialist categories before - Autodesk, Microsoft, Adobe have all done it. The barrier isn't impossibility; it's the depth of physics, the maturity of the toolchains, and the economic case for building versus buying access through a marketplace.
So the agent reaches out. It calls a Buildings AI MCP server for the NZEB check. It calls a CFD MCP server for airflow simulation on the flagged zones. It calls a mesh validation server to make sure the geometry it just simulated is watertight. It chains these results together, runs them past the design model, and returns a coherent answer to the engineer.
The engineer never knows - or needs to know - which tools were called. They asked a question. They got an answer.

This is the agentic engineering ecosystem Autodesk is building toward. And the partners who own the specialist tools in that ecosystem are not commodity vendors. They're infrastructure.

There's an obvious temptation, watching this market open up, to ship the easy MCP servers first - wrap an existing API in MCP, publish it to the marketplace, claim the position.
This is mostly a mistake.
Three reasons.

First, the marketplace will fill quickly with thin wrappers. APIs are already exposed; turning them into MCP servers is a few weeks of work. The agents calling these servers will quickly learn which are useful and which are generic plumbing dressed up in new packaging. Generic plumbing gets called once, found unhelpful, and not called again.

Second, the agents calling MCP servers don't just need access to capability. They need access to capability with reasoning. An MCP server that returns raw simulation data forces the agent to interpret the data itself - which it often can't do well. An MCP server that returns structured assessment - "the design fails compliance at zone X for reason Y, here's the relevant standard, here's the magnitude of the violation" - gives the agent something it can actually act on.

The difference is the difference between a CFD server that returns a pressure field and one that returns "the heat exchanger has a recirculation zone at the inlet that will reduce efficiency by approximately 12%; consider relocating the baffle." The first is data. The second is intelligence.

Third, the moat in this category is not the MCP wrapper. It's the underlying tool. Anyone can write an MCP server in a week. Almost no one can write a production-grade CFD solver, or a hydraulic simulator that handles real distribution networks, or a building energy model accurate enough to use for compliance certification. The MCP server is the delivery mechanism. The thing being delivered is what matters.

The most interesting thing about MCP isn't any single server. It's that servers compose.
An agent backed by the right set of specialist MCP servers can execute a workflow no single product offers. Consider a workflow like:
"Review the design for ASHRAE 90.1 compliance, run an airflow simulation on any zones the compliance check flags, validate that the simulation mesh is watertight before trusting the results, generate an RFI for any violations, attach the simulation report, and log everything to the ACC project."
This is six specialist tools chained - compliance check, simulation, mesh validation, RFI generation, document attachment, project logging - coordinated by an agent. No single vendor today ships all six. But a vendor that ships several of them, and ensures they chain well with each other and with the platform, builds a position no thin-wrapper competitor can replicate.
This is where the engineering software industry is heading. The competitive question is no longer "what features does your product have" but "how well does your specialist intelligence chain with the specialist intelligence of others - and how often does the platform reach for you in the workflows that matter?"

Three things change. First, product strategy changes. Building monolithic engineering applications - one app for design, one for simulation, one for analysis - was the right strategy for the desktop era. Building specialist intelligence that plugs into agentic workflows is the right strategy now. The product is the specialist capability. The MCP server is the delivery. Second, R&D investment changes. Investing in the depth of the specialist domain - better physics, better solvers, better domain-adapted models, better validation harnesses - pays off compounded in this environment, because every workflow the agent runs leans harder on the specialists in the chain. Investing in generic UI features pays off less, because the agent often replaces the UI as the access layer.
Third, partner strategy changes. Firms that historically competed because they offered overlapping monolithic products now have reason to cooperate - because their MCP servers can chain. The competitive question shifts from "can we beat them on features" to "can we be in the chain when the agent reaches for help."
This last shift is the one most engineering software firms haven't fully internalized yet. The ones that do will build very differently from the ones that don't.

The agentic ecosystem inside engineering platforms is being built now. The MCP marketplace is open. The platforms - Autodesk, Bentley, Dassault - are committing publicly to specialist-partner participation. The partners who move first will set the patterns the marketplace adopts as defaults. The opportunity isn't to wrap an existing API in MCP and call it a day. It's to build the specialist intelligence layer the next generation of engineering platforms will be unable to function without - and to do it with enough depth, enough reasoning, and enough composability that the agents reach for it again and again.
This is where the real moats in engineering software will be built over the next five years. Not in feature lists. In the depth of the specialist intelligence the platforms can no longer afford to build themselves.
The infrastructure is being laid now. The platforms need partners to fill it. The question for anyone building engineering software is no longer whether to participate. It's how deeply.