AI Agents Meet Projectional Editing: Portalon for MPS

AI coding agents have changed how many teams work with text-based codebases. An agent such as Claude Code can read, refactor, and test a repository of .java, .ts, or .py files with remarkable fluency. This works well because these agents were trained on large amounts of plain text, and plain text is exactly what a conventional codebase provides.

Projects built with JetBrains MPS are in a different situation. MPS is a projectional language workbench: there is no textual source code to parse. Models are abstract syntax trees, persisted on disk in a verbose, ID-heavy XML format that was never intended for human consumption. If an agent is pointed at these .mps files directly, it usually struggles; the distance between the XML representation and the language concepts it encodes is too large to bridge reliably. In practice, letting an LLM edit the XML directly works far less well than one might hope. Therefore, teams working with MPS have so far benefited little from agentic tooling.

In this article we present Portalon, an MPS plugin developed at itemis that connects AI agents to the live MPS model. We also explain why we consider it worthwhile to build such a tool ourselves, even though JetBrains has announced a comparable component for MPS 2026.1.

Working on the live model instead of the XML

An obvious approach would be to make the persisted XML easier for agents to read. However, this addresses the symptom rather than the cause. A running MPS instance already holds the model in exactly the form an agent needs: a clean, well-structured AST, together with full knowledge of concepts, properties, children, references, scopes, and type rules. If an agent can access this live model through a structured API — reading and modifying nodes the same way MPS itself does — the file format becomes irrelevant. There is no XML parsing, no brittle text editing, and no risk of broken references; every change is structurally valid by construction.

This is the approach Portalon takes. Note that the MPS instance does not have to run as an interactive IDE for this: it can also run headless, and most of the functionality remains available, except for the tools that genuinely require the IDE.

What Portalon provides

Portalon is an MPS plugin that runs a server based on the Model Context Protocol (short: MCP) inside the MPS process. It exposes the currently open project to any MCP-capable agent, e.g., Claude Code. The agent connects via a local HTTP endpoint and works directly on the model in memory.

With this connection, an agent can:

• Navigate and understand — list projects, modules, models, and root nodes; read any node and its subtree; inspect concept schemas, concept hierarchies, and reference scopes; search by name or full text; find usages of a node. For access, Portalon offers three equivalent mechanisms: nodes and subtrees as structured JSON, dedicated MCP tools for specific queries, and a filesystem abstraction that lets the agent navigate the project like a directory tree and search it with commands such as grep or find.
• Edit safely — create, update, replace, move, and delete nodes; set properties and references; create models, solutions, and languages; add dependencies. Note that every write operation goes through the MPS Open API; the agent never edits files directly. When MPS runs as an IDE, changes can be undone as usual; full structural validation is available as a separate step.
• Validate, build, and test — run the same checkers MPS uses interactively (typesystem, constraints, structure), build modules, execute the tests defined in the MPS project, and read back the respective results.
• Apply intentions and quickfixes — discover and invoke the model transformations offered by the DSLs available in the open project, i.e., by the project’s own languages as well as by installed dependencies and plugins.
• Stay grounded — Portalon ships MPS know-how that an agent can retrieve on demand. This allows the agent to fetch the correct concept IDs, role names, and patterns from the live model instead of guessing from general knowledge.
• Understand history — read the Git history behind individual nodes as well as the set of changed nodes in a commit or working tree.

These capabilities allow building the eval loops typical for agents: the agent repeatedly checks its own work on the models against the feedback from validating, building, and testing, and corrects and improves it autonomously. Such feedback loops are a central building block when setting up efficient agents and skills.

In summary, the agent operates on MPS models with the same structural safety a human gets in the projectional editor, but at machine speed and scale.

Why build our own MCP server for MPS?

With the release candidate of MPS 2026.1, JetBrains introduced the Projectional Agent Toolkit (short: PAT), a built-in MCP server bundled with MPS from this version on. This raises a legitimate question: why should itemis develop and maintain its own MCP server for MPS when the platform vendor provides one for free? After all, maintaining such a tool is a considerable ongoing effort.

We welcome PAT. Both solutions emerged in the same period, and the fact that two teams independently arrived at the same architecture — connecting agents to the live MPS model rather than to the persisted XML — is good confirmation that this approach is sound. Nevertheless, there are two reasons why we continue to invest in Portalon.

The first reason is availability also for older MPS versions, which many real-world industrial projects run on today. PAT will be part of MPS 2026.1 and later. However, migrating a large MPS project to a new major version is a substantial undertaking that teams typically plan on their own schedule. Portalon is a plugin, independent of a specific MPS release, and supports MPS versions from 2022.3 onwards. Teams on a 2022, 2023, 2024, or 2025 version can therefore adopt agentic workflows today, without a migration, and decide about version upgrades for their own reasons.

The second reason is building know-how. At itemis, we are developing MCP servers and CLI integrations for a growing number of applications and platforms. Designing a good agent interface for a complex interactive tool is a discipline of its own: which operations to expose, at which granularity, how to keep the agent grounded in the tool’s domain, and how to make feedback loops fast and reliable. With Portalon, we work on these questions for a particularly demanding case — a projectional language workbench. Owning the full stack allows us to experiment, measure how agents actually use the interface, and improve it in short cycles. This experience feeds back into all our agent integrations, and it is not something we could gain by merely consuming a built-in component.

Beyond the bridge: language-engineering skills

A connection to the model is the foundation, but it is not sufficient on its own. Real language-engineering work — reviewing a change, migrating across MPS versions, debugging a generator — follows patterns and conventions that an agent benefits from knowing. Over the years, itemis has developed and applied such patterns in numerous industrial MPS projects; this experience is something we can now translate into tooling for agents.

In parallel with Portalon, itemis is therefore building an mps-language-engineering plugin for Claude: a growing collection of skills that encode such workflows and reliably relieve the language engineer of routine tasks. Two examples from this collection illustrate the approach:

• PR / MR review — the skill clusters the changed root nodes by module and model, separates the changes that belong to the pull request from unrelated edits, builds the affected modules, and runs the model checks. The result is a structured report that highlights potential risks, sticking points, and hot spots of the change — the basis for the subsequent human review. All technical points have already been worked through in it: deviations between the branch content and the PR description, build errors, constraint violations. The reviewer can concentrate on the substantive core questions of the change.
• Version migration — the skill determines the source and target MPS version, prepares the build files, hands off to the MPS Migration Assistant, and verifies the result through Portalon: building modules, finding unmigrated models, broken references, deprecated concepts, and type errors, and fixing the mechanical issues via intentions and quickfixes. In the end, the language engineer gets a clear overview of what has been cleaned up automatically and where substantive decisions are still needed.

Both are being evaluated and refined continuously, and further skills are already in the works. The plugin is designed to grow as we learn what makes an agent a genuinely proficient MPS language engineer.

Sweet spots and current limitations

A fair picture also includes what Portalon can and cannot do well today. In our experience, the current sweet spot lies in analysis-oriented tasks: exploring MPS projects and models, looking for inconsistencies, writing reports, adding comments to models and baselang code, examining the Git history of models, writing and aligning ticket descriptions and pull-request content, and building example models. For this kind of work, agents connected via Portalon are productive today.

Implementing complete features is a different matter. On textual languages such as Java, Python, or Kotlin, today’s agents implement features remarkably quickly, effectively, and efficiently; for MPS models, this level has not yet been reached. This gap still has to be closed. Note, however, that benchmarks such as Sergej Koščejev’s MPS AI benchmark harness indicate the same limitation for other agent integrations for MPS, including JetBrains’ PAT and CLI-based approaches — it reflects the current state of agentic tooling for projectional languages in general, not a specific shortcoming of Portalon. The MPS community has already begun to explore this field and will certainly make significant progress here over the next few years.

Current status, licensing model, and evaluation

Portalon is actively developed and has gone through several releases; the current version is 0.8. These releases are not publicly available, but are handed out to customers who run an evaluation or hold a subscription. Within itemis, the teams working with MPS use Portalon on a growing number of real projects; feedback is collected continuously and flows directly into improvements.

A major thread of the current work is optimizing the interplay between agents — especially Claude Code — and MPS. We refine the interface of the MCP server step by step and learn in the process. Optimizing such an interplay is not an exact science, and MCP is not an API: what makes an agent effective is not just the set of operations, but how well their descriptions, granularity, and feedback guide the agent’s reasoning.

Portalon is closed-source software. Interested parties receive an evaluation license for a no-obligation trial: it allows non-commercial use for a limited period (typically four weeks), so they can assess the tool against their own MPS project. After the evaluation, itemis offers an affordable subscription at a fixed monthly rate; the subscription also includes a small support budget of about two person-days per month. We consider this a fair model. In contrast to an open-source approach, the subscription provides itemis with a reliable budget to maintain Portalon, develop it further, and keep delivering innovation in a field that is evolving quickly.

If you work with MPS and want to bring AI agents into your language-engineering work — on your current MPS version, without a migration — get in touch with us to join the evaluation. And if you are interested in how agent interfaces for complex engineering tools evolve, stay tuned!

Get in touch — Want to bring AI agents into your MPS environment? Talk to us: Contact form →