XMCP – Control the Xojo IDE from your AI assistant

AI
21

I don’t have a Console license either and asked ChatGPT about that:

You probably should not rely on debug mode. It may work for experiments, but it is the wrong operational model for an MCP server.

The key issue is not only “console vs desktop”; it is transport.

XMCP, as described by the author, exposes its MCP tools over stdin/stdout JSON-RPC, which is the normal command-launched MCP-server model used by tools such as Codex/Claude-style clients. The forum post explicitly says XMCP talks to the Xojo IDE via the IDE IPC socket, but exposes tools to the AI client over stdin/stdout JSON-RPC.

A normal Xojo desktop app can be made visually invisible or mostly invisible, for example with LSUIElement in the app’s Info.plist, which hides the Dock presence. That part is technically plausible; Xojo forum users also mention using an Info.plist key for hiding the Dock icon. But that does not automatically make it a usable stdio MCP server.

Practical answer

For XMCP as-is: you need a console build, not a desktop build.

A hidden desktop app is only a good workaround if you change the MCP transport away from stdin/stdout, for example:

MCP client  →  local TCP / HTTP / SSE server  →  Xojo IDE IPC socket

But XMCP’s current model is more like:

MCP client  →  launches XMCP executable  →  communicates over stdin/stdout

That second model wants a real command-line process.

Can you convert it to Desktop?

Technically yes, you can probably copy most of the classes into a Desktop project. But then you have to solve these things:

  1. No useful Dock/UI
    Add LSUIElement = true to Info.plist, or use an IDE build step/AppWrapper plist modification.
  2. Keep the app alive
    A desktop app needs an event loop. That is fine.
  3. Replace stdio transport
    This is the real blocker. A desktop app launched normally is not a clean stdin/stdout MCP process. You would need to implement an MCP transport that listens locally, for example on 127.0.0.1, or use a small wrapper process.
  4. MCP client compatibility
    Some MCP clients expect a command to launch and speak stdio. If the client only supports stdio, your hidden desktop app alone will not be enough.

Best workaround without a console license

The most practical route is:

Small Node/Python stdio MCP wrapper
        ↓ local socket/HTTP
Hidden Xojo Desktop helper
        ↓ IDE Communicator socket
Xojo IDE

That lets the MCP client launch a normal command-line script, while your Xojo code remains a Desktop app. The Node/Python wrapper only handles MCP stdin/stdout plumbing and forwards requests to your Xojo helper.

This also avoids running the Xojo project in debug mode.

Why debug mode is not a good solution

Debug mode is only suitable for testing because:

  • the MCP client usually wants a stable executable path;
  • the debug app lifecycle depends on the Xojo IDE;
  • crashes/stops/debugger interruptions will break the MCP session;
  • deployment to Codex/Claude/Cursor-style clients becomes fragile;
  • the forum thread notes that debug-mode behavior/logging differs from built apps, especially around debug logs and exceptions.

My recommendation

Do not try to run XMCP permanently in debug mode.

Either:

  1. Use/buy/build the console version if you want XMCP mostly unchanged; or
  2. Port it to a hidden Desktop helper only if you are willing to replace the MCP stdio layer with a local socket/HTTP layer plus a small external stdio wrapper.

For your use case as a Xojo desktop developer, option 2 is probably the most interesting long-term architecture, but it is no longer “just change the project type”. It becomes a small two-process design.

22

Don’t get me wrong,

I don’t mean to get anyone in trouble by making the executable, I would consider paying for a product with does exactly as I think this project is meant to do: enable newbies like me (with a desktop license) utilize an AI via MCP to Control XOJO IDE, where most valuable part is trying to build and address the run/build errors.

23

Cursor in this context is an equivalent of Claude Code or Codex or any other AI driven IDE, the app and environment is still xojo and its IDE

24

Thank you for your reply, sounds more complicated. I think it might be a matter of time until what I am looking for is available.

25

If you look at the code the MCP server is not that complicated. There are alternative Basic dialects. Even Node.js is not out of reach these days.

26

I used XMCP with claude desktop (without the link to clarion references). After the refactoring a larhe application, I asked claude to analyse the strengths and weaknesses. Her eis the report:–> XMCP — Practical Assessment from This Session

What XMCP Is

XMCP is the MCP server that allows Claude to control the Xojo IDE directly — navigating the project tree, reading and writing code, building, and running. It was the backbone of this entire refactoring session.

Strengths

Project navigation and inspection
list_project_items and select_project_item work reliably. Getting an overview of the project structure is fast and accurate. This was essential for understanding the codebase before touching anything.

Build feedback
build_project returns structured error messages with file, method, and line number. This is genuinely excellent — it meant every fix could be verified immediately without leaving the workflow. The tight build→fix→build loop was the most productive part of the session.

Project reload
revert_project reliably reloads files from disk after Python edits. This is the critical bridge between external file editing and the IDE, and it worked consistently throughout.

System log access
get_system_log provides access to System.DebugLog output during debug runs, which is the right architecture for runtime diagnostics on macOS.

IDE script execution
run_ide_script with DoShellCommand is a powerful escape hatch — it allowed running arbitrary Python scripts on the Mac filesystem, which became the primary editing mechanism for this session.

Weaknesses

get_code / set_code scope limitation
These tools only operate on top-level navigable items, not on individual methods within a class or window. This is the single biggest limitation. In practice it means you cannot surgically edit one method — you must read or write the entire file. For a 137KB class file, this is unwieldy.

.xojo_window files are not navigable
select_project_item cannot navigate into window files, and get_code/set_code don’t work on them at all. All CodeCleanWindowedits had to go through Python file manipulation via DoShellCommand, which is fragile and error-prone.

No direct file write tool
There is no write_file equivalent. The only way to edit source files is via IDE scripts that shell out to Python or sed. This led to the cumbersome base64 encoding workflow: write Python in the container → encode → decode on Mac → run → verify. Each step added a failure mode.

Base64 encoding is fragile
Strings generated in the container and encoded to base64 repeatedly contained bugs that survived the encoding process — the eoc vs loc typo being the clearest example. The container file was clean but the encoded version had the old bug, suggesting the encoding was happening from a cached or previous version. This cost significant diagnostic time.

Quote handling in DoShellCommand echo chains
Building Python scripts line by line via echo commands inside IDE scripts fails badly when the Python code contains quotes. Double quotes inside Xojo strings inside DoShellCommand create quoting hell. The workaround of using chr(34) or base64 encoding adds complexity that itself introduces bugs.

get_system_log process name sensitivity
The log query for CodeCleaner.debug returned nothing during the diagnostic phase, even while the app was running in debug mode. This forced a fallback to MessageBox diagnostics, which is far more disruptive (blocking UI, fires on each recursive call).

No str_replace equivalent for Xojo files
The most reliable editing pattern in Claude’s computer-use toolkit is str_replace — find unique text, replace it. XMCP has no equivalent. Every edit required constructing a Python script that does its own string matching, with all the indentation/encoding fragility that entails.

Indentation inconsistency in source files
Xojo’s .xojo_code files mix tabs and spaces in context-dependent ways (\t\t for method bodies inside classes, ``for event handlers in .xojo_window files). Python string matching is case- and whitespace-exact, so every missed pattern required an additional diagnostic round-trip to discover the actual indentation. This probably added 30-40% overhead to the session.

Workflow That Emerged

The most reliable pattern was:

  1. Inspect with grep/sed via DoShellCommand to get exact text including whitespace
  2. Write Python in the Claude container and verify syntax with py_compile
  3. Encode to base64 in container
  4. Deploy via IDE script DoShellCommand decode-and-run
  5. Verify with targeted grep to confirm the change landed
  6. Revert project and build to confirm compilation
  7. Commit with git via DoShellCommand

This is six steps where ideally it would be two (edit + build). The overhead is real but manageable once the pattern is established.

Overall Assessment

XMCP is genuinely useful for the build-verify-commit loop and for project-level navigation. It transforms what would be a manual IDE workflow into something automatable. But the editing story — the most important part of a refactoring session — is weak. The lack of a direct file-write tool or a str_replace-style operation means every edit goes through a fragile Python-via-shell chain.

The ideal improvement would be a write_method tool that accepts a method name and new body and applies it directly via the Xojo IDE’s own code model, bypassing the filesystem entirely. That would eliminate the indentation fragility, the encoding overhead, and the .xojo_window blind spot in one stroke.

For what it is, XMCP made this session possible. Without it, a refactoring of this scope across 13 source files would have required many hours of manual IDE work. With it, it took two focused sessions — with the majority of the overhead coming from the editing fragility rather than from the analysis or decision-making.

27

Hello guys,

I am doing some tests over the Web version with XMCP, while i tuned some parts , i discovered that over time if i keep the project for long opened, some times ipc socket hangs then it stops so as a workaround i need to close project, close ide, reopen them and then start to work, this lately starts happened more and more often, i have the feeling that the issue is IPC somehow and XOJO rather than the XMCP itself. @XOJO is the Communicator protocol fully aware about the latest changes on XOJO and latest IDE apis or maybe something is hanging and it fails then it times out and kills the IPC ? is there a workaround for this ? as it gets quite annoying. , so far it seems that once it calls the build_project or run_project it hands on “Preparing…” and it dies there until slowly XOJO becomes unresponsive and you need to force quit it as you cannot control it anymore. So far you can safely use it on select, reload, inspect but not on run and build , at least not for Web apps .

MacOS : Tahoe 26.5.1

Mac Mini M1

XOJO : 2026 R 1.2

28

I wouldn’t think there’d be any licensing problem with supplying the built console app publicly. I build an app and distribute it with no licensing restrictions. Xojo is designed to let you distribute built apps.

29

It took less than 30 minutes to have Codex port the MCP code from Ojan to node. So no Pro license needed.

30

Thanks for sharing this, @Philip_Cumpston.

In the spirit of this project, I asked Claude Code to comment on your Claude Desktop analysis. Based on its feedback, I then had Claude Code make a few updates to usage-guide.md— so this is, in a sense, Claude reviewing Claude and revising itself. :thinking:

Here’s Claude Code’s response:

The analysis is largely accurate and fair. Let me add some nuance:

Agree on the strengths — build feedback, revert, and system log are genuinely solid. The build→fix loop assessment matches my own experience working in this codebase.

Agree on the core weakness — the lack of a direct file-write tool is the biggest gap. But the framing slightly misdiagnoses the intended workflow. XMCP is designed around direct disk editing: the client (Claude Code, in this case) edits .xojo_code files directly on disk, then calls revert_project. The set_code tool exists as a convenience, not as the primary path. The analysis describes a workflow where edits go through DoShellCommand → Python → base64, which is working around a self-imposed constraint — Claude Code has Edit and Write tools that can modify .xojo_code files directly without any of that complexity.

The .xojo_window limitation is real — those files can’t be edited via set_code, and direct disk editing + revert is the correct approach there too. But the fragility the user experienced came from routing through DoShellCommand rather than using the client’s own file tools.

The write_method idea is interesting but architecturally tricky — Xojo’s IDE scripting API doesn’t expose a “set method body” primitive, so it would have to go through disk editing anyway. The right improvement is probably better documentation in usage-guide.md making the “edit on disk, then revert” pattern clearer as the primary workflow.

The indentation observation is accurate and useful — worth documenting explicitly.

The bottom line: the session apparently used XMCP as a remote shell host rather than as intended. The six-step workflow the user describes collapses to two steps (Edit + revert_project) when the client uses its own file tools. That’s a documentation/discoverability failure more than a tool capability gap.

31

Thank you. I have applied your advice to use CODEX, and it seems to be working well.

32

v1.10.0 — XMCP can now search any Dash/Zeal docset, not just XOJO docs

The AI’s documentation search was XOJO-only until now. That’s fixed.

Three new tools: list_docsets, search_docset, get_docset_entry

Register any Dash or Zeal .docset bundle with --docset-path (repeatable — pass it once per bundle) and the AI can search it directly, independent of the existing XOJO-specific search_docs/lookup_class tools. This covers hundreds of languages and frameworks via Dash-User-Contributions — PHP, JavaScript, CSS, AppleScript, whatever your project actually touches beyond XOJO itself.

list_docsets shows what’s registered and how many entries each has. search_docset searches entry names across all registered docsets at once, or scoped to one via docset_name. get_docset_entry reads the full content of a specific match, HTML stripped to plain text.

Two on-disk docset layouts are handled: the usual Documents/ HTML tree, and Dash’s space-saving tarix.tgz archive format (some distributions, like AppleScript’s, ship no Documents/ folder at all) — that gets extracted once to a local cache on first read.

Why this matters beyond “more tools”

XMCP is still XOJO-first — the IDE tools and the bundled XOJO documentation exist because I’m a XOJO developer. But none of that architecture is XOJO-only. If your project mixes XOJO with an HTML/JS/CSS front end, or you’re calling out to a database, you can register docsets for all of it and the AI searches whichever is relevant. The README now has a section on adapting XMCP to your stack — docsets, the examples/ reference templates, and usage-guide.md are all meant to be edited per project, not just accepted as XOJO defaults.

Thanks

A few people have contributed fixes and ideas since the last update, including a startup robustness fix from eltan148 that’s been in since v1.9.0. Appreciate everyone who’s opened issues, sent PRs, or just tried this out and reported back.

Full details in the CHANGELOG on GitHub.

33

I put in a pull request for Windows support. The original on worked on MacOS. 2 of my colleagues at work are already using it on Windows and at least on their machine it seems to work. I have more work that i need to do, but since the pull request for Windows is already so big (since my version was developed next to yours) I’d rather wait till after it’s been merged. Let me know if I need to change anything, or if the pull request is ok. @OJAN

34

Hey Dirk
I really appreciate the effort here, and great to hear it’s already working for two of your colleagues on Windows, that’s a solid real-world signal.

I’m swamped at the moment, so I had Claude do a thorough line-by-line review of the diff on my behalf rather than digging through 60 commits myself. It came back with a fairly long list, including a few things that look like regressions of bugs already fixed on my side (things get lost easily in a merge when both branches touched the same functions independently), plus some correctness issues in the new parser. I’ve posted the details as a comment on the PR itself so it’s easy to work through point by point.

Nothing there takes away from the value of what you’ve built. The Windows support and the new inspection tools are genuinely things this project needs. I just don’t want to merge something that quietly breaks write paths people are already relying on, so I’d rather get those sorted first. Given the list, I don’t think it’s fair to ask you to hold off further work waiting on this — happy to take it in smaller chunks by theme if that makes it easier to land pieces incrementally instead of one big branch.

Thanks again for putting this together.
Will follow up properly on the PR comment.

35

I’ll process the comments asap. thanks for the feedback.

36

XMCP 1.11.0 — opt-in file tools for MCP clients without their own (write_file/read_file/hash_file)

Quick update on XMCP:
1.11.0 adds three new tools, write_file, read_file, and hash_file, for MCP clients that have no file tools of their own — Claude Desktop being the main case, since it can’t touch the filesystem otherwise.

They’re disabled by default. Start XMCP with --enable-file-tools to turn them on, and --file-root to restrict access to specific directories (defaults to /tmp). A new FileGuard module enforces the sandbox: paths are canonicalised and resolved through realpath(3) before comparison, so a symlink inside an allowed root can’t be used to write outside it. write_file also supports an optional expected_hash check, so it refuses to overwrite a file that’s changed since you last read it.

Full credit for this one goes to @ Philip Cumpston — he designed and built the whole thing, including the sandboxing model and the opt-in flag, and iterated through several rounds of security review to get there. I ported his work onto current main and fixed one remaining bug in read_file along the way, but the design is his.

Details and config examples in the README. As always, happy to hear how people are using it.

37

Getting started on the next part towards windows support. (the new file tools won’t work on windows yet due to posix paths not working on windows. i’ll handle that later because security is important in handling files that could be links and i don’t want to rush it). i’ll process your feedback on the merged pull request as well. thanks for merging it. @OJAN

38

A quick credit where it’s due: @Philip_Cumpston has been a real driving force behind a couple of features that just landed in XMCP.

  • Smarter class lookups — before this, asking lookup_class about something like String dumped the entire raw reference page — over 70,000 characters, mostly markup, for a single lookup. That’s expensive and slow for an AI assistant to work with. Philip’s work scopes it down to a clean summary by default (~3,300 characters): a description plus the member list, so the assistant can see what’s available and then ask for exactly the one method or property it needs, or pull the full page when that’s genuinely required. In practice this makes every “look up how X works” interaction in the IDE faster and cheaper.
  • Native file tools — reading, writing, and hashing files directly from XMCP, sandboxed to specific folders so it can’t wander outside them. This closes a real gap for AI clients that don’t have their own file-editing tools (like Claude Desktop), so they can work with files on disk without workarounds.

Thanks for the contributions, Philip — good, careful work on both.

39

I pushed the changes to PR #11
Let me know if there are any more remarks.
I tested everything on Windows and Mac.

40

Thanks Dirk — ran another review pass on the update. All ten points from round one are genuinely fixed. Found four new issues in the rebase itself, posted with details on #11: Keep IDE sockets open past a timeout, merge split replies, one reply classifier by eurog33k · Pull Request #11 · o3jvind/XMCP · GitHub. Not blocking, just flagging before merge — take a look when you have time.