The Windchill REST API, PTC's OData v4 based Windchill REST Services, is a workable base for AI agents when an MCP server sits in between: per-user OAuth tokens instead of one shared account, an explicit configuration spec on every structure call, an allow-list of named operations rather than an HTTP-verb filter, and a per-call audit log.
The four breakpoints
Each of these is visible in the source of a public community Windchill MCP server, Cars-10/windchill-mcp-server, read on 19 September 2026. It calls itself a test bed, and as a test bed it is useful. As a production shape it fails in four places.
01 · Identity
The server reads a single Windchill username and password from its environment and uses them for every call. Windchill then applies that account's rights, across every product and library context it can reach, to every person who asks the assistant anything.
02 · Configuration
Its structure tool calls the GetPartStructure action with navigation criteria that set only the part type and leave the filter at the default. The answer is a real structure, but whether it is latest, released or as-stored depends on a default the user never saw.
03 · Verb
GetPartStructure is an OData action, invoked with POST and a CSRF token. A proxy rule that allows only GET, the obvious way to make an agent read-only, blocks the most useful read. Loosen it to allow POST and every write goes through as well.
04 · Surface
The part tools alone include create, revise, check-in, bulk update and set lifecycle state beside search and structure. A model choosing among them for a question has the power to change released data, and nothing in the tool list distinguishes asking from acting.
The first answer is to wrap WRS quickly: take a community server or write thirty lines, give it a technical user, and let the pilot team try it. It works in a demo, because the demo user has the same rights as the technical user and nobody asks about a restricted product. It fails the first security review for exactly the reasons above, and the fix is not a patch. Moving from a stored password to per-user tokens changes how every tool authenticates, so the prototype is rebuilt rather than hardened.
The second answer is to wait for PTC. That is defensible. In February 2026 a PTC representative wrote that Codebeamer and Windchill are evaluating their roadmap plans for MCP integration, and a vendor server would be maintained through Windchill upgrades by the people who make them.
It still leaves two questions open. There is no date and no scope, so a plant that needs an answer this year is planning around an announcement. And in our assessment a vendor server will cover Windchill and stop there. A PTC server would read Windchill, so the Windchill BOM next to the SAP BOM for the same plant, which is where the expensive questions end, stays your problem either way.
A variant of the first answer deserves its own sentence, because security teams propose it: keep the technical user, but put a gateway in front of WRS that lets only GET requests through. It looks like read-only by construction. It breaks the moment someone asks for a BOM, because the structure read is a POST, and the usual fix, allowing POST for one path, is a hand-written exception in a proxy that nobody reviews again after the pilot. It also leaves the shared account in place, which was the larger problem.
The architecture below is the third answer: a thin server of your own, on the API PTC already supports, that makes the four decisions explicitly and can be replaced or narrowed the day PTC ships something better.
The architecture
In call order, top to bottom. Each layer answers one of the four breakpoints; the governance panel holds what applies to all of them. None of the layers is specific to Claude: any client that speaks the Model Context Protocol sees the same tools, and the same server can later hold the SAP tools the comparison questions need.
01
The agent sees eight or so named tools, each mapped to one WRS entity set or action with fixed parameters. The server allows GetPartStructure because it is on the list, and refuses every other action or entity set, whatever the HTTP verb. Read-only is a property of the list, not of GET.
02
The user signs in with your identity provider; the server obtains a WRS token for that user through OAuth with the authorization code flow and caches it per session. No Windchill password is stored anywhere. The CSRF token for POST calls is fetched per user session, because it is a session artefact, not a permission.
03
Every structure tool takes the configuration as an input with a stated default, usually latest released, and returns the configuration it used next to the result. A user who wants as-stored asks for it; nobody gets it by accident.
04
Each call writes user, tool, arguments, configuration and result count to a log your team already reads. A fixture of twenty to thirty real questions with known answers runs after every Windchill or WRS upgrade, so a changed response shape is caught before a user sees it.
Covered versus still needed
| Concern | Covered by WRS | Additionally needed in the server |
|---|---|---|
| Data access | OData v4 entity sets and actions for parts, documents, changes and workflow | A short list of named tools; no free OData query reaches the model |
| Authentication | OAuth with the authorization code flow, so tokens can be issued per user | Token per asking user from your identity provider; no shared account, no stored password |
| Authorisation | Windchill applies its context, team and lifecycle rules to whoever is authenticated | Making sure the authenticated user is the person asking, on every call |
| Configuration | Navigation criteria on structure actions | A required, visible configuration input with a stated default, echoed in the answer |
| Change protection | CSRF protection on state-changing requests; the community server fetches one and sends it with its POST calls | An allow-list. CSRF stops forged browser requests; it does not stop an agent holding a valid token |
Read the right-hand column as the specification of the server. Every row in it is small on its own; together they are the difference between an agent that answers engineering questions and one that a security review will not let near Windchill. None of them needs a change to Windchill itself, which is why the server can be built against a staging system in weeks rather than as a PLM project.
Counterintuitive
The points that are easiest to miss when an agent is first put on WRS. Each follows from the breakpoints above, and each is cheap to get right before the first tool is written and expensive afterwards.
The configuration as the argument
An excerpt of the server policy. Everything else in the file is detail: timeouts, logging targets, the mapping of your soft attributes. These three lines are the architecture, and each one closes a breakpoint from the top of this post. The entity set and action names are the ones the WRS ProdMgmt and ChangeMgmt domains use.
# windchill-mcp policy (excerpt): three lines carry the architecture
auth: oauth_authorization_code # every WRS call runs as the asking user; no stored password
structure_config: required # no BOM without a stated configuration, returned with the answer
allow: # named operations; the HTTP verb grants nothing by itself
- ProdMgmt/Parts:read
- ProdMgmt/Parts/PTC.ProdMgmt.GetPartStructure # a POST, allowed because it is named
- ChangeMgmt/ChangeRequests:readThe test that it works: call the structure tool as two users with different contexts on the same part. If the answers differ where Windchill says they should, identity is carried through; if they are identical, the server is still seeing too much.
When a rejected answer is right
A quick wrapper with one technical user is fine for a sandbox holding data everyone may see, or for a PLM administrator exploring the API alone. Waiting for PTC is right if you only need Windchill, have a date from your account team and no question that crosses into SAP. For everything else, the build is described on our page on Windchill integration for Claude and other agents, including the first tool list and the fixed-price blueprint.
It is enough as a base and not enough on its own. WRS gives an OData v4 interface to parts, documents, changes and workflow, and supports OAuth. It does not decide which operations an agent may call, which configuration a structure answer is valid for, or how a call is attributed to the person who asked. Those three decisions are the server you build on top.
Only for a sandbox with data everyone may see. A service account answers every user with its own rights, which in Windchill are usually wider than any engineer's across products, libraries and lifecycle states. WRS supports the OAuth authorization code flow, so tokens can be issued per user; that is the path we take for anything beyond a demo.
Scoping is a two-week Readiness Blueprint at €4,900 fixed: tool list, identity proof on staging and a costed build plan. A first production server is usually a use-case pilot from €15,000. Whether agent access needs further Windchill licences is a question for your PTC account team, not something we can answer from outside. All prices are net and exclude VAT.
Then we operate it, or nobody should build it yet. The server is your code in your environment either way, with runbook and evaluation fixture handed over. If you want us to keep it running through Windchill upgrades, monitoring starts at €3,000 per month, and an engineer allocated to it is a separate rung on the same price ladder.
It does not help where the answer is not in Windchill's data. Geometry questions need CAD tools, not WRS. Heavily customised soft types may need a WRS domain extension before any agent can read them. And if PTC ships an MCP server for your release, re-evaluate: its tool list and identity model decide whether you still need your own.
Next step
Thirty minutes with the architect who would build it. Bring your Windchill release and your authentication set-up; we tell you which of the four breakpoints applies to you and what the first tool list would be.