大模型刚开始进入软件时，最常见的形态是在界面旁边增加一个聊天窗口。

用户可以询问某个命令在哪里、一个错误是什么意思，或者让模型根据帮助文件给出操作步骤。这确实降低了软件的使用门槛，但模型与软件之间仍然隔着一层界面：模型能够回答问题，却不一定知道当前项目里真正存在什么，更不能稳定地操作软件内部的对象。

随后出现了另一条路线：让模型读取屏幕截图，模拟鼠标和键盘，像人一样寻找选单、填写参数和点击按钮。

Computer Use 扩大了模型能够操作的软件范围，却没有从根本上解决专业软件中的语义问题。对于 CAD、CAE、EDA 和科学计算软件而言，模型不仅要知道按钮在哪里，还要知道：

  • 当前选中的是哪个零件、面、特征或元器件；
  • 一条线路在电气意义上连接到了哪个网络；
  • 参数使用毫米、英寸、欧姆还是兆帕；
  • 修改尺寸后哪些下游特征会失效；
  • 模拟是否真正收敛；
  • 结果对应的是哪组材料、载荷和边界条件。

当模型开始从“回答软件问题”转向“参与实际工作”，软件也就需要一种新的界面：它既不能只面向编程师，也不能只面向图形界面，而要让模型能够发现、理解和调用软件能力。

Model Context Protocol，也就是 MCP，正是在这样的需求下发展起来。

MCP 最初要解决的不是点击软件，而是连接碎片化

2024 年 11 月 25 日，Anthropic 正式开源 MCP。

当时大模型已经可以生成代码、分析文件和调用函数，但一旦需要访问企业文件、数据库、代码仓库或业务系统，开发者仍然要为每一个数据源单独编写联结器。一个模型应用接入 Google Drive、Slack、GitHub、PostgreSQL 和本地文件系统，往往意味着五套互不兼容的整合。

Anthropic 将这一问题概括为模型被隔离在信息孤岛之外：模型能力不断提高，但真实数据和软件能力仍散落在不同系统中。MCP 因此被设计成一套开放标准，让数据来源和工具只需提供一次标准化服务，就能被多个兼容的模型应用连接。最早公开的参考服务器便覆盖了 Google Drive、Slack、GitHub、Git、PostgreSQL 和 Puppeteer。MCP 的最初两位主要建立者是 David Soria Parra 和 Justin Spahr-Summers。

MCP 的结构受到 Language Server Protocol，也就是 LSP 的启发。

LSP 解决的是编辑器与编程语言工具之间的重复适配问题。过去，每种编辑器都要分别实现 Python、Java、C++ 等语言的补全、诊断和定义跳转；有了 LSP，语言服务器可以同时服务多种编辑器。

MCP 采用了类似思路：

不再让每一种模型应用分别适配每一套软件和数据来源，而是由软件提供标准服务器，再由兼容的模型客户端连接。

MCP 使用 Host、Client 和 Server 架构，通过 JSON-RPC 交换消息。服务器可以公开三类核心能力：

  • Resources：文件、数据库记录、工程对象、日志和其他上下文；
  • Tools：查询、修改、执行、计算和导出等操作；
  • Prompts：经过整理的任务模板和工作流程。

Host 是承载模型和用户互动的应用，Client 负责与某个 MCP Server 建立连接，Server 则把具体系统的数据和操作能力提供出来。

MCP 因此并不是新的求解器、建模核心或自动化引擎。它更像是模型与既有软件能力之间的一层通用界面。

从本地联结器到生产协议

MCP 在 2024 年公开时，首先适合本地文件、开发环境和桌面工具。它真正引起大型软件厂商重视，则与 2025 年的快速演进有关。

2025 年 3 月：远程连接和权限控制开始成形

2025 年 3 月的规范加入了基于 OAuth 2.1 的授权框架，以 Streamable HTTP 替代早期的 HTTP+SSE 传输方案，并增加工具注释，让客户端知道一个工具是否只读、是否具有破坏性。

这一步非常关键。

如果 MCP 只能连接用户电脑上的本地程序，它更像开发者实验工具；当它拥有远程传输、身份验证和权限描述后，企业软件才有条件通过云服务提供 MCP。

2025 年 6 月：工具返回结果变得更适合专业任务

2025 年 6 月的版本增加了结构化工具输出、Resource Link 和 Elicitation。

结构化输出允许工具返回具有明确字段的数据，而不是一段模糊文字。对于工程软件，求解工具可以返回：

求解状态
最大应力
最大位移
危险位置对象 ID
单位
警告数量
结果文件

Elicitation 则允许服务器在执行过程中向用户请求必要信息，例如要求确认材料、单位、文件位置或操作范围。协议同时加强了 OAuth 资源服务器定位和令牌使用安全。

2025 年：大型模型与平台厂商相继采用

MCP 最初由 Anthropic 提出，但很快不再局限于 Claude 生态。

Microsoft 在 2025 年 3 月为 Copilot Studio 推出 MCP 预览，并于 5 月宣布正式可用。连接 MCP Server 后，服务器发布的工具和数据可以自动加入智能体；当服务器更新工具时，Copilot Studio 也可以动态同步，而不必手工重新建立每一个 Action。Microsoft 还把 MCP 接入现有联结器体系，以继续使用虚拟网络、数据防泄漏和多种身份验证机制。

OpenAI 随后在 API、ChatGPT Apps 和智能体工具体系中采用 MCP。开发者可以让模型连接远程 MCP Server，限制允许调用的工具，并为写入操作设置审批要求；ChatGPT 的自定义应用同样以 MCP 作为连接工具和内部数据的重要基础。

GitHub 发布并维护官方 GitHub MCP Server，让不同 IDE 和智能体读取仓库、Issue 和 Pull Request，建立任务，并调用代码安全等功能。组织还可以使用 MCP 策略和登录档限制允许执行的服务器。

Google Cloud 在 2025 年为数据库工具箱加入 MCP，并在同年 12 月宣布为 Google 服务提供官方 MCP 支持。Google 对此给出的原因也很直接：依赖社区服务器要求开发者分别安装和维护多个本地实现，容易形成脆弱的整合，因此需要由服务提供方维护远程、可治理的官方端点。

MCP 至此完成了一次重要转变：

它从 Anthropic 提供的开放连接方案，逐渐变成不同模型、智能体平台和软件厂商共同采用的界面层。

2025 年末：进入中立治理

2025 年 11 月的规范继续增加 OpenID Connect 发现、增量授权、工具显示信息和实验性的 Tasks。Tasks 用于跟踪耗时较长、需要轮询状态或延迟获取结果的任务，对编译、批次处理和工程模拟尤其重要。该版本还正式建立了治理结构、工作组和 SDK 分级制度。

2025 年 12 月，Anthropic 将 MCP 捐赠给 Linux Foundation 下成立的 Agentic AI Foundation。AAIF 的创始项目还包括 Block 的 goose 和 OpenAI 的 AGENTS.md，成员包括 Anthropic、OpenAI、Microsoft、Google、AWS、Cloudflare 和 Bloomberg 等机构。

这一变化减少了软件厂商对“接入竞争对手私有协议”的顾虑。MCP 的治理不再只由某一家模型公司控制，而是逐渐成为中立的开源基础设施。

截至 2026 年 7 月，稳定规范仍为 2025-11-25。计划于 2026 年 7 月 28 日发布的下一版正在进一步弱化协议级会话，转向更适合普通 HTTP 基础设施的无状态核心，并通过扩展机制承载 Tasks、互动式界面等能力。

为什么软件厂商开始把产品做得对模型友好

软件厂商支持 MCP，并不只是为了追随一个热门协议。

真正的变化是：模型正在成为新的软件入口。

过去，用户先开启 CAD、EDA 或办公软件，再从选单中选择功能。未来，用户可能先向 Codex、Claude、Copilot、ChatGPT 或企业内部智能体提出目标：

检查这套电路的供电问题。

修改模型后重新比较应力结果。

找出装配体中的干涉并生成报告。

读取项目状态，建立修复任务并提交代码。

智能体再决定需要调用哪些软件。

当这种工作方式逐渐普及时，软件能否被模型正确发现、理解和调用，就会像文件格式、插件生态和云端 API 一样，成为产品竞争力的一部分。

保住专业软件在工作流中的位置

模型能够生成代码，也可以调用开源库重新实现部分功能。如果传统软件始终只能由人通过界面操作，智能体便可能绕开它：

  • 直接生成通用几何文件；
  • 调用其他模拟服务；
  • 使用开源库处理数据；
  • 依赖第三方脚本完成转换；
  • 转向界面更开放的竞争产品。

厂商提供 MCP，可以让自己的几何核心、求解器、组件模型、设计规则和项目数据继续成为智能体工作流中的权威执行环境。

Autodesk 对 MCP 的定义便强调，服务器负责验证请求、执行权限、访问数据并返回结果，而不是让模型直接绕过产品内部控制。

避免为每一种模型重复开发插件

假设一家软件厂商要同时支持 ChatGPT、Claude、GitHub Copilot、Gemini、Cursor 和 Codex。

没有统一协议时，厂商可能需要分别适配六套工具格式、身份验证、配置方法和生命周期。模型平台每次更新，联结器也可能需要跟着修改。

有了 MCP，软件厂商可以维护一套服务器，再由多个兼容客户端发现其中的工具。Autodesk Fusion 和 MathWorks 的官方实现已经同时列出 Claude、VS Code、GitHub Copilot、Codex、Gemini CLI 等不同客户端。

这不是完全消除适配工作，而是把原来的多对多连接：

多个模型 × 多种软件

转化为：

模型客户端 ↔ MCP 标准 ↔ 软件服务器

把已有 API 开放给更多普通用户

SOLIDWORKS、NX、MATLAB、AutoCAD 和 Ansys 很早就拥有宏、脚本、插件或编程接口。

但这些界面主要面向开发者。普通工程师即使知道软件能够自动化，也未必会编写 C# COM 程序、NX Open 插件、MATLAB 工具箱或 AutoLISP 脚本。

MCP 可以把底层界面包装成模型能够理解的语义工具：

读取装配结构
查询欠定义草图
修改材料
检查悬空输入
生成网格
执行测试
读取求解日志
导出 STEP 文件

用户只需要说明目标，模型负责选择工具和组织步骤，软件原有 API 则继续负责确定地执行操作。

降低软件学习和支持成本

专业工程软件通常拥有大量命令、模块和参数。新用户可能花很长时间寻找一个功能，熟练用户在面对不常使用的模块时也需要重新查阅文件。

Siemens 在 Designcenter X NX 中加入 Copilot，让它结合近期命令和当前任务提供操作指导，减少复杂流程的重新学习时间。

Proteus ProPilot 则能够读取当前原理图、程序代码和模拟数据，结合实际 MCU 接线提供外围装置代码、组件建议、故障分析和软件操作指导。

即使这些能力并不全部通过公开 MCP 服务器呈现，它们体现了同一个方向：软件帮助系统正在从通用文件搜索，转向理解用户当前项目。

允许个人和企业选择模型

软件厂商不可能保证某一种模型永远在能力、成本、延迟、隐私和地区可用性上适合全部用户。

MCP 将软件能力与模型选择适当分开。个人可以使用自己已经订阅的模型，企业可以接入获准的云模型、私有模型或本地模型，软件厂商则继续控制工程对象和操作权限。

Proteus 允许用户选择 GPT、Claude、DeepSeek 和自托管模型；MathWorks 的 MCP 与 Agentic Toolkit 也支持多种编码智能体。

防止第三方替厂商定义界面

当厂商没有提供 MCP 时，社区通常会利用已有 API 先做出一个版本。

第三方实现可以快速验证市场需求，却也可能出现：

  • 工具命名和参数不统一；
  • 不同软件版本兼容性不足；
  • 依赖任意脚本执行；
  • 无法使用软件内部身份和权限；
  • 操作失败后缺少事务与回滚；
  • 项目停止维护。

如果第三方项目首先获得大量用户，它就可能成为模型理解该软件能力的事实标准。厂商后来即使推出官方方案，也要面对既有兼容习惯。

因此，厂商提供官方 MCP 不只是增加功能，也是重新掌握对象语义、权限边界和版本兼容的定义权。

“支持 MCP”其实有四种不同状态

讨论软件是否支持 MCP 时，不能简单地只写“有”或“没有”。

第一类：厂商提供正式 MCP Server

服务器由软件厂商维护，直接访问产品内部对象或云服务。

这类方案通常最容易获得：

  • 准确的对象语义；
  • 软件版本适配；
  • 官方身份验证；
  • 企业权限；
  • 错误状态；
  • 正式支持。

第二类：产品内置 AI，并通过内部 MCP 或类似界面工作

用户能够在软件内使用上下文感知的 AI，模型也可能通过本地界面访问软件，但厂商未必把完整服务器作为独立开发产品公开。

Proteus 9.1 的实际使用便属于这一方向。在本文作者使用的环境中，Codex 可以通过本地 8001 埠连接 Proteus，读取工程上下文并调用相应能力。对普通用户而言，它和 ProPilot 的产品内体验共同构成了模型与原理图、代码和模拟的连接。

第三类：厂商尚未提供专用 MCP，但已有成熟 API

第三方、合作伙伴或企业内部团队可以基于官方 API 开发 MCP。

SOLIDWORKS 的 COM API 和 Siemens NX Open 都属于这一基础。MCP 并不会替代这些界面，而是将它们组织成更适合模型调用的工具。

第四类：主要依靠界面自动化

软件缺少稳定 API，只能使用截图、鼠标、键盘、窗口控制组件或文件导入导出。

这种方式仍然可以接在 MCP 工具后面，但它本质上仍是 RPA 或 Computer Use，稳定性和语义精度都低于直接访问软件对象。

常见软件的 MCP 现状与能力

以下状态以截至 2026 年 7 月的公开数据和实际使用情况为基础。

软件或平台 当前状态 实现方 已经实现的主要能力
GitHub 正式 MCP Server 官方 读取仓库、Issue、PR 和代码信息，建立 Issue 或 PR，调用代码安全与 Copilot 云端智能体等能力
Microsoft Copilot Studio MCP 客户端与企业接入平台 官方 接入外部 MCP Server，自动同步工具和资源，结合 OAuth、虚拟网络、DLP 和企业治理
Google Cloud 托管 MCP 服务与数据库工具箱 官方 连接 Google 服务和企业数据库，为智能体提供受控的数据查询与操作入口
Autodesk Fusion 本地与云端两套正式 MCP 官方 检查活动文件、执行实时建模命令；管理项目、数据夹、条目、协作者和权限
Ansys 系列 PyAnsys MCP 体系 官方 连接 Mechanical、MAPDL、Fluent、AEDT 和 Lumerical，调用相应 PyAnsys 自动化与模拟能力
MATLAB MATLAB MCP Core Server 官方 启动或连接 MATLAB、检查代码、执行代码、执行脚本和单元测试、查询工具箱
Simulink Agentic Toolkit 与 MCP 工具 官方 读取模型结构与信号、修改模块和参数、解析变量、检查模型并执行测试
Proteus 9.1 产品内置 AI 与本地 MCP 接入 官方产品能力 读取原理图、代码和模拟上下文，修改组件数值、导航对象、生成外设代码并协助故障分析
Siemens 生态 通用开发者 MCP 已上线；NX 目前以 Copilot 和 NX Open 为主 官方与企业自建 官方 MCP 搜索西门子产品、开发文件和技术资源；NX Copilot 提供工作流指导，直接建模控制可基于 NX Open 封装
SOLIDWORKS 未见公开通用官方 MCP，社区实现活跃 第三方 基于 COM/VBA 读取和修改草图、零件、装配、工程图和属性，执行分析、导出或查询 API 文件
AutoCAD 社区 MCP 为主 第三方 通过 AutoLISP、文件通信或 DXF 库建立图元、图层、块、文字、标注和 P&ID 对象
Blender 社区 MCP 为主 第三方 读取场景，建立和修改对象、材质与灯光，渲染、导出并执行 Blender Python

GitHub：从代码上下文到软件开发动作

GitHub 官方 MCP Server 可以在 VS Code、Visual Studio、JetBrains、Xcode 和其他兼容客户端中使用。它不仅能读取仓库信息，还可以建立 Issue、列出 Pull Request、启动部分 Copilot 云任务，并调用代码扫描或密钥检测功能。具体工具继续继承 GitHub 原有权限和订阅要求。

它展示的是现代平台软件的典型路线：把原来分布在网页、API 和 Copilot 中的能力，整理成一个可以被多种智能体调用的正式入口。

Autodesk Fusion：传统 CAD 厂商的完整参考方案

Autodesk Fusion 提供两个定位不同的 MCP Server。

本地 Fusion MCP 连接正在执行的桌面软件，可以检查活动文件、执行命令并实时建模。Fusion Data MCP 执行在 Autodesk 云端，用于查询和管理 Hub、项目、数据夹、条目和权限。

这种拆分很有代表性：

本地 MCP：操作当前设计
云端 MCP：管理项目和协作数据

它说明传统桌面软件不必全部迁移到浏览器，仍然可以通过本地 MCP 把正在执行的专业应用连接给外部模型。

Ansys：在成熟 Python 生态上增加模型界面

Ansys 并没有重新为大模型开发一套模拟系统，而是在 PyAnsys 基础上增加 MCP。

当前 PyAnsys 文件已经列出面向 Mechanical、Fluent、MAPDL、AEDT 和 Lumerical 的 MCP 项目，同时提供 PyAnsys Common MCP，帮助不同产品建立统一服务器。

模型因此可以围绕现有 PyAnsys 能力组织工作：

读取分析设置
检查材料和边界条件
修改模型对象
生成网格
启动求解
读取日志
提取结果

MCP 负责工具发现和调用，实际模拟仍由 Ansys 产品与 PyAnsys 完成。

MathWorks 的 MATLAB MCP Core Server 可以启动或连接现有 MATLAB 会话，检测工具箱、静态检查代码、执行代码、执行脚本和测试。服务器还支持通过扩展文件增加企业或用户自己的工具。

Simulink Agentic Toolkit 则进一步结合了 MCP Tools 与 Agent Skills。

工具负责读取、编辑、查询和测试 Simulink 模型；Skills 则提供模型化设计、测试和工程实践知识。现有工具可以读取系统层级、信号流和参数，增加模块与线路，并通过 Gherkin 测试验证需求。

这体现了一种新的软件设计思路：

只给模型操作权限还不够，还要告诉模型在这个专业领域中应当怎样正确使用这些权限。

Proteus：让模型同时看到电路、代码和模拟

Proteus 的价值不只在于能够绘制原理图，而在于它把微控制器程序与电路模拟放在同一个环境中。

在本文作者实际使用的 Proteus 9.1 中，Codex 可以通过本地 8001 埠接入 MCP，与当前工程进行互动。

Proteus ProPilot 的公开能力则包括实时分析原理图、读替代码和模拟数据、根据 MCU 引脚连接生成 SPI、I²C、PWM 等代码、修改组件数值、导航对象并协助定位电路或固件问题。它还允许用户选择多种云端或自托管模型。

这使模型不必只根据截图猜测某根线接在哪里，而可以同时结合：

原理图连接
组件参数
MCU 引脚
嵌入式代码
编译信息
模拟数据

Proteus 是 MCP 和上下文感知 AI 进入传统 EDA 软件的一个实际案例，但它并不是唯一方向。相同思路也正在 CAD、CAE 和科学计算软件中出现。

Siemens NX：已经重视 AI 入口，直接建模 MCP 仍有发展空间

Siemens 已经上线官方 MCP Server，为智能体提供西门子产品、开发文件、API 和技术资源搜索。这个服务器目前主要服务信息和开发者内容，而不是直接操作 NX 几何模型。

Designcenter X NX 则已经加入内置 Copilot。它结合当前任务和近期命令，为用户提供工程工作流指导、命令建议和错误处理信息。

对于更深层的建模控制，NX Open 仍然是重要基础。企业可以将经过批准的 NX Open 能力封装成内部 MCP，例如：

读取零件和特征树
查询表示式
修改参数
检查失效引用
执行干涉分析
导出指定格式

因此，Siemens 的现状不是“不重视 MCP”，而是已经在开发者和知识入口采用 MCP，同时让 NX 的模型操作继续依赖其成熟的产品 API 和内置 Copilot。

SOLIDWORKS：第三方利用成熟 COM 界面先行

SOLIDWORKS 官方 API 是拥有数百项函数的 COM 编程接口，可以通过 VBA、VB.NET、C# 和 C++ 直接访问设计功能。

目前公开的 SOLIDWORKS MCP 主要由社区开发。

一类服务器只提供 SOLIDWORKS API 文件检索，帮助模型寻找界面、列举和示例；另一类服务器通过 COM 和 VBA 直接操作软件，覆盖草图、建模、装配、工程图、分析和导出。部分项目已经提供大量工具，但开发者仍将其标记为研究、业余或 Alpha 状态。

这说明“第三方已经实现”与“已经适合生产”不是同一个结论。个人可以用它探索，企业则需要重新检查工具范围、异常处理、版本锁定和权限。

AutoCAD 和 Blender：社区证明了界面需求

AutoCAD 的第三方 MCP 可以通过 AutoLISP、文件通信和 ezdxf 操作图层、图元、块、文字、标注、检视和 P&ID 符号，也可以在没有 AutoCAD 的环境中直接生成 DXF。

Blender 社区 MCP 能够读取场景、建立对象、设置材质、渲染、导出并执行 Python。其常见架构是在 Blender 内安装插件，再通过本地 Socket 与 MCP Server 通信。

这些项目证明，拥有成熟插件和脚本界面的软件很容易被社区 MCP 化。

但任意 Python、AutoLISP 或宏执行也会扩大风险。模型一旦能够执行未经限制的代码，权限范围可能从“修改当前模型”扩大到读取文件、启动程序甚至访问网络。因此，正式产品更适合提供范围明确的语义工具，而不是只开放一个万能的 execute_code。

官方 MCP 与第三方 MCP 各自实现了什么

官方和第三方不是简单的好坏关系。

维度 官方 MCP 第三方 MCP
对象语义 可直接使用软件内部对象和状态 依赖公开 API、宏、脚本或文件解析
版本兼容 可以随产品版本共同维护 软件升级后可能出现失效
身份权限 可以接入厂商账户与企业策略 常继承本地程序或 API 密钥权限
功能范围 通常较克制，只开放受支持能力 往往更积极覆盖实验性功能
迭代速度 受正式发布周期影响 社区开发通常更快
技术支持 有厂商文件和支持渠道 依赖维护者与社区
风险 可能受许可、订阅和平台策略限制 可能包含任意代码执行或供应链风险

官方 MCP 更适合处理身份、项目权限、云端数据和稳定对象。

第三方 MCP 则更容易填补厂商尚未覆盖的场景，或者针对某一家企业的具体流程进行定制。

两者未来很可能长期并存：官方提供稳定核心，社区和企业在其上增加专业工作流。

MCP 与类似技术分别解决什么问题

MCP 并不是软件智能化所需的唯一技术。

软件 API 和 SDK

API 是执行层。

SOLIDWORKS COM、NX Open、PyAnsys、MATLAB Engine 和 Blender Python API 真正负责读取对象、修改项目和执行计算。MCP 通常建立在它们之上，而不是替代它们。

Function Calling

Function Calling 让模型在一次应用请求中选择开发者预先宣告的函数。

它适合一个应用内部的工具调用；MCP 则进一步规定了独立客户端和服务器怎样连接、发现工具、取得资源和协商能力。同一个 MCP Server 可以被多个兼容应用使用。

OpenAPI

OpenAPI 描述 HTTP 服务的路径、参数、请求体、返回结构和认证方法。

它面向一般程序调用；MCP 则面向模型和智能体，增加了工具发现、Resources、Prompts、生命周期和模型互动语义。已有 OpenAPI 服务可以被封装或转换成 MCP，但本地桌面软件的对象模型仍需要专门适配。

A2A

A2A 主要解决智能体之间的发现、委派和任务交接。

MCP 解决智能体如何连接工具，A2A 解决多个智能体如何协作。例如设计智能体可以把验证任务交给模拟智能体，模拟智能体再通过 MCP 调用 Ansys。

RPA 和 Computer Use

RPA 与 Computer Use 操作图形界面。

它们适合没有 API 的遗留软件、视觉检查和少量边缘步骤，但容易受到窗口布局、语言、分辨率、弹窗和软件版本变化影响。

更合理的优先顺序是：

软件 API 或 SDK
      ↓
官方或第三方 MCP
      ↓
受控脚本与命令界面
      ↓
RPA 或 Computer Use

对个人用户意味着什么

对个人用户而言，MCP 最直接的价值不是“一句话自动完成所有设计”，而是减少重复说明。

过去遇到电路或模型问题，用户需要：

  • 撷取界面；
  • 标出组件；
  • 描述连接；
  • 复制代码；
  • 解释参数；
  • 上传日志。

模型仍可能因为看错一个引脚或单位而从一开始就判断错误。

通过 MCP，模型可以先读取当前工程，再回答：

哪些器件没有接入电源网络？

哪个草图没有完全定义？

这组边界条件是否缺少约束？

当前代码与实际 MCU 引脚是否一致？

修改前后的应力和网格质量有什么变化？

它也可以帮助新用户快速了解陌生项目，解释对象关系，并给出下一步建议。

但软件能够被模型操作，并不代表设计结果自动可信。代码编译成功不等于硬件安全，模拟完成不等于工况合理，模型重建成功也不等于零件能够制造。

更稳妥的个人工作流是：

读取项目
→ 解释当前状态
→ 提出修改方案
→ 用户确认
→ 执行有限修改
→ 重新编译、重建或求解
→ 检查结果与日志

对企业意味着什么

企业使用 MCP，真正需要关注的不是模型节省了多少次鼠标点击，而是设计能力能否被标准化、授权和审计。

企业可以把自己的规范整理成工具：

检查电源与接地
检查悬空输入
检查未定义草图
检查装配干涉
检查材料和单位
执行标准模拟
生成设计审查报告

不同项目可以复用同一套检查流程，新成员也能更快理解历史工程。

与此同时，企业必须对 MCP Server 进行治理：

  • 只允许批准的服务器；
  • 区分只读、建议、修改和高风险操作；
  • 为工具设置白名单；
  • 保留修改前后的对象差异；
  • 记录使用的模型、工具和参数；
  • 对外发数据、删除和覆盖操作要求确认；
  • 为重要工程建立检查点和回滚；
  • 把编译器、规则检查器和求解器结果作为证据。

GitHub、Microsoft 和 OpenAI 都已经把服务器审批、组织策略、工具权限和写入确认纳入企业 MCP 使用方式，这说明 MCP 进入生产环境后的核心问题已经从“能不能连接”转向“谁可以连接、允许做什么、怎样留下记录”。

对软件设计方意味着什么

软件过去主要服务两类界面：

面向人的图形界面
面向编程师的 API

模型进入工作流后，软件还需要第三类界面：

面向智能体的语义工具

面向模型的工具不应该只是：

点击第 17 个按钮
开启第 5 个窗口
选择下拉框第 3 项

而应直接表达任务意图：

读取器件连接
检查欠定义草图
修改指定材料
执行干涉分析
生成网格
读取求解日志
导出模型

一个成熟的工程 MCP 还应具备：

  • 稳定的对象标识；
  • 明确的单位和座标系；
  • 输入范围和型别检查；
  • 修改前差异预览；
  • 事务与撤销；
  • 执行进度和取消；
  • 结构化错误信息；
  • 软件与工具版本；
  • 可核验的执行结果。

软件设计方也不应只把现有数百个底层 API 原样暴露给模型。工具过多、名称相近或参数复杂，都会增加模型选错工具的概率。

更合理的方式是把底层界面重新组合成少量语义清晰的任务工具，并提供专业 Skills、规则和示例，让模型不仅“有能力调用”，还知道“应当怎样调用”。

软件多了一种使用方式

模型进入工程软件后，集成需要准确识别对象和单位，限制修改范围，并返回可以核验的结果。人员也需要能够查看、拒绝和追溯这些操作。

MCP 为图形界面和现有 API 之外增加了一条互动路径。它是否有用，取决于软件能否清楚地开放操作，以及工程师能否可靠地核验结果。