PTC Brings MCP to CAD With a FeatureScript Server

FeatureScript is Onshape's most interesting oddity: a language of its own that lets an engineer write their own parametric operations, compile them inside the browser and use them as if they had shipped with the product. PTC has just connected that language to the Model Context Protocol with an MCP server aimed at AI-assisted CAD automation, according to the note published by ARC Advisory Group.

The news looks minor and it is not. Almost everything seen so far under the «AI and CAD» label has been mesh generation or assistants that suggest the next step in the interface. The angle here is different: exposing a textual, deterministic and verifiable language to an LLM client through a standard protocol.

What was released

An MCP server is a process that exposes tools and resources to a model through a fixed contract. The model does not improvise HTTP calls or guess parameters: it discovers which tools exist, with which schema, and calls them. Applied to FeatureScript, the reasonable reading is that the model can write feature code, evaluate it against the Onshape environment and get back either the result or the error.

The ARC coverage is short, so it is worth checking the fine print in PTC's documentation before building anything on top: which tools it exposes exactly, how it authenticates against the Onshape account, which operations are read only and which write to real documents.

Why it matters

What matters is not that yet another MCP server exists. It is who publishes it. Since Anthropic released MCP in late 2024, much of the catalogue has come from the community, with servers that wrap third party APIs through reverse engineering and break as soon as the vendor changes an endpoint. When the software vendor ships its own, three things change: there is maintenance, there is a supported authentication model and there is someone to complain to.

On top of that, FeatureScript fits LLMs better than almost any other CAD surface. It is text, it is evaluated inside Onshape and it returns concrete errors when the geometry does not close. That enables a closed loop of generate, run and fix, which is exactly where models perform. The difference with an «AI designs a part» demo is that verification comes built in here.

Who it is useful for

Three profiles with an immediate use case:

1. Engineering teams with internal libraries of custom features, who today spend hours maintaining code only two people understand.
2. Manufacturers running product configurators, where every variant is a combination of parameters and the expensive part is translating customer requirements into geometry.
3. Integrators already building pipelines across PLM, ERP and CAD who can now put a model in the middle without writing a bespoke connector.

For everyone else it is early, and that is worth saying. CAD is not a domain where an approximate answer will do: a miscalculated wall thickness passes review, enters manufacturing and costs money. Any serious rollout starts with read only permissions, human review of anything touching a production document and traceability of what the model generated and with which prompt.

How it fits if you work with Claude

An MCP server is client agnostic. If PTC's follows the specification, you declare it in claude_desktop_config.json or add it from Claude Code like any other. From there, the pattern that has worked best for us is not leaving the server bare: wrap it in a skill carrying the team's conventions, feature naming and validation criteria, and delegate long tasks to a subagent that does not drag the whole conversation context along.

That an industrial vendor of this size publishes its own MCP server says more about the protocol's maturity than many product announcements, because it implies support, a lifecycle and customers asking for it. That said, between shipping a server and an engineering department letting it touch production documents there is a gap measured in months.