xojo-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| XMCP_READ_ONLY | No | Read-only mode: hide and reject every tool that modifies the project. Accepted truthy values are 1, true, yes, on (case-insensitive). Can also be enabled with --read-only flag. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_project_itemsA | Lists the project items directly under a location in the open Xojo project's Navigator, as tab-separated names: the top level (App, windows, classes, modules, folders) when location is empty, or what a folder holds. On Xojo 2026r3 an item's members (methods, properties, constants, events) are not listed; read them from its .xojo_code or .xojo_window file, in the folder get_project_info names. A location with nothing listable under it, or one that does not exist, returns a message saying so rather than an error. Needs the Xojo IDE running with the project open. |
| get_current_locationA | Returns the item selected in the Xojo IDE's Navigator and its type, as ' ()', e.g. 'Module1.Helper (Method)'. Tools whose location is optional act on this item when it is omitted, so check it before relying on that; select_project_item changes it. get_project_info returns the same plus the project's path and Xojo version. Needs the Xojo IDE running with the project open. |
| select_project_itemA | Selects an item or member in the Xojo IDE's Navigator by dot-separated path and returns where the IDE landed and its type. A path that does not exist is an error naming where the IDE is instead, so a near miss shows the right spelling. Changes only the IDE's selection, not the project. Tools that take a location select it themselves; use this for those that act on the current item: get_selected_text, set_selected_text, analyze_project with scope 'item', and create_project_item without parent_location. Needs the Xojo IDE running with the project open. |
| get_codeA | Returns the code of one method, event handler or other code item in the open Xojo project: the item at location, or the one open in the code editor when location is omitted. Giving a location also selects that item in the Navigator. A path that does not exist, or an item with no code editor, is an error; an empty body says so. The code is the body only: the declaration line is not included. Window and control event handlers are reachable on Xojo 2026r3 and later; on earlier releases read the .xojo_window file instead. Copy edit_code's old_string from this output. Needs the Xojo IDE running with the project open. |
| set_codeA | Replaces the whole code of one method, event handler or other code item in the open Xojo project: the item at location, or the one open in the code editor when location is omitted. Everything the item held is overwritten, so for a change to existing code prefer edit_code, which sends only the part that changes. The name, parameters and return type are not part of the code; set_declaration changes those. A path that does not exist, or an item with no code editor, is an error and nothing is written. Reaches the same items as get_code. The change stays in the IDE until save_project. Needs the Xojo IDE running with the project open. |
| edit_codeA | Makes a targeted edit to an item's source code by replacing an exact substring, leaving everything else untouched. Reads the current code, replaces |
| get_selected_textA | Returns the text selected in the Xojo IDE's code editor, after a first line 'start= length=' giving its position in characters from the start of the item's code. Fails if no code editor is active. Use it to see what the user has highlighted, or to find offsets for set_selected_text; to read a whole item, use get_code. Needs the Xojo IDE running with the project open. |
| set_selected_textA | Replaces the selection in the Xojo IDE's code editor with text, or inserts it at the cursor when nothing is selected. Pass selection_start to select a range first; otherwise it acts on whatever the user or an earlier call left selected. Fails if no code editor is active. For a change you can describe by its content, edit_code is more reliable because it does not depend on offsets. The change stays in the IDE until save_project. Needs the Xojo IDE running with the project open. |
| build_projectA | Builds the open Xojo project into a standalone app. Call it only when the user asks for a build, and offer run_project first: a run catches errors a build misses. Returns 'Build succeeded.' or the compile errors with their locations; runtime errors are not visible. A success has been reported with no app written, so confirm the built app exists on disk. Waits up to 30 minutes; a build that outlasts that keeps going, and xmcp refuses other requests until the IDE answers. Needs the Xojo IDE running with the project open. |
| run_projectA | Runs the open Xojo project in the IDE's debugger. Call it only when the user asks to run. Returns 'Project launched in debug mode.' once the app starts, or the compile errors that stopped it. Runtime exceptions are caught by the IDE's debugger and are invisible here, so ask the user what they see. In an Agentic Mode project, agentic_run returns the compiler's errors with their locations instead. Step through the session with debug_control and end it with stop_project. Waits up to 30 seconds. Needs the Xojo IDE running with the project open. |
| stop_projectA | Ends the Xojo IDE's debug session by killing the app it is running, as started by run_project or agentic_run. The app is stopped outright, so anything it has not saved is lost. Returns 'Debug session stopped.' whether or not anything was running. Needs the Xojo IDE running with the project open. |
| create_project_itemA | Creates a new item in the open Xojo project with the IDE's own command for it, inside parent_location (selected first) or the currently selected item, and returns the new item's location. A new method or property is blank and untitled (e.g. 'Window1.Untitled') and stays selected, so name and type it with set_declaration straight afterwards, with no location. Use this, never a hand edit of the .xojo_project file, to add items: the IDE assigns their IDs. The item stays in the IDE until save_project. There is no matching delete: Xojo's IDE scripting has no command for it. Delete a member by removing its #tag block from the item's file on disk; a whole item has to be deleted by the user in the IDE. Needs the Xojo IDE running with the project open. |
| run_ide_scriptA | Executes an arbitrary Xojo IDE script. Use Print to return a value, once: with several Prints the first that says something is returned, and an error outranks output. A script that prints nothing reports that it ran. Do not leave the script early with Return: xmcp appends a final line that tells it the script finished, and a script that never reaches it is waited on until the timeout. Powerful escape hatch — IDE scripting can quit Xojo, close/reopen projects, create or delete items, write files, and invoke shell commands via DoShellCommand. Prefer a dedicated tool when one fits (list_project_items, get_code, build_project, etc.); use this only when nothing else does, and pause before running anything that quits the IDE or touches the shell. It cannot delete project items: IDE scripting has no command for that (see create_project_item). A runtime error comes back with no message or line number. Needs the Xojo IDE running. |
| get_project_infoA | Returns facts about the project open in the Xojo IDE, one per line: the .xojo_project path, the Project Directory holding its .xojo_code and .xojo_window files, the Xojo version, the selected location and its type, and whether Agentic Mode was on at the last save. Call it first when working on files on disk, since lint_project_file and direct edits need absolute paths. Needs the Xojo IDE running with the project open. |
| revert_projectA | Closes the open Xojo project without saving and reopens it from disk, so the IDE picks up project files edited directly. Every unsaved change in the IDE is discarded, the user's included, so ask the user before calling it; the IDE may also show a prompt they must accept. Use it after editing .xojo_code or .xojo_window files on disk, and do not save_project in between, which would overwrite those edits. Not needed in an Agentic Mode project, where Xojo reloads edited files by itself. Needs the Xojo IDE running with the project open. |
| save_projectA | Saves the open Xojo project, writing the IDE's in-memory copy over the project's files on disk. Returns 'Project saved.', or 'No changes to save.' when no file changed within two seconds. Call it when IDE-side edits (set_code, edit_code, create_project_item and the like) should persist, and before editing on disk a file you changed through the IDE. Never call it between editing a file on disk and revert_project: it would overwrite the disk edit. Needs the Xojo IDE running with the project open. |
| get_item_descriptionA | Reads or sets the Description of a project item or member (the note shown in the IDE's Inspector, not its code): the one at location, or the selected one. Without value it returns the description; with value it replaces it and returns 'OK', and an empty value clears it. Giving a location also selects that item. A set stays in the IDE until save_project. Needs the Xojo IDE running with the project open. |
| constant_valueA | Gets or sets the value of a project constant in the Xojo IDE. The constant must already exist in the project. A set is read back, so a name that matches no constant is reported rather than silently ignored; a get of such a name returns an empty value, the same as an empty constant. It changes the value only: to rename or retype a constant, edit its #tag Constant line on disk (scaffold_code_block writes one). A set stays in the IDE until save_project. Needs the Xojo IDE running with the project open. |
| property_valueA | Gets or sets a FRAMEWORK property of a project item in the Xojo IDE — e.g. 'App.OptimizationLevel', 'App.SupportsDarkMode', 'Window1.Title'. This is the supported way to change app and build settings, which otherwise live in the .xojo_project file that must never be hand-edited. IMPORTANT LIMITS: it reaches only properties that are part of the Xojo framework, NOT properties you added yourself, and it CANNOT address controls on a window (there is no 'Window1.PushButton1.Caption'). Values are always strings, even for numeric or boolean properties. A set returns 'OK' without reading the value back, so get it afterwards to confirm it took. A set stays in the IDE until save_project. Needs the Xojo IDE running with the project open. |
| set_declarationA | Sets the name, type, scope and parameters of the CURRENT method or property in the Xojo IDE. This is the other half of create_project_item: DoCommand "NewProperty" creates a blank, untyped property, and this is what names and types it. NOTE the two argument meanings — for a METHOD, |
| analyze_projectA | Analyzes the current Xojo project for compile errors and warnings without building. Reports unused variables, type mismatches, deprecated API usage, and other issues. Pass scope="item" to analyze only the currently selected item (faster); default is "project" to analyze everything. Returns 'No errors or warnings found.' or one line per issue with its type, message and location. Any error makes the call fail; warnings alone do not. Nothing is built, run or changed. Waits up to one minute. Needs the Xojo IDE running with the project open. |
| debug_controlA | Controls the Xojo debug session. Actions: "step_over" (execute current line), "step_into" (step into method call), "step_out" (step out of current method), "resume" (continue running), "pause" (pause execution). Requires an active debug session started with run_project; without one the call fails. It returns once the IDE accepts the command and reports neither the new line nor variable values: the user sees those in the IDE's debugger. Needs the Xojo IDE running with the project open. |
| agentic_runA | Agentic Mode only (Xojo 2026r3+): runs the project and returns its compile errors, if any. Unlike run_project, this reports real compiler errors with their locations. It works through files in the project folder rather than IDE scripting, so it also works when the IDE socket does not: it drops XojoRunProject.txt into the project folder and reads back XojoCompileErrors.txt. Compile errors fail the call, one ', line : ' per line. A successful run launches the app in the debugger; stop it with stop_project. If Xojo has not taken the request within 10 seconds, Agentic Mode is off or the project is not open: the request file is removed again and the call fails saying how to turn the mode on. Agentic Mode is the user's opt-in to having the project run to check edits, so this may be called without asking each time. |
| scaffold_code_blockA | Generates a correctly formatted #tag block for a .xojo_code or .xojo_window file: a method, shared method, property, constant, event definition (#tag Hook), control event handler (#tag Events block) or window event handler. Use it instead of writing #tag syntax from memory when editing a project file on disk: it pairs each Flags value with its visibility keyword, escapes a constant's Default value, and indents the body the way the IDE does. It only returns text; insert it yourself, in the block order usage-guide.md's Format Rules give and before #tag ViewBehavior, then check the file with lint_project_file. A control_event result is a whole #tag Events block: if the control already has one, insert just its inner #tag Event … #tag EndEvent. An argument that does not apply to block_kind, a name that is not a Xojo identifier, or a constant value it cannot escape safely is an error. Reads no files and needs no IDE. |
| lint_project_fileA | Checks a .xojo_code or .xojo_window file on disk for mistakes the IDE reports badly or not at all. Errors are unbalanced #tag/#tag End pairs, which break the file. Warnings are a constant Default value with characters left unescaped, which can silently truncate it, and things Xojo loads but resolves on its own terms: blocks out of order or after #tag ViewBehavior, and a Flags value that disagrees with the visibility keyword, where the warning says which visibility Xojo will use. Run it after editing a project file directly and before revert_project. Returns 'No issues found' or a count and one 'error|warning: line : ' per finding; findings, errors included, are a normal result, and only a file it cannot read or one of another type fails the call. It reads the file only and needs no IDE. |
| search_docsA | Searches the full text of the local Xojo documentation — guides, tutorials and API pages — for a case-insensitive literal substring. Returns up to max_results excerpts in document order (not ranked), each headed by its section title, with the matching line marked '>>>'. A multi-word query must appear verbatim, so one distinctive word usually finds more. No match is a normal result, not an error. Use this for concepts, how-tos, error messages, or a class whose name you are unsure of; when you know the name, lookup_class returns its reference page directly. Reads the installed documentation (fails if none was found) and needs no IDE. |
| lookup_classA | Returns the reference page for one Xojo class, control, data type or other API, by name (case-insensitive). If no page has that exact name it tries the Desktop and Web prefixes, so 'Button' finds DesktopButton. By default the page is cut to its description and member tables (methods, properties, events with their signatures), markup stripped; pass member for one member's full entry. An unknown class is an error suggesting search_docs; an unknown member is an error listing the members the page documents. Use this when you know the name; use search_docs for concepts or a name you are unsure of, and list_doc_topics to browse page titles. Reads the installed documentation (fails if none was found) and needs no IDE. |
| list_doc_topicsA | Lists the pages in the local Xojo documentation index, one title and URL per line. Unfiltered that is the whole index — about 1,600 entries, 150 KB — so pass a filter. An API page's title is the name lookup_class takes. No match is a normal result, not an error. Use this to find which pages exist; search_docs searches their text, and lookup_class reads one. Reads the installed documentation (fails if none was found) and needs no IDE. |
| estimate_request_costA | Rates a planned request's likely token cost as LOW, MEDIUM or HIGH, with the reasons and cheaper ways to do it. It is a keyword heuristic over the request text and the planned tool names, with no project or IDE access and no real token count, so treat it as a prompt to narrow scope rather than a measurement. Most useful before documentation-heavy or project-wide work. |
| get_debug_logA | Returns /tmp/xmcp_debug.log, which a built Xojo app writes from its App.UnhandledException handler when it crashes (usage-guide.md has the handler to add). This is how to see an exception in a built app; in a debug run the IDE's debugger catches exceptions instead, and get_system_log reads System.DebugLog output. No log file is a normal result that says so. With clear, the file is deleted after reading, so the next crash starts a fresh log. Needs no IDE. |
| get_system_logA | Returns recent System.DebugLog output of a Xojo app from the macOS unified log ( |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| xmcp Usage Guide | Guide for AI assistants: xmcp capabilities, limitations, and fallback strategies for direct file editing. |
TDQS
Scored across 31 tools
Tools span distinct domains (IDE editing, build/run, on-disk file tooling, docs, logs), and overlapping clusters like get_code/set_code/edit_code/set_selected_text are carefully disambiguated by descriptions (whole-item vs. selection vs. targeted substring edit). A few pairs still require reading: run_project vs agentic_run, get_current_location vs get_project_info, and constant_value/property_value vs get_item_description all touch adjacent concepts.
Most names follow a verb_noun pattern (get_code, set_code, edit_code, create_project_item, list_project_items, lint_project_file, search_docs). Deviations like constant_value, property_value and debug_control use noun phrases, though they remain readable and predictable given the get/set dual semantics.
31 tools is at the heavy end and exceeds the comfortable 3-15 band; several could be merged (constant_value/property_value/get_item_description, run_project/agentic_run). However, the surface genuinely spans IDE automation, code editing, file linting/scaffolding, documentation lookup and logging, and no tool appears purely trivial.
Coverage is broad: read/write/edit code, item creation, declarations, constants/properties, build, run, debug stepping, save/revert, on-disk scaffolding and linting, docs search and logs. The notable gap is item deletion (explicitly impossible via IDE scripting, with a documented workaround), which is a minor rather than blocking hole.