By Ana Pantaleão, OutSystems Tech Lead at Moxie · 5 min read

Can an AI assistant build and change a real OutSystems app? Yes, through the OutSystems MCP and Mentor, with limits you should know before you start. We tested it on a live ODC project and went from an empty app to a live map in three days.

How do the OutSystems MCP and Mentor work together?

The assistant talks to the MCP, and the MCP hands every edit to Mentor. MCP (Model Context Protocol) is an open standard that lets an AI assistant call another system's tools. OutSystems hosts one MCP server per tenant, with 50+ tools. Mentor is OutSystems' AI developer: it changes the app on the server from a text prompt.

The app model (OML) never reaches your disk: the assistant reads it through lookups and edits it only through Mentor. That explains most of the limits below.

How do you set up the OutSystems MCP?

By adding your tenant's OutSystems MCP server to your AI assistant and signing in with OAuth. In Claude Code it takes five steps, or you can paste the install prompt from the OutSystems MCP GitHub repository. For example:

claude plugin marketplace add OutSystems/outsystems-mcp
claude plugin install outsystems@outsystems \
  --config tenant_hostname=mycompany.outsystems.dev
claude mcp list

Then restart the assistant and ask anything about OutSystems: a browser window opens for the sign-in. Use the host name only, with no https:// and no path.

The OutSystems skill holds the rules the agent follows: it asks before every publish, deploy or new app, and looks things up instead of guessing. Claude Code gets it with the plugin; VS Code Copilot, Cursor, Kiro and Claude Desktop (via the mcp-remote proxy, 0.14 or later) work too.

What can an AI assistant do through the MCP?

Anything you can describe in plain words, within what Mentor can edit. It can inspect apps, read entities, actions, screens and roles, create new apps (after asking you), edit through Mentor, publish to Development and read logs and traces. Deploys to Test or Production happen only when you ask.

How does one change go from request to live?

In seven steps, and the three that prove the change are the ones people skip. It ran 50+ times in our build.

1. YouDescribe the feature or the bug
2. AgentWrites the prompt: exact names, rules, a checklist
3. MentorRuns the turn. It takes minutes
4. Agent · proofReads the result: applied? any errors?
5. YouApprove the publish
6. Agent · proofPublishes and confirms the live revision is the new one
7. Both · proofLook at it: screenshot, logs, real data

Mentor's "succeeded" only means the turn ended. Steps 4, 6 and 7 proved each change.

How do you write prompts that Mentor follows?

Give Mentor a clear, specific brief, as you would to a new teammate. The more precise the request, the less it has to guess. What worked:

• One feature per prompt, with exact names for entities, screens and widgets.
• The exact rule, such as the SQL or the If condition.
• "Delete A, B" first, then "Add…" when replacing. Asked to replace widgets, Mentor added new ones beside the old.
• A checklist that Mentor verifies by reading the model back.

What are the limits of the OutSystems MCP?

Everything Mentor can't do, the MCP can't do either. Check these before you start:

• No CSS, JavaScript or mobile through Mentor.
• Sessions expire after 30 idle minutes. We lost a batch of unpublished edits overnight.
• Slow and sequential. One Mentor turn per session at a time, each taking minutes.
• Development only. Test and Production need a deployment.
• No admin tools, a daily Mentor usage limit and a prompt firewall: "UNION ALL SELECT" in a prompt returned HTTP 403.

What did we build with the OutSystems MCP and Mentor?

A web app that maps where social services are missing, built almost entirely through Mentor.

A person still did the sign-in, the approvals, the map script and CSS import, and the role assignments.

Where should you start?

Small, read-only, and checked at every step.

1. Install, sign in, then ask a read-only question: "list my apps".
2. Make one small edit, publish it, and check the live revision and the screen.
3. Keep prompts and a progress file in git, so anyone can resume.
4. Treat Mentor's output as a draft.

FAQ