Power your agent
คำสั่งของผู้เผยแพร่เอง ไม่ใช่เอนด์พอยต์ของ PlugMCP
Host a copy with our keys and logs.
cargo xojo-mcpClaude Code ไม่มีลิงก์ติดตั้งสำหรับคำสั่งแบบโลคัล ให้คัดลอกคำสั่งด้านล่างแล้วรันในเทอร์มินัล
claude mcp add io.github.brechanbech-xojo-mcp -- cargo xojo-mcpรันในเทอร์มินัล
{ "mcpServers": { "io.github.brechanbech-xojo-mcp": { "command": "cargo", "args": [ "xojo-mcp" ] } }}claude_desktop_config.json
URL แบบรีโมตหรือคำสั่งบนเครื่องของคุณ? การติดตั้งสองแบบต่างกันอย่างไร
รันบน PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
เปิดจากผู้เผยแพร่
An MCP (Model Context Protocol) server that gives AI assistants direct control over the Xojo IDE. Communicates via stdin/stdout JSON-RPC and forwards IDE commands via a Unix domain socket to the running Xojo IDE process.
Note on the name. This crate was previously published as
xmcp. It was renamed toxojo-mcpto avoid confusion with X's (formerly Twitter) unrelated framework. The installed , so existing configs keep working.
MCP server for controlling the Xojo IDE on macOS
xmcpxmcpmacOS only. xojo-mcp talks to the Xojo IDE over a Unix domain socket (
/tmp/XojoIDE, or/tmp/$XOJO_IPCPATH— see Choosing which IDE to talk to). Windows is not supported and there is no plan to add it. The reason is not that the IDE lacks an IPC mechanism there: Xojo'sIPCSocketis a framework abstraction, and on Windows it is a localhost TCP socket whose port is derived from the path string rather than a filesystem entry. The original XMCP, being itself a Xojo application, gets that transport for free from the framework; this port speaks the wire protocol directly, so Windows would mean reverse-engineering an undocumented path-to-port derivation. Linux is untested rather than ruled out — it uses a Unix socket as macOS does, but the debug- and system-log tools read macOS-only sources.
This is a Rust port of XMCP by Øjvind Søgaard Andersen, originally written in Xojo. The original project is licensed under the MIT License.
Each release carries an aarch64-apple-darwin tarball that is signed with a
Developer ID certificate, notarized by Apple, and accompanied by a detached
minisign signature. Grab the latest from
Releases, check it, and put
the binary on your PATH:
minisign -Vm xmcp-*-aarch64-apple-darwin.tar.gz \
-P RWR7Jy43Mphvu+jrP2FynfYpR7WdP0PvQaSFKfXub7q9Sh7fjtyAX9GU
tar xzf xmcp-*-aarch64-apple-darwin.tar.gz
install -m 755 xmcp-*/xmcp ~/.cargo/bin/xmcp
The .minisig is the check worth doing, and the one the .sha256 beside it
cannot do: a checksum file hosted next to the file it vouches for proves only
that the download wasn't corrupted, since anyone able to replace one asset can
replace both. The signature is made by a key that never touches the release
server — the one in the command above, kept in this repository as
minisign.pub.
minisign is in MacPorts (port install minisign). A successful verify prints
the trusted comment, which names the version and the date it was signed. The
.sha256 is still published for anyone who wants it:
shasum -a 256 -c xmcp-*-aarch64-apple-darwin.tar.gz.sha256
The binary is signed with a Developer ID certificate and notarized by Apple, so Gatekeeper lets it run as-is. Check that for yourself if you like:
codesign -dvv ~/.cargo/bin/xmcp # Authority: Developer ID Application …
codesign -vvv -R="notarized" --check-notarization ~/.cargo/bin/xmcp
(spctl is the obvious thing to reach for and the wrong tool here: it answers
does not seem to be an app for any plain command-line binary, notarized or
not.)
A notarization ticket cannot be stapled to a bare executable — stapler only
handles .app, .dmg and .pkg — so the first run needs to reach Apple to
resolve the ticket. If that first run has to happen offline, clear the
quarantine flag by hand instead:
xattr -d com.apple.quarantine ~/.cargo/bin/xmcp
Intel Macs are not covered — build from source instead.
cargo install xojo-mcp
The crate is xojo-mcp; the binary it installs is xmcp.
git clone https://codeberg.org/brechanbech/xojo-mcp.git
cd xojo-mcp
cargo install --path .
This installs the xmcp binary to ~/.cargo/bin/xmcp. If ~/.cargo/bin
is already on your PATH (the Rust installer adds it by default), you're
done. Verify with:
xmcp --help
Optional: usage-guide.md is embedded into the binary at compile
time, so the MCP resource is always available out of the box. If you
want to tweak the guide without rebuilding, drop a copy next to the
binary — xmcp will prefer the file on disk over the embedded fallback:
cp usage-guide.md ~/.cargo/bin/
Run this from any terminal:
claude mcp add xmcp -- xmcp
Or add it manually to your Claude Code settings. Open the MCP config file
(on macOS: ~/.claude/settings.json or the project-level
.claude/settings.json) and add:
{
"mcpServers": {
"xmcp": {
"command": "xmcp",
"args": []
}
}
}
To enable verbose logging (written to stderr, visible in the Claude Code MCP log):
{
"mcpServers": {
"xmcp": {
"command": "xmcp",
"args": ["-v"]
}
}
}
The documentation tools (search_docs, lookup_class, list_doc_topics) need
a local copy of the Xojo docs. A script is included to download them from
docs.xojo.com:
scripts/update-xojo-docs.sh
This downloads llms.txt and llms-full.txt from docs.xojo.com and splits
the full documentation into individual class files under _sources/. Everything
goes into ~/Library/Application Support/Xojo/Xojo/<version>/Documentation/,
which xmcp auto-detects at startup. Re-run the script periodically to pick up
documentation updates — Xojo refreshes these files when new releases are
published.
lookup_class returns a shaped summary by default: the class description plus
its member tables, with Sphinx cross-reference markup resolved to plain text.
That is a few thousand characters where the raw page runs to tens of thousands
— String alone is over 70,000. Ask for one member with member, or the
unprocessed page with full: true:
lookup_class(class_name: "String") # description + member tables
lookup_class(class_name: "String", member: "Middle") # that member's entry alone
lookup_class(class_name: "String", full: true) # the raw .rst.txt page
To use a custom location instead:
scripts/update-xojo-docs.sh /path/to/docs
xmcp --docs-path /path/to/docs
By default, an assistant connected to xmcp can change your project: it can rewrite code, create new items, save, and revert. That is the point of the tool — but it is not always what you want. If you only want an assistant to look at a project — read the code, build it, run it, analyse it, answer questions, consult the documentation — without any possibility of it modifying or overwriting your source, start the server in read-only mode.
Read-only mode is enforced by the server itself, not by asking the assistant to behave. It is the single most important safety control in xmcp, so it is worth understanding exactly how it works.
The simplest way is the --read-only flag on the launch command. In Claude
Code:
claude mcp add xmcp -- xmcp --read-only
Or, in a Claude Code settings file (~/.claude/settings.json, or the
project-level .claude/settings.json):
{
"mcpServers": {
"xmcp": {
"command": "xmcp",
"args": ["--read-only"]
}
}
}
If your MCP client prefers environment variables to command-line arguments, the
variable XMCP_READ_ONLY=1 does exactly the same thing. Accepted truthy values
are 1, true, yes, and on (case-insensitive):
{
"mcpServers": {
"xmcp": {
"command": "xmcp",
"args": [],
"env": { "XMCP_READ_ONLY": "1" }
}
}
}
If both the flag and the environment variable are present, either one enabling read-only mode is enough — there is no way to disable it from the other.
This is the part newcomers most often get wrong. You do not put the assistant into read-only mode by telling it to "stick to reading" in the chat. A prompt is a request the model can forget, misinterpret, or be argued out of — and it does nothing at all if the model simply calls a write tool anyway. That is the weakness read-only mode exists to remove.
Read-only mode is a property of how the server was started. You set it once, in your MCP client's configuration, before the session begins. From that point on, for the entire lifetime of that server process, the restriction holds regardless of anything typed into the conversation. Neither you nor the assistant can toggle it mid-session; to change modes you change the configuration and reconnect the server. (Restarting the server is required for a change to take effect — a server that is already running will not pick up a new flag or environment variable.)
Read-only mode disables the ten tools that modify the project:
property_value, constant_value and get_item_description also read, but each
is one tool, so read-only mode blocks the read along with the write.
Every tool also carries MCP behaviour hints in tools/list — a title and
readOnlyHint, destructiveHint, idempotentHint and openWorldHint — so a
client can decide what to confirm before calling it. These are hints, not
enforcement, and they describe a tool's effect on the whole machine rather than
on the project, so they are stricter than read-only mode: build_project,
run_project and agentic_run leave the source alone and stay available in
read-only mode, but they write build output or launch an app, so they are not
hinted read-only. openWorldHint is false everywhere except run_ide_script,
whose DoShellCommand can reach anything.
Everything else remains fully available — navigating and listing items, reading
code (get_code), building (build_project), running (run_project),
stopping, compile-checking (analyze_project), inspecting descriptions and
constants, the debug log tools, and all three documentation tools. In short:
browse, build, run, and analyse — just no writing.
Note that build and run are deliberately not blocked. They do not alter your
source; they exercise it. build_project writes a compiled app into the build
folder and run_project launches a debug session, but neither touches the
project itself, so both are considered read-only-safe.
The restriction is applied in two independent layers, so it holds even if a client or model misbehaves:
tools/list), the six mutating tools are
filtered out. The model never sees them, so it cannot choose to call
something it does not know exists. This is what makes the mode effective in
practice rather than merely defensive.The assistant is also told, via the embedded usage guide, that when it sees a reduced tool set the project is intentionally read-only and it should work within the available tools rather than trying to route around the restriction.
Because the mode is fixed per server, you can register xmcp twice under
different names and choose per task which one to point the assistant at — for
example a normal xmcp for editing sessions and a separate xmcp-ro for
review-only sessions:
claude mcp add xmcp -- xmcp
claude mcp add xmcp-ro -- xmcp --read-only
The IDE listens on a socket whose path is a temporary directory plus the name
XojoIDE — or the value of XOJO_IPCPATH, when that variable is set in the
IDE's environment. Setting it to a unique name per instance is Xojo's supported
way of running several IDEs (say, two releases side by side) and addressing each
one independently:
env XOJO_IPCPATH=Xojo2026r2_1 "/Applications/Xojo 2026 Release 2.1/Xojo.app/Contents/MacOS/Xojo" &
xmcp must be given the same value, otherwise it connects to whichever instance
owns the default XojoIDE socket:
{
"mcpServers": {
"xmcp-2026r2-1": {
"command": "xmcp",
"args": [],
"env": { "XOJO_IPCPATH": "Xojo2026r2_1" }
}
}
}
Only a-z, A-Z, 0-9 and _ are valid in the name; xmcp ignores a value
containing anything else (with a warning on stderr) and falls back to XojoIDE.
Candidate directories are /tmp first — what the IDE itself prefers — then
$TMPDIR, which is where the IDE falls back when /tmp is not writable.
If you only ever run one IDE at a time, ignore all of this: the default works.
rustup — https://rustup.rs)xmcp [OPTIONS]
--read-only — Read-only mode: hide and reject every tool that modifies the
project. Can also be enabled with XMCP_READ_ONLY=1. See
Read-only mode for the full description.-v, --verbose — Enable verbose logging to stderr-d, --docs-path <PATH> — Path to Xojo documentation directory (auto-detected if omitted)-V, --version — Print version-h, --help — Print helpEnvironment: XMCP_READ_ONLY (see above) and XOJO_IPCPATH, which selects the
IDE instance to connect to — see
Choosing which IDE to talk to.
This is a drop-in replacement — it exposes all 25 tools from the original with
identical names and parameters (analyze_project and debug_control were the
last two ported, bringing it to full parity), plus one new tool, edit_code,
for 26 in total. Same IDE Communicator Protocol v2 over the Unix domain socket,
updated to MCP protocol version 2025-11-25.
Notable differences:
xmcpedit_code — targeted str_replace-style editing — replaces an exact
substring within an item's code in one call (read → replace → write, all
server-side), instead of resending the whole item via set_code. The
original has no such tool, forcing whole-item rewrites or shell-based text
munging for small edits.set_code and
edit_code send source straight through the IPC, with all IDE-script string
escaping (quotes, newlines, special characters) handled server-side. There is
no need to smuggle code across the bridge by hand — the base64
encode-on-agent / decode-on-Mac / run-via-shell workflow the original forces
for file edits simply does not exist here.--read-only / XMCP_READ_ONLY removes and
rejects the mutating tools at the server. The original has no built-in
enforcement; it can only be asked, via the prompt, not to write. See
Read-only mode.xmcp exposes 29 tools across five categories:
IDE tools (22): list_project_items, get_current_location, select_project_item, get_code, set_code, edit_code, get_selected_text, set_selected_text, build_project, run_project, stop_project, create_project_item, run_ide_script, get_project_info, revert_project, save_project, get_item_description, constant_value, property_value, set_declaration, analyze_project, debug_control
Documentation tools (3): search_docs, lookup_class, list_doc_topics
Debug tools (2): get_debug_log, get_system_log
Agentic Mode (1): agentic_run — runs a project that has Xojo 2026r3's Agentic Mode on and
returns its compile errors with locations. It works through files in the project folder, not
the IDE socket, so it can be pointed at a project with project_dir even when the socket is
unavailable.
Cost awareness (1): estimate_request_cost
MIT — see LICENSE.md for details.
Ownership-verification token for the MCP registry (read from this crate's rendered README on crates.io):
Registry ownership token:
mcp-name: io.github.brechanbech/xojo-mcp
A version is immutable once published — crates.io yanks, it does not delete, and a number is never reused — so the order matters:
cargo test and cargo clippy --all-targets clean.
Bump version in Cargo.toml.
Bump version in server.json — both fields, the top-level one and the one under
packages[]. Nothing enforces this: no script, no CI, no test reads the file. It sat at
3.4.0 through the 3.4.1 and 3.5.0 releases because of it, leaving the registry advertising a
version two behind what anyone could install.
Commit and push; let CI go green before publishing rather than after.
cargo publish --dry-run, which compiles from the packaged copy and so catches a crate
depending on a file it does not ship. Then cargo publish.
Publish to the MCP registry, after crates.io and not before — the registry verifies the
namespace by reading mcp-name from this crate's rendered README on crates.io, and
server.json names a cargo version that must already exist there:
mcp-publisher validate # checks server.json against the live registry
mcp-publisher login github # interactive, for the io.github.brechanbech/* namespace
mcp-publisher publish
MCP server for controlling the Xojo IDE on macOS
{ "mcpServers": { "io.github.brechanbech-xojo-mcp": { "command": "cargo", "args": [ "xojo-mcp" ] } }}เครื่องมือ
ยังไม่มีรายการเครื่องมือ เซิร์ฟเวอร์แบบรีโมตจะได้รายการหลังการตรวจสอบสถานะครั้งแรก
FAQ
คัดลอกคอนฟิก stdio สำหรับ Cursor, Claude Desktop, Claude Code หรือ VS Code ได้ในหน้านี้ คอนฟิกนี้ใช้การติดตั้งของผู้เผยแพร่ ไม่ใช่พร็อกซีของ PlugMCP
ระเบียนนี้ไม่ได้ระบุตัวแปรสภาพแวดล้อมที่จำเป็น
Xojo IDE Control ทำงานแบบโลคัลผ่าน stdio
ตรวจสอบล่าสุดเมื่อ 2026-11-09 MCP server for controlling the Xojo IDE on macOS