Hand-author an MDG Technology

Goal

Write the MDG Technology XML for a modeling language, with stereotypes, tagged values, toolbox pages and diagram types, then deploy and test it. For an MDG author. You end with a technology file that parses, deploys, and creates correctly stereotyped elements with their tagged values, tested on scratch content.

Where it runs

This scenario needs the MCP server. Computer use covers its UI steps.

Before you start

• The start-of-session check and, if the repository may already carry a language, Assess the language situation.
• No source model for this technology in any repository. If one exists, use Build an MDG Technology from a source model instead.
• A scratch model to test in, not a production model.
• A short technology id. EA rejects ids over 12 characters silently. If you let AI Power Tools write the file, the effective limit is 7 characters, because it also creates <id>-Diag and <id>-TB.
• UTF-8 as the file encoding, with the declaration and the bytes agreeing. EA rejects the file outright if they do not.
• A folder to write to that is not on EA's MDG search path (Assess the language situation, step 3).

An MDG Technology file has three parallel sections inside one root: a UML profile (the stereotypes and their tagged values), a diagram profile (custom diagram types) and one or more toolboxes (the palette pages EA shows for each diagram type). The technology id must match everywhere it is referenced. A mismatch is the most common reason a toolbox fails to resolve.

Writing the XML directly treats the file as the source of truth. ea-mdg-author writes the file and ea-mdg-deploy tests it. The Westbrook illustration builds a subset of WBA: three stereotypes (WBABusinessApplication, WBABusinessService and WBAAIModel), the six base tagged values, and one diagram type with one toolbox page.

Steps

1. AI with computer use; otherwise you If EA is not running or the model is not open, start EA and open it. AI Power Tools ea-mdg-assess confirms this is the right approach (assess_mdg_situation, get_mdg_from_runtime).
2. You Confirm direct XML. It is a one-way choice.
3. AI ea-mdg-author designs the language: stereotypes, aliases, base metaclasses, tagged values, toolbox pages and diagram types.
4. You Approve the design. It is customer-visible text: names and aliases appear in menus.
5. AI Power Tools ea-mdg-author writes the technology file, either directly from the skill's skeleton or from an intermediate description of the metamodel that AI Power Tools turns into the file (write_mdg_xml). AI Power Tools writes UTF-8 and checks every id before it writes, and it reports an id that is too long by name.
6. AI Power Tools ea-mdg-author reads the file back (parse_mdg_xml) and compares what it finds with what you intended: stereotype count, names, metaclasses and tagged values. Install and deploy both report success on a file that is missing content, so this is the only check that catches an emitter gap.
7. AI ea-mdg-author checks namespace consistency, by checklist. The technology id, the top-level documentation id and the profile's documentation id all match. Every toolbox entry reads <id>::<Stereotype>. The diagram profile's toolbox property names the toolbox. The pattern the skill teaches sets it to the toolbox page's name. The shipped Westbrook technology instead names the toolbox's own UML profile, with its diagram profile named WBA, and its diagram types resolve and switch the toolbox on. Which form resolves depends on how the file is assembled, so try yours on a scratch diagram before relying on it. A toolbox property that matches nothing leaves the diagram type unbound, and the toolbox empty.
8. You Decide whether to ship a companion rules file. Do not embed validation in the technology file's script section, which runs inside EA's script engine, out of reach of AI Power Tools. Ship a companion <tech_id>_rules.yaml and run it with ea_validate, as in Author a ruleset.
9. You Choose where the technology goes: into the model at Location: Model, into the model at Location: Project, or onto this machine only. See Deploy an MDG Technology and prove it works. ea-mdg-deploy carries the deployment. A hand-authored file reaches Location: Model only through EA's own Import MDG Technology, with Import to Model, a UI step that is AI with computer use; otherwise you. The other UI steps (reading the screen after an import, restarting EA, and checking the toolbox and tagged values in EA's window) are also AI with computer use; otherwise you, as set out in Deploy an MDG Technology and prove it works. Prefer Location: Model for a technology with toolbox pages, because Location: Project keeps none.
10. AI Power Tools ea-mdg-deploy tests with real content, after EA has been restarted: it creates an element of each stereotype and a diagram of each custom type in a scratch package, and reads the tags back.
11. You Approve the optional migration of existing elements. Deploying a technology does not change existing elements. The skill finds candidates with a read-only query, shows them, and updates each through AI Power Tools (update_element), never with a direct database write, because EA's cache will not see one. It then re-runs the rules file.

Design rules. Base a standalone custom technology on standard UML types (Class, Component, Activity). Basing it on an ArchiMate or BPMN shape name makes elements invisible in the Project Browser tree when that technology is not active at project scope, though they still appear on diagrams and in queries. Carry the ArchiMate concept in the stereotype name and tagged values. Tagged value types are enumeration (not enum) and String (capital S). bgcolor is a Windows color integer: blue times 65536, plus green times 256, plus red.

Reference data. The file AI Power Tools writes has no reference data: the list of allowed values for an enumeration is written, but a technology installed from that output alone gives free-text fields where a closed list was intended. EA shows a dropdown from a file you author by hand with the reference data included. Say so when you hand the technology over.

Prompts to use

Opening

Follow-ups

Recommended models

Ratings are guidance based on the kind of reasoning the skill needs, not measured benchmarks.

Checking the result

• Accurate. The parsed file matches the approved design: names, aliases, metaclasses and tag types. Every id is within the limit and every namespace reference matches. In EA, after a restart, a diagram of the custom type shows its designed toolbox page, and a placed element shows <Tech>::<Stereotype> with its tagged values.
• Complete. Every designed stereotype, tag, toolbox page and diagram type is present. Every stereotype is on a toolbox page: a stereotype on no page ships invisible. The runtime reading for the technology id reports the stereotype and diagram counts the design has.
• Nothing unintended changed. Only the scratch content changed. The same technology id is not stored at two Locations, and not at a Location and as a file on the machine (Deploy an MDG Technology and prove it works).

Variations

• Change an existing hand-authored technology. Edit the XML, bump the version, repeat steps 6 to 10, and redeploy. Check first that no source model exists.
• Add connector relationships and Quick Linker rules. Quick Linker rules live on the source stereotype. Add them only with a connector stereotype: a plain relationship already appears in EA's default menu, and hiding the default menu without a rule produces an empty, apparently broken menu. The Westbrook technology declares three connector stereotypes, Uses, Flows and realizes, and its own rules use them: a vendor system, for example, offers Uses to a technology node. A connector stereotype beyond those three is a proposed extension, not part of the Westbrook technology.
• Generate the file from data. Start from the intermediate metamodel, or from a census (Generate an MDG Technology from current usage).

Limitations

• Silent failures are common here. Ids over the limit, a toolbox string mismatch and an encoding mismatch all fail without an error you can read. The read-back and the screen test are the checks.
• A technology id has two limits. 12 characters in EA, and 7 when AI Power Tools derives the other ids.
• Deploying does not migrate existing elements.
• Validation uses the rules file, not the technology file's script section.
• EA caches the technology. A restart is needed after a deploy before the toolbox is judged, and a technology removed through automation can persist until a restart.
• A hand-authored file reaches Location: Model by a UI step. The operation that stores a file in the model writes it at Location: Project, which keeps no toolbox pages, and its reply lists what it did not store.