Efficient Domain-Specific Modeling with AI Agents, MPS and Portalon

Over the course of this year, not only LLMs have become more capable, but also Portalon, our MCP server for MPS. A practical domain-specific language (DSL) for project planning, with scoping, cycle detection, a scheduling algorithm, example models and 28 tests: with Portalon 1.5, an AI agent creates all of this in an empty MPS project in under ten minutes, without additional skills. The generated code looks as if it had been written by a developer with extensive MPS experience, and the generated tests were all green on the first run. The freely available alternatives needed about 70 to 90 percent longer for the same task.

In July 2026, we introduced Portalon in this blog, at that time in version 0.8. Portalon is an MPS plugin by itemis that connects AI agents such as Claude Code to the live model of a JetBrains MPS project via the Model Context Protocol. Back then, we had seen the main benefit in analysis-oriented tasks, and we openly wrote that implementing complete tool features had not yet reached the level that agents achieve with textual languages. This gap has narrowed considerably since then. We at itemis and our customers use Portalon in real projects, and the experience gained there has fed directly into its further development. This article presents the most important improvements in performance, functionality and infrastructure, followed by the use cases for which Portalon is applied today.

What has stayed the same

The design goals for Portalon have remained constant since the early releases:

• IDE and headless – user and agent collaborate interactively in the IDE. Long-running tasks can be executed with a headless MPS instance.
• Support all roles – users of the DSLs, developers and language engineers, each with read-only or read/write access.
• One codebase, many MPS versions – a wide range of MPS versions is supported.
• Good enough without extra effort – the agent should be productive without additional skills and without DSL-specific instructions.
• Automatic evaluation – tools for building, checking and testing, so that the agent can verify its own work and improve it iteratively.
• Token efficiency – optimized round trips, efficient code creation.

The last three goals in particular are important for the results below. In the benchmark runs reported there, the agent worked with MPS exclusively through Portalon, without any project- or task-specific skills.

Performance: wall-clock time and token consumption

Two quantities dominate when working with agents. The wall-clock time determines how long a user or a language engineer waits for the result of a prompt; the token consumption ultimately determines the cost. Our analyses show that the computing time of the MCP server plays practically no role here. Portalon almost always responds in well under a second. The time is spent in the inference of the LLM, across all LLM requests (so-called turns) of the agent session. A faster interface is therefore, above all, one with which the agent needs fewer turns and has to read, think and write less per turn.

The benchmark prompt for the project planning DSL mentioned above was originally created as a demo example for my talk at the LangDev 2026 conference. The task for the agent comprised the language structure with projects, persons, tasks and their dependencies, clean scoping, the detection of dependency cycles, a scheduling algorithm with a result cache, automatically computed result cells in the editor, a sandbox with example models, and a test solution with about 20 tests. With Portalon 1.0, the agent needed about 13 minutes for this. With Portalon 1.5, it is now under 10 minutes, and all 28 tests written by the agent passed on the first run. Note that Portalon delivers practically identical results on MPS 2025.1 and MPS 2026.1 (9:24 and 9:43 minutes, respectively); this confirms the design goal of one codebase for many MPS versions.

Using the same task, we compared Portalon in November with two other agent integrations for MPS, both freely available. These are, on the one hand, the MCP server that is now shipped with MPS as open source, and on the other hand the open-source CLI mops, which connects the agent to a headless MPS instance via command-line calls. Agent, model, effort level and MPS version were identical in all runs (Claude Code with Opus 5.5, effort medium, MPS 2026.1). The two open-source tools were allowed to use their bundled skills; Portalon worked without skills, only with its built-in instructions. The following table shows the key figures:

For the cost metrics in the table, Portalon is ahead, although only narrowly ahead of mops in terms of context read. The second-fastest tool needed about 70 % more time; the MCP server from MPS needed more than twice as many turns. We are happy to provide the full evaluation with additional metrics on request.

A large share of this result comes from the efficiency of automatically generating code in BaseLanguage, the Java dialect of MPS (more on this in the next section). Early versions of Portalon had the agent write such code as a JSON representation of the syntax tree. Since Portalon 1.0, the agent writes textual Java, including MPS extensions such as node<C> or list<T>. Portalon translates this text into the corresponding syntax trees. In our benchmarks, this significantly reduced the amount of tool input the agent had to write, with the same model and the same task. In a typical benchmark, runtime and cost dropped to about one third.

Since version 1.0, Portalon has also offered an interface based on the Code Mode principle as a further performance optimization. Here, the agent does not call individual MCP tools one after another, but writes a short program in Python or TypeScript that accesses Portalon via the provided clients. This pays off for complex queries that involve many nodes, e.g., the distribution of the number of methods across all classes of a large project. With individual tool calls, this would require a long sequence of turns; in Code Mode, a single script is sufficient, and only the condensed result enters the agent’s context. Note, however, that Code Mode was disabled for Portalon in the benchmark above; the results shown are based solely on the individual MCP tools.

Functionality: code like an experienced language engineer would write

Speed of creation alone is not enough; the generated code must also be maintainable in the long term. A major focus of the further development was therefore the generation of idiomatic BaseLanguage code. BaseLanguage is the Java-like language used in MPS to implement large parts of a DSL, e.g., behavior, constraints or editor functions. It offers its own constructs for working with models, above all the smodel language for accessing nodes and the collections language. Those who use these constructs get compact, readable code that fits seamlessly into the MPS tooling.

Without special measures, agents tend to write plain Java, i.e., code that works but does not make use of the Java language extensions of MPS. The benchmark result shows this quite clearly. With the MCP server shipped with MPS, the agent generated the scheduling algorithm and other code of the benchmark predominantly as plain Java. With the mops CLI, the result was plain Java as well; nodes are read there via the open API using property and role names as strings, which is not refactoring-safe.

With Portalon, all generated code is idiomatic BaseLanguage, from the scheduling algorithm to scoping and checking rules to the tests. The generated code looks as if an experienced language engineer had written it. For our internal work and for our customers, this is an important advantage, because an agent’s code is subsequently read, reviewed and further developed by humans.

Infrastructure: ready for real-world environments

A tool that works well on an individual developer’s workstation is not necessarily suitable for use in an enterprise environment. Portalon therefore now supports security mechanisms that allow such use. The connection between clients and Portalon can be secured with bearer tokens, so that only authorized agents and clients can access the MPS model, even when MPS runs headless on a server. In addition, settings control which kinds of access are permitted. A read-only mode restricts the agent to read operations. For users who only use DSLs but should neither develop DSLs nor modify the tool itself, the language engineering tools can also be switched off.

What Portalon is used for today

With these improvements, the range of tasks that we and our customers handle with Portalon has broadened considerably:

• Language engineering tasks – developing new features in existing languages up to completely new DSLs, refactorings, and creating and extending test suites.
• Complex debugging – root-cause analysis for errors that spread across several language aspects such as structure, type system and generator, and that only become visible at runtime.
• Architecture and design analyses – examining large MPS projects for dependencies, inconsistencies and potential for improvement.

Cross-cutting tasks such as creating pull requests, reviews or model migrations naturally become easier as well. With Portalon, the agent can also work with several open projects at the same time. This is particularly helpful for tasks that span multiple projects, as is typical, e.g., when maintaining platform components.

Another interesting use case is transferring DSLs and models from old MPS versions. For this, an agent works with two Portalon instances at the same time. One runs in the old MPS version and serves as the source, the other runs in the current version and serves as the target. Without the traditional route of manually migrating the old model, the agent reads DSLs and models from the source project and rebuilds them in the target. We use this pragmatic approach repeatedly, both internally and with customers.

Finally, Portalon is well suited as a building block for customer-specific agents. A common architecture from our project practice combines an open-source LLM, a web interface and a headless MPS instance with Portalon into a local agentic solution on the intranet. With this solution, domain experts can interact with their MPS models in natural language, i.e., ask questions about the models, make changes or trigger analyses, without opening the MPS IDE and without data leaving the company. The access restrictions described above are an important prerequisite for this. We build such solutions together with our customers as part of our custom tools projects.

Tailor-made tools at manageable cost

With the improvements shown, LLMs, AI agents and Portalon fundamentally change language engineering with MPS. A large part of the implementation work that used to consume considerable project time can now be reliably delegated to an agent. However, language engineers are not replaced by this. They set the direction, assess the results and make the design decisions. Relieved of routine work, they can concentrate more on innovation and conceptual work, and on making a custom tool reflect the needs of its users even more precisely.

This also affects a fundamental decision that many companies face time and again. The initial development costs have often been cited as an argument against a tailor-made tooling solution; one should therefore rather accept the limitations of an off-the-shelf tool. This argument now largely loses its weight. With AI agents and Portalon, optimally adapted tools can be developed at manageable cost. At the same time, innovative use cases become possible that would be difficult to implement with generic tools, e.g., the natural-language interaction with MPS models on the intranet described above.

Conclusion

Since its first introduction, Portalon has evolved from a promising tool for analyses into a foundation for professional language engineering with AI agents. The agent can work effectively with it and produces solutions that follow the conventions of experienced language engineers. With the new security mechanisms, Portalon is also ready for use in real enterprise environments. As a result, tailor-made tools become economical even where a compromise with off-the-shelf tools used to be the obvious choice. We continue to develop Portalon consistently, based on the experience from our projects.

If you would like to learn more about Portalon or specifically about the benchmark, please feel free to contact me directly, by e-mail at kbirken@itemis.de or via LinkedIn. The recording of my LangDev talk also offers a look behind the scenes of the optimization work. Stay tuned!

Custom Tools at itemis — Custom tooling for your model-based development: Custom Tool Development →