# XMCP – Control the Xojo IDE from your AI assistant **URL:** \ **Category:** AI\ **Created:** [February 22, 2026, 4:34pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749 "2026-02-22T16:34:52Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Beatrix\_Willius](https://forum.xojo.com/user_avatar/forum.xojo.com/beatrix_willius/32/282_2.png) [@Beatrix\_Willius](https://forum.xojo.com/u/Beatrix_Willius)\ **Post date:** [May 31, 2026, 1:57pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/21 "2026-05-31T13:57:51Z")
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: > > ```auto > MCP client → local TCP / HTTP / SSE server → Xojo IDE IPC socket > > ``` > > But XMCP’s current model is more like: > > ```auto > 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: > > ```auto > 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. ---
**Author:** ![Eugene\_Gonchar](https://forum.xojo.com/letter_avatar_proxy/v4/letter/e/ebca7d/32.png) [@Eugene\_Gonchar](https://forum.xojo.com/u/Eugene_Gonchar)\ **Post date:** [May 31, 2026, 7:10pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/22 "2026-05-31T19:10:44Z")
> [@Clifford\_Antrim](#): > > I believe the terms of the Xojo license prohibit building apps for other users to get around not having a license 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. ---
**Author:** ![Eugene\_Gonchar](https://forum.xojo.com/letter_avatar_proxy/v4/letter/e/ebca7d/32.png) [@Eugene\_Gonchar](https://forum.xojo.com/u/Eugene_Gonchar)\ **Post date:** [May 31, 2026, 7:12pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/23 "2026-05-31T19:12:17Z")
> [@Clifford\_Antrim](#): > > I don’t know much about Cursor, but I don’t think XMCP will work with it since XMCP is designed to communicate with the Xojo IDE. 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 ---
**Author:** ![Eugene\_Gonchar](https://forum.xojo.com/letter_avatar_proxy/v4/letter/e/ebca7d/32.png) [@Eugene\_Gonchar](https://forum.xojo.com/u/Eugene_Gonchar)\ **Post date:** [June 1, 2026, 2:23am UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/24 "2026-06-01T02:23:04Z")
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. ---
**Author:** ![Beatrix\_Willius](https://forum.xojo.com/user_avatar/forum.xojo.com/beatrix_willius/32/282_2.png) [@Beatrix\_Willius](https://forum.xojo.com/u/Beatrix_Willius)\ **Post date:** [June 1, 2026, 4:36am UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/25 "2026-06-01T04:36:59Z")
> [@Eugene\_Gonchar](#): > > Thank you for your reply, sounds more complicated. 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. ---
**Author:** ![Philip\_Cumpston](https://forum.xojo.com/user_avatar/forum.xojo.com/philip_cumpston/32/621_2.png) [@Philip\_Cumpston](https://forum.xojo.com/u/Philip_Cumpston)\ **Post date:** [June 15, 2026, 12:16am UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/26 "2026-06-15T00:16:33Z")
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 `CodeCleanWindow`edits 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. ---
**Author:** ![Aurelian\_N](https://forum.xojo.com/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@Aurelian\_N](https://forum.xojo.com/u/Aurelian_N)\ **Post date:** [June 15, 2026, 8:48am UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/27 "2026-06-15T08:48:16Z")
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](https://forum.xojo.com/groups/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 ---
**Author:** ![Stephen\_Dodd](https://forum.xojo.com/user_avatar/forum.xojo.com/stephen_dodd/32/530_2.png) [@Stephen\_Dodd](https://forum.xojo.com/u/Stephen_Dodd)\ **Post date:** [June 15, 2026, 9:10am UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/28 "2026-06-15T09:10:36Z")
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. ---
**Author:** ![Beatrix\_Willius](https://forum.xojo.com/user_avatar/forum.xojo.com/beatrix_willius/32/282_2.png) [@Beatrix\_Willius](https://forum.xojo.com/u/Beatrix_Willius)\ **Post date:** [June 15, 2026, 9:16am UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/29 "2026-06-15T09:16:26Z")
> [@Stephen\_Dodd](#): > > Xojo is designed to let you distribute built apps It took less than 30 minutes to have Codex port the MCP code from Ojan to node. So no Pro license needed. ---
**Author:** ![OJAN](https://forum.xojo.com/letter_avatar_proxy/v4/letter/o/f1d935/32.png) [@OJAN](https://forum.xojo.com/u/OJAN)\ **Post date:** [June 16, 2026, 3:52pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/30 "2026-06-16T15:52:19Z")
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. 🤔 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. ---
**Author:** ![Philip\_Cumpston](https://forum.xojo.com/user_avatar/forum.xojo.com/philip_cumpston/32/621_2.png) [@Philip\_Cumpston](https://forum.xojo.com/u/Philip_Cumpston)\ **Post date:** [June 21, 2026, 6:06am UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/31 "2026-06-21T06:06:43Z")
Thank you. I have applied your advice to use CODEX, and it seems to be working well. ---
**Author:** ![OJAN](https://forum.xojo.com/letter_avatar_proxy/v4/letter/o/f1d935/32.png) [@OJAN](https://forum.xojo.com/u/OJAN)\ **Post date:** [September 7, 2026, 4:55pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/32 "2026-09-07T16:55:16Z")
**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](https://github.com/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](https://github.com/o3jvind/XMCP/blob/main/CHANGELOG.md) on GitHub. ---
**Author:** ![Dirk\_Cleenwerck](https://forum.xojo.com/user_avatar/forum.xojo.com/dirk_cleenwerck/32/533_2.png) [@Dirk\_Cleenwerck](https://forum.xojo.com/u/Dirk_Cleenwerck)\ **Post date:** [September 15, 2026, 6:23pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/33 "2026-09-15T18:23:46Z")
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 ---
**Author:** ![OJAN](https://forum.xojo.com/letter_avatar_proxy/v4/letter/o/f1d935/32.png) [@OJAN](https://forum.xojo.com/u/OJAN)\ **Post date:** [September 16, 2026, 12:35pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/34 "2026-09-16T12:35:06Z")
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. ---
**Author:** ![Dirk\_Cleenwerck](https://forum.xojo.com/user_avatar/forum.xojo.com/dirk_cleenwerck/32/533_2.png) [@Dirk\_Cleenwerck](https://forum.xojo.com/u/Dirk_Cleenwerck)\ **Post date:** [September 16, 2026, 1:01pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/35 "2026-09-16T13:01:42Z")
I’ll process the comments asap. thanks for the feedback. ---
**Author:** ![OJAN](https://forum.xojo.com/letter_avatar_proxy/v4/letter/o/f1d935/32.png) [@OJAN](https://forum.xojo.com/u/OJAN)\ **Post date:** [September 17, 2026, 12:14pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/36 "2026-09-17T12:14:31Z")
**XMCP 1.11.0 — opt-in file tools for MCP clients without their own (write\_file/read\_file/hash\_file)** Quick update on [XMCP](https://github.com/o3jvind/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](https://forum.xojo.com/u/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](https://github.com/o3jvind/XMCP#file-tools-opt-in). As always, happy to hear how people are using it. ---
**Author:** ![Dirk\_Cleenwerck](https://forum.xojo.com/user_avatar/forum.xojo.com/dirk_cleenwerck/32/533_2.png) [@Dirk\_Cleenwerck](https://forum.xojo.com/u/Dirk_Cleenwerck)\ **Post date:** [September 17, 2026, 3:01pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/37 "2026-09-17T15:01:48Z")
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 ---
**Author:** ![OJAN](https://forum.xojo.com/letter_avatar_proxy/v4/letter/o/f1d935/32.png) [@OJAN](https://forum.xojo.com/u/OJAN)\ **Post date:** [September 19, 2026, 6:26am UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/38 "2026-09-19T06:26:04Z")
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. ---
**Author:** ![Dirk\_Cleenwerck](https://forum.xojo.com/user_avatar/forum.xojo.com/dirk_cleenwerck/32/533_2.png) [@Dirk\_Cleenwerck](https://forum.xojo.com/u/Dirk_Cleenwerck)\ **Post date:** [September 22, 2026, 1:48pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/39 "2026-09-22T13:48:36Z")
I pushed the changes to PR #11 Let me know if there are any more remarks. I tested everything on Windows and Mac. ---
**Author:** ![OJAN](https://forum.xojo.com/letter_avatar_proxy/v4/letter/o/f1d935/32.png) [@OJAN](https://forum.xojo.com/u/OJAN)\ **Post date:** [September 22, 2026, 2:14pm UTC](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749/40 "2026-09-22T14:14:13Z")
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](https://github.com/o3jvind/XMCP/pull/11#issuecomment-5778008660). Not blocking, just flagging before merge — take a look when you have time. [Previous page](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749.md?page=1) [Next page](https://forum.xojo.com/t/xmcp-control-the-xojo-ide-from-your-ai-assistant/87749.md?page=3)