XMCPStudio – an AI cockpit for XOJO development (pet project)

AI
1

I’d like to share a project I’m working on — partly as a pet project, but also as a learning exercise. I wanted to explore what I could do by combining AI and XOJO, while also learning more about XOJO as a platform.

SCR-20260531-pjzi
SCR-20260531-pjzi2402×1666 141 KB

What is it?
XMCPStudio is a macOS app built in XOJO that works as an AI-assisted cockpit for XOJO development. It features a chat UI, a job library (prompt templates), notes, and a session browser. You can talk to Claude Code or OpenAI Codex directly from the app, and they have access to the XOJO IDE through a MCP server — [ XMCP – Control the Xojo IDE from your AI assistant ] — which was built as part of this journey.

AI-assisted — architect + AI
I should mention that this project is heavily AI-assisted. I work as the architect — I design the structure, make the decisions, and set the direction — while Claude Code does most of the actual typing. It’s been a fun way to explore how far I can push architectural thinking with AI-assisted implementation. And it’s teaching me a lot about both XOJO and AI-assisted development.

Why not just use VS Code?
Of course, nothing here is impossible to do in VS Code or Cursor — but XMCPStudio is built around the idea that I already have the XOJO IDE. Why not use it? Autocomplete, the navigator, the debugger — it’s all there. And if the XOJO team ever felt inspired to bake some of these ideas — like a built-in notes panel or a shared job/prompt library — directly into the IDE, I certainly wouldn’t complain. :wink:

Oh, and XMCPStudio weighs in at around 50 MB. VS Code is closer to 1 GB.

Technical approach
One thing I really like about XOJO is the built-in SQLite support — it makes it really easy to build a solid local data layer. For the UI itself I’ve gone with HTML, CSS and JavaScript rendered through a DesktopWKWebViewControlMBS from the MBS plugin, and I’m really happy with that choice. Using web tech also means I can reuse a lot of existing libraries — here I’ve used marked.min.js for Markdown rendering in chat bubbles, session history, and the note editor.

It’s not the most “XOJOish” approach, but the combination of XOJO’s native strengths and the flexibility of web technologies works really well for me.

Status
The project is still under development and not finished – it works and is actively used. Maybe it will never be finished because the XOJO team makes it redundant for me (wishful thinking :wink:).
I’m sharing it mainly because I’m curious whether others here have experimented with similar approaches — whether that’s AI-assisted development or mixing native XOJO with web technologies for UI.

6 Likes
2

Very impressive. I like your approach.
I’m very curious to see a real result you’ve achieved with this XOJO and AI combination.

3

Thank you! @Jose_Fernandez_del_Valle
The most mind-blowing result so far is that XMCPStudio helped build itself — I used a combination of an earlier version and VS Code to develop the current one. There’s something deeply satisfying or crazy about that loop.

2 Likes
4

This looks really cool. Can you explain more ?

So it via Claude modifies your local repository. It then sends a revert command directly to Xojo so that it can reload the UI?

Can you tell me more about this vs using something else hooked up to Claude to modify Xojo code and then manually revert in Xojo?

5

Thanks @Stephen_Dodd The key dependency is XMCP — a separate open-source MCP server (also built in Xojo) that connects to the Xojo IDE via its built-in IPC socket. You register it once in your MCP client config and the AI can call its tools automatically.

6

What does that actually do? What do you communicate to Xojo other than reload from disk? Genuinely curious!

7

More than just reload-from-disk :slightly_smiling_face:

XMCP connects directly to the Xojo IDE through its IPC socket and exposes 22 MCP tools to the AI. That means the AI can navigate the project structure, read and modify code, inspect constants and descriptions, build and run applications, read debug logs and system output, and look up Xojo documentation.

For me, the biggest advantage isn’t code generation itself, but the feedback loop. The AI can trigger a build, detect compile errors, inspect the resulting messages, make corrections, rebuild, and continue iterating without me having to copy/paste error messages back and forth. The same applies to runtime debugging through log and output inspection.

Another recent addition is XMCP now provides both traditional and semantic search across the Xojo documentation.

One detail that has worked surprisingly well is that XMCP ships with a usage-guide.md file exposed as an MCP resource. Clients such as Claude Code automatically read it when a session starts, so the AI immediately understands XMCP’s capabilities, known IDE scripting limitations, and recommended fallback strategies. I can also add project-specific notes there without changing any code in XMCP. This also allows XMCP to work around certain IPC limitations by falling back to direct disk edits when appropriate.

So while reload-from-disk is certainly part of the workflow, the goal is really to give the AI a fairly complete view of what’s happening inside the Xojo IDE rather than treating it as an external text editor.

4 Likes
8

That’s frankly quite amazing. You should make a little video showing it in action.

Would love to find the time to try it out.

Do you have any idea of the token usage difference between this and say simply having Claude read the local repository and make changes on disk?

3 Likes
9

I don’t think it’s possible to make any general statements about token usage. It depends largely on your coding style.

If you’re very methodical and instruct the AI to work with the code you’ve selected in the IDE using SET and GET operations, you’ll likely use significantly fewer tokens than if you’re vibe coding.

1 Like