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
LSUIElementin the app’sInfo.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 socketBut XMCP’s current model is more like:
MCP client → launches XMCP executable → communicates over stdin/stdoutThat 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:
- No useful Dock/UI
AddLSUIElement = truetoInfo.plist, or use an IDE build step/AppWrapper plist modification.- Keep the app alive
A desktop app needs an event loop. That is fine.- 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 on127.0.0.1, or use a small wrapper process.- 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 IDEThat 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:
- Use/buy/build the console version if you want XMCP mostly unchanged; or
- 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.