XMCP – Control the Xojo IDE from your AI assistant

AI
1

I came across MCPKit by @GarryPettet a few weeks ago and wanted to try it. I got a bit carried away and ended up building something bigger than I originally intended.

XMCP is an MCP server that lets an AI assistant talk directly to the XOJO IDE. Navigate the project, read and write code, build, run, look up documentation. The AI does it, not you.

https://github.com/o3jvind/XMCP

It communicates via the IDE’s IPC socket using the IDE Communicator Protocol v2, and exposes 20 tools to the AI client over stdin/stdout JSON-RPC — the standard MCP protocol. Garry’s MCPKit handles all the MCP plumbing, which made this possible without starting completely from scratch.

In the spirit of the project itself, the code was written by AI — Claude Code mainly, with some OpenAI Codex. I was the architect.

It works. I’ve tested it quite a bit. But it’s experimental, and there are some limitations that come from what the IDE scripting API allows — you can’t navigate directly to individual methods, for example, only to classes and folders.

If anyone else is playing with MCP and XOJO I’d love to hear about it.

9 Likes
2

v1.2.0 update

A few significant improvements since the initial post.

The AI now knows what it can’t do

The biggest addition is a usage-guide.md that ships with the project and is exposed as an MCP resource. Compatible clients like Claude Code fetch it automatically at session start — so the AI immediately knows about XMCP’s capabilities, the IDE scripting limitations (e.g. can’t navigate to individual methods or window event handlers), and what to do instead. Previously the AI would just hit a wall and get confused; now it gets actionable guidance.

You can also edit the file to add project-specific notes without rebuilding.

Compile errors flow directly to the AI

When the AI calls build_project or run_project, any compile errors come back directly in the response — error type, message, file, and line number. The AI sees exactly what’s wrong and can fix it immediately without you having to copy-paste anything or take screenshots.

get_system_log also works for reading System.DebugLog output from both debug runs and built apps, so the AI can instrument code and check output without leaving the session.

Better error messages

When tools like select_project_item or get_code hit a scripting limitation, the error now tells the AI exactly what alternative to use — direct file editing, revert_project, etc.

get_project_info now returns the project directory

Useful when the AI needs to fall back to editing .xojo_code or .xojo_window files directly on disk.

Protocol fixes

Several JSON-RPC correctness fixes — integer id preservation, correct JSON types for tool parameter defaults, shell injection prevention in get_system_log.

Full details in the CHANGELOG on GitHub.

2 Likes
3

This sounds fantastic.

I’ve been using Claude Code with Opus 4.6, after a hiatus. Previously using with Sonnet, which was good if the task wasn’t too ambitious. What a difference with Opus. I’ve been converting Xojo apps that I spent months on, into web apps, in a matter of hours. In one case just a screenshot of the Xojo app form…plus a reference to a folder containing the files that the Xojo app used. This is taking a few hours to get it all done, but I am not straining my brain doing it. No reference to Xojo code, yet, its generating python and js from scratch.

But with your MCP for Xojo my methods can change. I think the presentation, with an native application, is generally much better than a web app. So I am looking forward to this. I’ve got a ton of code.

1 Like
4

Honestly Opus is blowing my mind right now as if regenerates code (in Python) that I so painstakingly wrote in Xojo. With very little intervention. It’s embrace or die. I mention this to you because clearly you understand, having made the effort to implement MCP.

5

If you decide to try XMCP, there’s one small but important tip: add this to your prompt at the start of the session:

Run list_mcp_resources and read file://usage-guide.md before coding.

Make sure usage-guide.md sits next to the XMCP binary.
That ensures the AI loads the built-in usage guide first, so it understands the IDE limitations and the intended workflows. It makes a big difference in how smoothly things go.

Would love to hear how it works for your projects if you give it a spin.

1 Like
6

Is there any way to use XMCP in a read-only mode so it cannot overwrite documents, but only read through the IDE?

7

There’s no built-in read-only mode right now. You can steer it toward read-only use via prompts/instructions (see usage-guide.md), but it’s not enforced.

For now, best to treat XMCP as experimental and use it with care on non-critical projects.

8

v1.3.0 — Improved AI guidance based on real-world testing

After more testing I’ve made significant updates to the usage-guide that ships with XMCP.

Direct file editing is now the primary approach

Previously the guide suggested using get_code/set_code with dot-separated paths to read and write code in .xojo_code files. In practice, navigation by dot-path is unreliable — it frequently fails. The guide now instructs the AI to always edit source files directly on disk and call revert_project to reload. This turns out to be more robust anyway.

The only reliable use of get_code/set_code is without a location parameter — reading or writing whatever the user has already selected in the IDE. After writing with set_code, the AI now reminds you to save (Cmd+S).

Clearer debug guidance

The guide now makes it explicit that get_debug_log is only useful in built apps — the Xojo debugger intercepts all exceptions in debug mode, so they never reach the log. The log also persists across crashes, so the AI now always calls get_debug_log with clear: true after reading to avoid confusing old data with new.

build_project always reports success

The guide now warns the AI that build_project always returns “Build succeeded” regardless of outcome. The AI will now always ask you to confirm the build actually worked.

Full details in the changelog on GitHub.

3 Likes