When large models first entered software products, the most common design was a chat window placed beside the existing interface.

Users could ask where a command was, what an error meant, or how to complete a procedure described in the documentation. This lowered the learning barrier, but a layer of separation remained between the model and the software. The model could answer questions without necessarily knowing what actually existed in the current project, and it could not reliably operate the application's internal objects.

Another approach followed: let the model inspect screenshots and simulate mouse and keyboard input, finding menus, entering parameters, and pressing buttons as a person would.

Computer Use expanded the range of software a model could operate, but it did not solve the semantic problems of professional applications. In CAD, CAE, EDA, and scientific software, a model needs to know more than where a button is:

  • Which part, face, feature, or component is currently selected?
  • Which electrical net is a wire actually connected to?
  • Are parameters measured in millimeters, inches, ohms, or megapascals?
  • Which downstream features will fail after a dimension changes?
  • Did a simulation genuinely converge?
  • Which materials, loads, and boundary conditions produced a result?

Once models move from answering questions about software to participating in real work, software needs a new kind of interface. It cannot be designed only for programmers or only for graphical interaction. It must let models discover, understand, and invoke software capabilities.

The Model Context Protocol, or MCP, developed in response to that need.

MCP Originally Addressed Fragmentation, Not Clicking Through Software

Anthropic released MCP as an open-source project on November 25, 2024.

Models could already generate code, analyze documents, and call functions. Yet access to enterprise files, databases, repositories, and business systems still required developers to build a separate connector for every source. Connecting one model application to Google Drive, Slack, GitHub, PostgreSQL, and a local filesystem often meant maintaining five incompatible integrations.

Anthropic described the problem as models being isolated from information silos. Model capability was improving while real data and software functions remained scattered across disconnected systems. MCP was designed as an open standard through which a source or tool could expose one standardized service and become available to multiple compatible model applications. The earliest reference servers covered Google Drive, Slack, GitHub, Git, PostgreSQL, and Puppeteer. The protocol's two principal original creators were David Soria Parra and Justin Spahr-Summers.

MCP's structure was inspired by the Language Server Protocol, or LSP.

LSP reduced repeated integration work between editors and programming-language tools. Before it, every editor needed separate implementations for Python, Java, C++, and other languages to support completion, diagnostics, and definition lookup. With LSP, one language server could serve multiple editors.

MCP applies a similar idea:

Instead of making every model application integrate separately with every software product and data source, software exposes a standard server that compatible model clients can connect to.

MCP uses a Host, Client, and Server architecture and exchanges messages through JSON-RPC. A server can expose three core kinds of capability:

  • Resources: files, database records, engineering objects, logs, and other context;
  • Tools: operations for querying, modifying, executing, calculating, and exporting;
  • Prompts: prepared task templates and workflows.

The Host contains the model and user interaction. A Client manages a connection to a particular MCP Server. The Server exposes the data and operations of a concrete system.

MCP is therefore not a new solver, modeling kernel, or automation engine. It is a common interface between models and capabilities that software already possesses.

From Local Connectors to a Production Protocol

When MCP appeared in 2024, it was initially well suited to local files, development environments, and desktop tools. Its rapid evolution during 2025 made it more relevant to large software vendors.

March 2025: Remote Connections and Authorization Began to Take Shape

The March 2025 specification introduced an OAuth 2.1-based authorization framework, replaced the early HTTP+SSE transport with Streamable HTTP, and added tool annotations that tell clients whether a tool is read-only or potentially destructive.

This was an important transition.

If MCP could connect only to a local process on a user's computer, it would remain largely an experimental developer tool. Remote transport, authentication, and permission descriptions made it possible for enterprise software to offer MCP through managed cloud services.

June 2025: Tool Results Became Better Suited to Professional Work

The June 2025 release added structured tool output, Resource Links, and Elicitation.

Structured output allows a tool to return fields with explicit meanings rather than an ambiguous paragraph. An engineering solver, for example, can return:

Solve status
Maximum stress
Maximum displacement
Object ID of the critical location
Units
Warning count
Result file

Elicitation lets a server request required information during execution, such as confirmation of a material, unit system, file location, or scope of operation. The protocol also strengthened OAuth resource-server discovery and token-use security.

2025: Major Model and Platform Vendors Adopted MCP

Anthropic proposed MCP, but the protocol quickly expanded beyond the Claude ecosystem.

Microsoft introduced an MCP preview for Copilot Studio in March 2025 and announced general availability in May. Once a server is connected, its tools and data can be added dynamically to an agent. When the server changes its tools, Copilot Studio can synchronize them without requiring every Action to be recreated manually. Microsoft also connected MCP to its existing connector system so customers could continue using virtual networks, data-loss prevention, and multiple authentication mechanisms.

OpenAI adopted MCP across its API, ChatGPT Apps, and agent tooling. Developers can let a model connect to remote MCP Servers, restrict the tools it may call, and require approval for write operations. Custom ChatGPT apps likewise use MCP as an important foundation for connecting tools and internal data.

GitHub publishes and maintains an official GitHub MCP Server. Compatible IDEs and agents can read repositories, Issues, and Pull Requests, create work items, and access code-security functions. Organizations can use MCP policies and registries to limit which servers are allowed.

Google Cloud added MCP to its database toolbox in 2025 and announced official MCP support for Google services that December. Google's reasoning was direct: depending on community servers forces developers to install and maintain many local implementations, creating fragile integration. Service providers therefore need to maintain official, remote, governable endpoints.

MCP had completed an important transition:

It moved from an open connection method supplied by Anthropic toward a shared interface layer adopted by different models, agent platforms, and software vendors.

Late 2025: Neutral Governance

The November 2025 specification added OpenID Connect discovery, incremental authorization, richer tool display metadata, and experimental Tasks. Tasks track operations that take time, require status polling, or return results later—properties especially useful for compilation, batch processing, and engineering simulation. The release also established a formal governance structure, working groups, and SDK maturity tiers.

In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation. The AAIF's founding projects also included Block's goose and OpenAI's AGENTS.md. Its members included Anthropic, OpenAI, Microsoft, Google, AWS, Cloudflare, Bloomberg, and others.

This reduced vendors' concern that supporting MCP meant adopting a competitor's proprietary protocol. Governance no longer belonged only to one model company; MCP was becoming neutral open-source infrastructure.

As of July 2026, the stable specification remains 2025-11-25. The next release, planned for July 28, 2026, is moving further away from protocol-level sessions toward a stateless core that works more naturally with ordinary HTTP infrastructure, while extensions carry Tasks, interactive interfaces, and other capabilities.

Why Software Vendors Are Making Products Model-friendly

Supporting MCP is not merely a way to follow a popular protocol.

The deeper change is that models are becoming a new front door to software.

Previously, users opened CAD, EDA, or office software first and chose functions from menus. In the future, they may first state a goal to Codex, Claude, Copilot, ChatGPT, or an internal enterprise agent:

Check this circuit for power-distribution problems.

Re-run the analysis after modifying the model and compare the stress results.

Find interferences in this assembly and generate a report.

Read the project state, create repair tasks, and submit the code.

The agent then decides which software it needs.

As this way of working becomes more common, a product's ability to be discovered, understood, and invoked correctly by models will become part of its competitiveness, much like file formats, plugin ecosystems, and cloud APIs.

Keeping Professional Software in the Workflow

Models can generate code and call open-source libraries to reimplement some functions. If traditional software can be used only through a human-operated interface, an agent may route around it:

  • generate a generic geometry file directly;
  • call another simulation service;
  • process data with an open-source library;
  • rely on third-party conversion scripts;
  • move to a competitor with a more accessible interface.

By providing MCP, a vendor can keep its geometry kernel, solver, component models, design rules, and project data as the authoritative execution environment in an agent workflow.

Autodesk's description of MCP emphasizes that the server validates requests, enforces permissions, accesses data, and returns results, rather than allowing the model to bypass the product's internal controls.

Avoiding a Separate Plugin for Every Model

Suppose a software vendor wants to support ChatGPT, Claude, GitHub Copilot, Gemini, Cursor, and Codex.

Without a common protocol, it may need to maintain six tool formats, authentication systems, configuration methods, and lifecycles. Every model-platform update may require another connector update.

With MCP, the vendor can maintain one server while multiple compatible clients discover its tools. Official implementations from Autodesk Fusion and MathWorks already list Claude, VS Code, GitHub Copilot, Codex, Gemini CLI, and other clients.

MCP does not eliminate all adaptation work, but it changes a many-to-many connection:

many models × many software products

into:

model clients ↔ MCP standard ↔ software servers

Opening Existing APIs to More Users

SOLIDWORKS, NX, MATLAB, AutoCAD, and Ansys have long provided macros, scripts, plugins, or programming interfaces.

Those interfaces were designed mainly for developers. An ordinary engineer may know that the software can be automated without knowing how to write a C# COM application, an NX Open plugin, a MATLAB toolbox, or an AutoLISP script.

MCP can wrap those lower-level interfaces in semantic tools that a model can understand:

Read the assembly structure
Find under-defined sketches
Change a material
Check floating inputs
Generate a mesh
Run tests
Read the solver log
Export a STEP file

Users describe a goal; the model chooses tools and organizes the steps; the existing API continues to perform the operation deterministically.

Lowering Learning and Support Costs

Professional engineering applications contain large numbers of commands, modules, and parameters. New users can spend significant time finding one function, while experienced users may need to relearn modules they use infrequently.

Siemens added Copilot to Designcenter X NX so it can use recent commands and the current task to provide operational guidance and reduce the cost of relearning complex workflows.

Proteus ProPilot can inspect the current schematic, program code, and simulation data. It uses the actual MCU wiring to provide peripheral code, component recommendations, troubleshooting, and software guidance.

Not all of these abilities are exposed through a public MCP Server, but they show the same direction: software assistance is shifting from generic documentation search toward an understanding of the user's current project.

Letting Individuals and Enterprises Choose Their Models

No software vendor can guarantee that one model will always fit every user's requirements for capability, cost, latency, privacy, and regional availability.

MCP separates software capability from model selection to a useful degree. Individuals can use a model they already subscribe to. Enterprises can connect approved cloud, private, or local models. The software vendor continues to control engineering objects and operation permissions.

Proteus allows users to choose GPT, Claude, DeepSeek, and self-hosted models. MathWorks' MCP and Agentic Toolkit likewise support multiple coding agents.

Preventing Third Parties from Defining the Interface

When a vendor does not provide MCP, the community often builds one first using an existing API.

Third-party implementations can validate demand quickly, but they may have:

  • inconsistent tool names and parameters;
  • weak compatibility across software versions;
  • dependence on arbitrary script execution;
  • no access to internal identity and permission systems;
  • poor transactions and rollback after a failure;
  • abandoned maintenance.

If a third-party project gains a large user base first, it may become the de facto definition of what the model believes the software can do. A later official server must then contend with established compatibility expectations.

An official MCP implementation is therefore not just another feature. It lets the vendor retain authority over object semantics, permission boundaries, and version compatibility.

“Supports MCP” Actually Describes Four Different States

It is not enough to say that a product either has MCP or does not.

1. The Vendor Provides a Formal MCP Server

The vendor maintains the server, which accesses internal product objects or cloud services directly.

This arrangement is most likely to provide:

  • accurate object semantics;
  • compatibility with product releases;
  • official authentication;
  • enterprise permissions;
  • structured error states;
  • formal support.

2. The Product Has Built-in AI Using Internal MCP or a Similar Interface

Users have context-aware AI inside the product, and the model may access the application through a local interface, even if the vendor does not publish the complete server as a separate developer product.

Proteus 9.1 falls in this direction in the author's environment. Codex can connect to Proteus on local port 8001, read project context, and invoke relevant capabilities. For ordinary users, this connection and ProPilot's built-in experience together link the model to schematics, code, and simulation.

3. The Vendor Has No Dedicated MCP but Provides a Mature API

Third parties, partners, or internal enterprise teams can develop MCP on top of the official API.

The SOLIDWORKS COM API and Siemens NX Open provide such foundations. MCP does not replace them; it organizes them into tools that are easier for models to call.

4. The System Primarily Uses Interface Automation

Software without a stable API must be operated through screenshots, mouse and keyboard input, window controls, or file import and export.

This can still be wrapped as an MCP tool, but it remains RPA or Computer Use underneath. Its stability and semantic precision are lower than direct access to software objects.

The Current MCP Status of Common Software

The following table reflects public information and practical use as of July 2026.

Software or platform Current state Implementer Main capabilities already available
GitHub Formal MCP Server Official Read repositories, Issues, PRs, and code; create Issues or PRs; access code security and Copilot cloud-agent functions
Microsoft Copilot Studio MCP client and enterprise integration platform Official Connect external MCP Servers, synchronize tools and resources, and combine them with OAuth, virtual networks, DLP, and enterprise governance
Google Cloud Managed MCP services and database toolbox Official Connect Google services and enterprise databases, providing controlled query and operation interfaces for agents
Autodesk Fusion Formal local and cloud MCP Servers Official Inspect active documents and perform live modeling commands; manage projects, folders, items, collaborators, and permissions
Ansys product family PyAnsys MCP ecosystem Official Connect Mechanical, MAPDL, Fluent, AEDT, and Lumerical through corresponding PyAnsys automation and simulation capabilities
MATLAB MATLAB MCP Core Server Official Start or connect to MATLAB, inspect and execute code, run scripts and unit tests, and query toolboxes
Simulink Agentic Toolkit and MCP tools Official Read model structure and signals, modify blocks and parameters, resolve variables, inspect models, and run tests
Proteus 9.1 Built-in AI and local MCP connection Official product capability Read schematic, code, and simulation context; modify component values; navigate objects; generate peripheral code; assist troubleshooting
Siemens ecosystem General developer MCP available; NX mainly uses Copilot and NX Open Official and enterprise-built Official MCP searches Siemens products, developer documentation, and technical resources; NX Copilot guides workflows; direct model control can be wrapped through NX Open
SOLIDWORKS No public general-purpose official MCP found; active community implementations Third party Use COM/VBA to read and modify sketches, parts, assemblies, drawings, and properties; perform analysis, export, or search API documentation
AutoCAD Primarily community MCP Third party Use AutoLISP, file exchange, or DXF libraries to create entities, layers, blocks, text, dimensions, and P&ID objects
Blender Primarily community MCP Third party Read scenes; create and modify objects, materials, and lights; render, export, and execute Blender Python

GitHub: From Code Context to Development Actions

GitHub's official MCP Server works in VS Code, Visual Studio, JetBrains IDEs, Xcode, and other compatible clients. It reads repository data and can create Issues, list Pull Requests, start selected Copilot cloud tasks, and invoke code-scanning or secret-detection features. Individual tools continue to inherit GitHub's existing permissions and subscription requirements.

It represents the typical route for a modern platform: capabilities previously spread across a website, APIs, and Copilot are reorganized into a formal entry point that many agents can call.

Autodesk Fusion: A Complete Reference from a Traditional CAD Vendor

Autodesk Fusion provides two MCP Servers with different roles.

The local Fusion MCP connects to the running desktop application, inspects the active document, executes commands, and performs live modeling. Fusion Data MCP runs in Autodesk's cloud and queries or manages Hubs, projects, folders, items, and permissions.

The split is instructive:

Local MCP: operate the current design
Cloud MCP: manage project and collaboration data

Traditional desktop software does not have to move entirely into a browser. A local MCP Server can connect the professional application already running on the workstation to an external model.

Ansys: Adding a Model Interface to a Mature Python Ecosystem

Ansys did not build a new simulation system for large models. It added MCP on top of PyAnsys.

Current PyAnsys documentation lists MCP projects for Mechanical, Fluent, MAPDL, AEDT, and Lumerical, along with PyAnsys Common MCP for establishing a consistent server across products.

Models can organize work around existing PyAnsys capabilities:

Read analysis settings
Inspect materials and boundary conditions
Modify model objects
Generate a mesh
Start a solve
Read logs
Extract results

MCP handles discovery and invocation; Ansys products and PyAnsys still perform the simulation.

MATLAB MCP Core Server can start or connect to a MATLAB session, detect toolboxes, statically inspect code, execute code, run scripts, and run tests. Extension files can add enterprise- or user-specific tools.

Simulink Agentic Toolkit combines MCP Tools with Agent Skills.

Tools read, edit, query, and test Simulink models. Skills contribute model-based design, testing, and engineering practice. Existing tools can inspect system hierarchies, signal flow, and parameters; add blocks and lines; and validate requirements through Gherkin tests.

This reflects a new design principle:

Giving a model permission to operate is not enough. It also needs guidance on how those permissions should be used correctly in the professional domain.

Proteus: Letting the Model See Circuits, Code, and Simulation Together

Proteus is valuable not only because it draws schematics, but because it places microcontroller code and circuit simulation in one environment.

In the author's Proteus 9.1 environment, Codex can connect through MCP on local port 8001 and interact with the active project.

Proteus ProPilot's published capabilities include real-time schematic analysis; access to code and simulation data; generation of SPI, I²C, PWM, and other peripheral code from actual MCU pin connections; component-value changes; object navigation; and help locating circuit or firmware problems. Users can choose among cloud and self-hosted models.

The model can therefore combine:

Schematic connections
Component parameters
MCU pins
Embedded code
Compiler information
Simulation data

It no longer has to infer where a wire goes from a screenshot alone. Proteus is one practical example of MCP and context-aware AI entering traditional EDA, but the same direction is appearing in CAD, CAE, and scientific computing.

Siemens NX: An AI Front Door Exists, While Direct Modeling MCP Has Room to Grow

Siemens publishes an official MCP Server for searching Siemens products, developer documentation, APIs, and technical resources. It currently focuses on information and developer content rather than direct manipulation of NX geometry.

Designcenter X NX includes a built-in Copilot that uses the current task and recent commands to offer workflow guidance, command suggestions, and error information.

NX Open remains the important foundation for deeper modeling control. Enterprises can wrap approved NX Open capabilities in an internal MCP:

Read parts and the feature tree
Query expressions
Change parameters
Check failed references
Run interference analysis
Export a specified format

Siemens is not ignoring MCP. It has adopted the protocol for developer and knowledge access while NX model operations continue to rely on its mature API and built-in Copilot.

SOLIDWORKS: Third Parties Build First on a Mature COM Interface

The official SOLIDWORKS API is a COM programming interface with hundreds of functions. VBA, VB.NET, C#, and C++ applications can access design features directly.

Public SOLIDWORKS MCP implementations are currently community projects.

Some servers provide only API-documentation search so a model can find functions, enumerations, and examples. Others use COM and VBA to operate the application directly, covering sketches, features, assemblies, drawings, analysis, and export. Some projects already expose many tools while their maintainers still label them research, hobby, or Alpha software.

“A third party has implemented it” is not the same as “it is ready for production.” Individuals can experiment; enterprises must reevaluate tool scope, exception handling, version pinning, and permissions.

AutoCAD and Blender: Communities Demonstrate the Demand

Third-party AutoCAD MCP servers use AutoLISP, file exchange, and ezdxf to work with layers, entities, blocks, text, dimensions, views, and P&ID symbols. They can also generate DXF without AutoCAD.

Community Blender MCP servers read scenes, create objects, set materials, render, export, and execute Python. A common architecture installs a plugin inside Blender and communicates with the MCP Server over a local socket.

These projects show how easily software with mature plugin and scripting interfaces can become MCP-accessible.

Arbitrary Python, AutoLISP, or macro execution also expands risk. Once a model can run unrestricted code, its permission can grow from modifying the current design to reading files, launching processes, or accessing the network. Formal products should expose narrow semantic tools instead of only a universal execute_code.

What Official and Third-party MCP Implementations Provide

Official and third-party implementations are not simply good and bad alternatives.

Dimension Official MCP Third-party MCP
Object semantics Direct access to internal objects and state Depends on public APIs, macros, scripts, or file parsing
Version compatibility Can be maintained alongside product releases May fail after software upgrades
Identity and permissions Can integrate vendor accounts and enterprise policies Often inherits the local process's or API key's permissions
Feature scope Usually conservative and limited to supported operations Often covers experimental functions more aggressively
Iteration speed Follows formal release cycles Community development is often faster
Technical support Vendor documentation and support channels Depends on maintainers and the community
Risk May be constrained by licensing, subscriptions, and platform policy May include arbitrary code execution or supply-chain risk

Official MCP is better positioned for identity, project permissions, cloud data, and stable product objects.

Third-party MCP can fill gaps the vendor has not yet addressed or implement workflows specific to one enterprise.

Both are likely to coexist: vendors provide a stable core, while communities and enterprises add specialized workflows.

MCP is not the only technology required to make software agentic.

Software APIs and SDKs

APIs form the execution layer.

SOLIDWORKS COM, NX Open, PyAnsys, MATLAB Engine, and Blender Python actually read objects, change projects, and run calculations. MCP usually sits above them rather than replacing them.

Function Calling

Function Calling lets a model select from functions declared by the developer for one application request.

It is suited to tool use inside one application. MCP additionally defines how independent clients and servers connect, discover tools, obtain resources, and negotiate capabilities. One MCP Server can serve multiple compatible applications.

OpenAPI

OpenAPI describes HTTP paths, parameters, request bodies, response structures, and authentication for general programmatic use.

MCP is designed for models and agents. It adds tool discovery, Resources, Prompts, lifecycle behavior, and model-interaction semantics. Existing OpenAPI services can be wrapped or converted into MCP, but desktop object models still need dedicated adaptation.

A2A

A2A primarily covers discovery, delegation, and task handoff between agents.

MCP connects an agent to tools; A2A coordinates multiple agents. A design agent might delegate verification to a simulation agent, which then calls Ansys through MCP.

RPA and Computer Use

RPA and Computer Use operate graphical interfaces.

They remain useful for legacy applications without APIs, visual checks, and a small number of edge steps, but they are sensitive to layout, language, resolution, dialogs, and product-version changes.

A more dependable order of preference is:

Software API or SDK
      ↓
Official or third-party MCP
      ↓
Controlled scripts and command interfaces
      ↓
RPA or Computer Use

What MCP Means for Individuals

For individuals, MCP's most immediate value is not “complete the entire design from one sentence.” It is reducing repeated explanation.

Previously, a user diagnosing a circuit or model had to:

  • capture the interface;
  • mark components;
  • describe connections;
  • copy code;
  • explain parameters;
  • upload logs.

The model could still misread one pin or unit and begin from a false assumption.

With MCP, it can inspect the current project before answering:

Which devices are not connected to the power net?

Which sketch is not fully defined?

Is this boundary-condition set missing a constraint?

Does the current code match the actual MCU pins?

How did stress and mesh quality change after the modification?

It can also help a new user understand an unfamiliar project, explain object relationships, and recommend the next step.

Software being operable by a model does not make the design automatically trustworthy. Successful compilation does not prove hardware safety. A completed simulation does not prove that its load case is sensible. A rebuilt model does not prove that the part is manufacturable.

A safer individual workflow is:

Read the project
→ Explain the current state
→ Propose a change
→ Ask the user to confirm
→ Execute a limited modification
→ Recompile, rebuild, or solve
→ Inspect results and logs

What MCP Means for Enterprises

For enterprises, the important question is not how many mouse clicks a model saves. It is whether design capabilities can be standardized, authorized, and audited.

An organization can package its own rules as tools:

Check power and ground
Check floating inputs
Check under-defined sketches
Check assembly interference
Check materials and units
Run the standard simulation
Generate a design-review report

Projects can reuse the same checks, and new team members can understand historical work more quickly.

At the same time, enterprises must govern MCP Servers:

  • allow only approved servers;
  • distinguish read-only, recommendation, modification, and high-risk operations;
  • use tool allowlists;
  • preserve before-and-after object differences;
  • record the model, tool, and parameters used;
  • require confirmation for data egress, deletion, and overwrite;
  • create checkpoints and rollback for important projects;
  • treat compiler, rule-checker, and solver output as evidence.

GitHub, Microsoft, and OpenAI have all incorporated server approval, organization policy, tool permissions, and write confirmation into enterprise MCP use. This shows how the central production question has moved from “can it connect?” to “who may connect, what may they do, and what record is left behind?”

What MCP Means for Software Designers

Software traditionally served two interfaces:

A graphical interface for people
An API for programmers

Models introduce a third:

Semantic tools for agents

Model-facing tools should not be expressed as:

Click button 17
Open window 5
Choose item 3 from the dropdown

They should state intent:

Read component connections
Check under-defined sketches
Change the specified material
Run interference analysis
Generate a mesh
Read the solver log
Export the model

A mature engineering MCP should also provide:

  • stable object identifiers;
  • explicit units and coordinate systems;
  • input-range and type validation;
  • a preview of changes;
  • transactions and undo;
  • progress reporting and cancellation;
  • structured error information;
  • software and tool versions;
  • verifiable execution results.

Software designers should not expose hundreds of low-level APIs to the model unchanged. Too many tools, similar names, and complicated parameters increase the probability that the model selects the wrong operation.

A better design recombines lower-level interfaces into a smaller set of semantically clear task tools, then supplies professional Skills, rules, and examples. The model needs not only the ability to call a function, but guidance about how it should be used.

Software gains another way to be used

When a model initiates work in engineering software, the integration must identify objects and units, limit the scope of changes, and return results that can be checked. People need to see, reject, and trace those operations.

MCP adds an interaction path alongside graphical interfaces and existing APIs. Its usefulness depends on how clearly software exposes its operations and how reliably engineers can verify the outcome.