At INCOSE IS 2026 in Yokohama, two requirements vendors had the same announcement on their slides. Siemens had added an MCP server for Polarion, and Jama Software had introduced one for Jama Connect. That's according to SodiusWillert's write-up of the event, which also noted that AI dominated the agenda. When two unrelated vendors ship the same plumbing in the same year, it's worth asking what the plumbing is for.
MCP stands for Model Context Protocol. It's a standard way for an LLM-based agent to call tools and read data from another system. For systems engineers, the interesting question is whether it can give an agent safe, structured access to a real model rather than a pasted text export.
Why agents struggle with models today
Most AI-in-MBSE demos work on text. You copy requirements into a chat window, get suggestions back, and paste them in by hand. That's useful, but it isn't engineering work on the model itself.
A SysML v2 model is a graph of typed elements with relationships, owned by a repository and exposed through a standardized API. A paper at the DESIGN 2026 conference in Dubrovnik, by Bazzal and colleagues, makes the point that SysML v2 brings a new metamodel and standardized APIs that open the door to automating MBSE tasks with generative AI. The same authors argue that existing LLM approaches handle complex SysML v2 API operations poorly, which limits interoperability.
That's the gap MCP is meant to fill. Instead of asking the model to learn the raw API from documentation, you put a server in between that offers a small set of well-described operations.
What an MCP layer actually does
The idea is simple. The agent doesn't talk to your repository directly. It talks to an MCP server, which translates a narrow, documented set of tool calls into API requests and returns results in a form the model can use.
The authors of the DESIGN 2026 paper propose a framework for building MCP servers for SysML v2, and they present it as a foundation for agentic MBSE that works across tools and generative AI systems. Worth noting: the page we could verify holds only the abstract, so it describes a framework, not benchmark results. Nobody should read it as proof that agents now model reliably.
The practical appeal is separation of concerns:
- The server decides which operations an agent may perform. Read-only access is a perfectly good starting point.
- The tool descriptions steer the model toward valid queries instead of improvised ones.
- Swapping the LLM or the modeling tool doesn't mean rewriting the integration, at least in principle.
Where it fits in a tool stack
The IS26 coverage shows MCP appearing in more than one layer. On the requirements side there are the Polarion and Jama Connect servers. Tracespace positioned itself as an AI native requirements platform built on a graph database so agents can reason about quality, consistency and traceability. SodiusWillert itself listed enabling LLMs and agentic workflows as a building block of a digital engineering environment.
On the modeling side, SysML v2 support is now broad enough that an agent could have several targets. Cameo and CATIA Magic 2026 offer SysML v2, Obeo showed Capella alongside SysON, which is built on SysML v2, and Dalus is a SysML v2-native platform. Each handles the standard API in its own way, so an MCP server written against the standard API is only as portable as the API support behind it. Check that before you plan around it.
A sensible first workflow is a traceability check. The agent reads requirements from the requirements tool, reads allocated elements from the model, and reports gaps. It doesn't write anything. A human reviews the list.
What it won't solve
MCP is plumbing. It doesn't make the model on the other end any smarter, and it brings its own problems.
Hallucination hasn't gone away. A recurring theme at IS26 was pairing LLMs with ontologies to reduce hallucinations, with two industrial talks from China focused on it. Structured access helps the agent see the right elements. It doesn't guarantee that its conclusions about them are right.
Write access is a governance question. If an agent can create or edit elements, you need branching, review and audit trails before you let it. Version control for SysML v2 models is still maturing, so start read-only.
Security surface grows. Every server that exposes engineering data to an agent is another thing to authorize, log and review, especially in export-controlled programs.
Evidence is thin. The research is early, and the vendor announcements are announcements. We haven't seen published accuracy numbers for agents editing real SysML v2 models. Pilot on a non-critical subsystem and measure.
Standards for the agent layer aren't settled. The SysML v2 API is a standard. The conventions for what tools an MCP server should expose are not, so two servers for the same repository may behave differently.
A reasonable way to start
If you want to test this without betting a program on it, keep the scope tight.
- Pick one read-only task with a clear right answer, such as finding requirements with no allocated element.
- Run it against a copy of the model, not the live baseline.
- Compare the agent's output with a manual check, and record the misses.
- Only then consider narrow, reviewable write operations on a branch.
Treat the first month as an experiment about your data quality as much as about the agent. Messy naming and missing relationships will show up immediately.
Bottom line
MCP isn't a modeling breakthrough. It's a connector, and a useful one if your models sit behind a standard API. The vendor momentum from IS26 and the early research suggest agentic access to SysML v2 models is coming whether or not you plan for it. The teams that benefit will be the ones with clean models, clear permissions and a habit of checking what the agent actually did.
Sources: SodiusWillert, "Impressions of INCOSE IS 2026"; Bazzal et al., "Model context protocol for MBSE: a unified interoperable agentic framework for systems modelling," Proceedings of the Design Society (DESIGN 2026).