Cameo migration from a live session
Same translation, but it can ask. Stereotypes, state machine triggers and types get resolved by querying the open project instead of being inferred from a name in a file.
CameoWrites · gated
The problem this solves
A file export freezes whatever the exporter happened to include, and every ambiguity in it has to be guessed at. Read the live project and the guessing stops — but the same bridge that lets you read can also write, and the model on the other side may be under Teamwork control or mid-review, where an unexpected edit is unrecoverable.
How it works
The same translation, reading the open project directly so nothing has to be inferred from a file. Resolves stereotypes, triggers and types by querying them rather than guessing, and treats Cameo as strictly read-only: it refuses to write, save or run a macro even though the bridge would let it.
01
Check both connections first
Cameo status and capabilities including the client compatibility flag. If it reports incompatible, it stops and says the plugin and Python server are out of sync rather than proceeding with partial tooling.
02
Read-only on Cameo, without exception
Never create, modify or delete an element, never save the project, never execute a macro however convenient. If a read is only available through a macro, it says so and does without.
03
Use what a file cannot give you
Resolve stereotypes and types by querying them, read triggers and state behaviours explicitly, read diagram contents for grouping context only, and ask you to select elements in Cameo when scope is ambiguous.
04
Say when it is sampling
On a large project it pages through containment rather than pulling the whole tree, and never presents a sample as a complete count.
Installing the bridge
A one-time install. The bridge is a community project under the MIT licence, not a Dassault product. It needs CATIA Magic or Cameo Systems Modeler 2024x or newer, a Java 17 JDK available to Gradle, Python 3.10+ with pip, and Gradle 8.x.
git clone https://github.com/ajhcs/cameo-mcp-bridge.git cd cameo-mcp-bridge export CAMEO_HOME="/path/to/your/CatiaMagic" export JDK17_HOME="/path/to/jdk-17" ./install.sh
- 01The script builds the Java plugin, deploys it into $CAMEO_HOME/plugins/com.claude.cameo.bridge/, creates a virtualenv, installs the Python MCP server, and registers it with Claude Code where the CLI is available.
- 02To register manually: claude mcp add cameo-bridge --scope user -- /absolute/path/to/mcp-server/.venv/bin/python -m cameo_mcp.server. For other clients, configure stdio transport with the venv interpreter and the command -m cameo_mcp.server.
- 03Restart CATIA Magic, open a project, and check the status. A 404 on a tool after an update means the plugin and server are out of sync: rebuild, redeploy, restart Cameo.
- 04Add the Dalus MCP in the same client.
Before installing, know that the bridge is intended for local development only. It binds to localhost with no authentication, wildcards CORS, and includes a macro tool that runs arbitrary Groovy inside the Cameo JVM with full filesystem, network and classloader access. In a regulated or defence environment that is an IT conversation first. It also works against the project open in your client: Teamwork support is read-only probes, and full Teamwork project support is listed as a wanted contribution.
cameo-mcp-bridge on GitHubThe prompt
You are migrating a SysML v1 model from a live Cameo or MagicDraw
session into the Dalus model [model name], reading through the Cameo
MCP bridge and writing through the Dalus MCP. This is a translation
between two languages, not a copy. Your first duty is to be honest
about what translates cleanly, what translates approximately, and
what does not translate at all.
CHECK BOTH CONNECTIONS BEFORE ANYTHING ELSE. Call the Cameo status
and capabilities tools and report what comes back, including the
client compatibility flag. If it reports incompatible, stop and say
the plugin and Python server are out of sync rather than proceeding
with partial tooling. Confirm a project is open and name it back.
Confirm the Dalus model is reachable.
TREAT CAMEO AS STRICTLY READ-ONLY. Read the model, write only to
Dalus. Never create, modify or delete a Cameo element, never save the
Cameo project, and never execute a macro, however convenient it would
be. The user's model may be under Teamwork version control or
mid-review, and an unexpected edit there is unrecoverable from this
side. If a read you need is only available through a macro, say so
and do without it.
CONFIRM FIRST, in one message: which Dalus model; whether the whole
project is in scope or named packages only; whether this is a first
migration or a re-import updating a previous one; and what the result
is for, since a model imported for stakeholder publication needs
different completeness from one that will become the working model.
Ask anything else in the same message. Then begin.
SURVEY BEFORE MAPPING. Walk the containment tree and query elements
by type, and report what the project contains:
- Blocks, parts, part properties and package structure.
- Ports of each kind and their types.
- Connectors, item flows and information flows, with what they
convey.
- Interface blocks and their flow properties.
- Value properties, value types and units.
- Requirements, and every satisfy, verify, derive, refine and trace
relationship.
- Constraint blocks and parametrics.
- State machines with transitions, triggers and state entry, do and
exit behaviours; activities; interactions.
- Diagrams by type and count.
- Applied profiles and stereotypes, listing custom profiles
separately from the standard SysML ones, since custom profiles are
where the team's own method lives and are the hardest part of any
migration.
On a large project, page through containment children rather than
pulling the whole recursive tree, and say clearly when you are
sampling rather than enumerating. Never present a sample as a
complete count. Deliver the survey before proposing anything: it is
useful to the user even if they stop here.
USE THE LIVE CONNECTION FOR WHAT A FILE EXPORT CANNOT DO, and say
when you are doing it:
- Resolve a stereotype, profile or type by querying it directly
rather than inferring it from a name.
- Read state machine triggers and state behaviours explicitly rather
than approximating them.
- Read a diagram's contents to learn which elements the team treats
as belonging together, and use that to inform grouping. Use it for
context only, never to recreate layout.
- Ask the user to select elements in Cameo when scope is ambiguous,
then read the selection. That is faster and less error-prone than
describing a package path in words.
- Re-query rather than guess whenever something is unclear. This is
the advantage this route has, and not using it wastes it.
CLASSIFY EVERY ELEMENT TYPE FOUND INTO ONE OF FOUR, shown as a table
before importing anything:
- TRANSLATES CLEANLY: a direct SysML v2 equivalent exists.
- TRANSLATES APPROXIMATELY: an equivalent exists but the semantics
differ. State the interpretation you are making, per type.
- CARRIED AS ANNOTATION: no structural equivalent, so content is
preserved as attributes or documentation. Custom stereotype tagged
values belong here by default: the values are the team's data and
must not be lost even where the stereotype has nowhere to go.
- DOES NOT TRANSLATE: reported with counts and reasons, not
imported. Diagram layout is the obvious case, and recreating it in
a tool that generates views is a redrawing rather than a
translation. Say so rather than producing an approximation.
Never move an element type into a higher category to make the
migration look better.
NAMES AND IDENTIFIERS: preserve names exactly. Store the Cameo
element ID on every imported element as an attribute, since that is
what makes a re-import safe and lets the team trace back. Report
collisions with existing Dalus elements; never auto-rename.
REQUIREMENTS: text verbatim, never paraphrased, merged or split. The
requirement ID property becomes the customer ID, preserved exactly,
never renumbered. Satisfy becomes allocation, verify becomes
verification linkage, derive becomes derivation. Custom requirement
stereotype tagged values carried as attributes. Report the count of
each relationship type converted and any whose ends could not both be
resolved.
VALUES AND UNITS: carry value properties across as typed variables
with units, say which unit mapping you applied, and report untyped
values rather than assuming SI.
DRY RUN, before any write to Dalus: the survey, the four-category
table, counts to be created by type, the first five and last five
requirements in full as they will land, collisions, unresolved
references, and everything in the does-not-translate category.
Reconciliation arithmetic:
elements surveyed = imported cleanly + imported approximately
+ carried as annotation + not imported
If the numbers do not reconcile, stop and say so. Suggest importing
into a Dalus branch so the whole pass can be discarded in one step.
Wait for approval.
IMPORT in dependency order: packages and types, then structure, then
relationships. If anything fails partway, stop, report exactly what
was created and what was not, and do not improvise. If the Cameo
connection drops mid-import, stop rather than continuing from partial
data, and report where you stopped.
ON RE-IMPORT: match on the stored Cameo element ID, never on name.
Report new, changed with both versions, unchanged, and Dalus elements
whose source ID is no longer present. Never delete on the strength of
an absence, since a narrower scope looks identical to a deletion.
FINAL REPORT: the arithmetic against actuals; the four-category table
as executed; unresolved references and what to include next; custom
profile data carried as annotation and where it landed; and a plain
paragraph on how complete the migration is and what a human should
check first. Offer, do not execute: generating a specification
document from the migrated model to compare against their Cameo
report output, publishing a stakeholder review for people who cannot
open Cameo, and re-running as a drift check while both tools run in
parallel.Replace the [bracketed] placeholders with your model and project names.
What you get
A survey of the open project, with custom profiles listed separately
The four-category table, as proposed and again as executed
Requirements with text and IDs verbatim, Cameo element IDs stored
Reconciled counts, and a plain read on how complete the migration is
Dalus + Cameo
Reads the project open in your client through the community MCP bridge, and writes only to Dalus. The prompt refuses the write, save and macro capabilities the bridge exposes, because the model on the other side may be under Teamwork version control and an unexpected edit there cannot be undone from this side.
Nothing is written until you approve it. The prompt carries the gate: the agent shows the full change set and waits, whether the target is the model or a system it reaches through a connector.
Common questions
Is the bridge an official Dassault product?
No. It is a community project under the MIT licence. Read the warning above before installing: it binds to localhost without authentication and ships a macro tool that executes arbitrary Groovy inside the Cameo JVM. In a regulated or defence environment that is a conversation with IT before it is a conversation with engineering.
Can it change anything in Cameo?
The bridge can. The workflow will not. It never creates, modifies or deletes an element, never saves the project, and never runs a macro, even where doing so would be the easier path to a read it wants. Your project may be under Teamwork control or mid-review.
When is this better than the XMI route?
When ambiguity is expensive: custom profiles to resolve, state machine triggers and behaviours to read exactly, or a scope you would rather select on screen than describe in words. The XMI route needs no installation and works air-gapped, so it is the better first move for an evaluation.