Skip to main content
Glama
brechanbech

xojo-mcp

by brechanbech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Create Project Item

create_project_item

Adds a new class, method, module, or other item to the open Xojo project using the IDE's own command, returning its location so you can name and type it next.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
item_typeYesItem type to create. Must be one of: NewClass, NewModule, NewMethod, NewProperty, NewConstant, NewEvent, NewNote, NewMenuHandler, NewComputedProperty, NewSharedMethod, NewSharedProperty, NewEnum, NewStructure, NewDelegate, NewInterface, NewWindow, NewContainerControl, NewFolder, AddEventImplementation
parent_locationNoDot-separated path of the item to create inside, e.g. 'Module1' or 'Window1'; selected first. Omit to use the current selection.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.7.1
    • changedInput schema / properties / parent_location / description
      Previous value: -"Dot-separated path to navigate to first (e.g. 'Module1')"New value: +"Dot-separated path of the item to create inside, e.g. 'Module1' or 'Window1'; selected first. Omit to use the current selection."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations, the description discloses that the IDE assigns IDs, new methods/properties are blank and untitled and remain selected, and items stay in the IDE until save_project. It also states the prerequisite that the Xojo IDE must be running with the project open.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the action and parent behavior, and every sentence carries relevant operational information. It is somewhat dense and run-on, but there is little wasted content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description explains the return value as the new item's location. It also covers lifecycle, selection state, prerequisites, follow-up naming, and deletion limitations, which is complete for this mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameter documentation already exists. The description adds useful semantics: parent_location is selected first, omitting it uses the current selection, and the new item's location is returned; it also clarifies that set_declaration should follow without a location.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: creates a new item in the open Xojo project using the IDE's own command. It distinguishes this from hand-editing the .xojo_project file and from the missing delete capability, so an agent can identify the tool's unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this tool, never a hand edit of the project file, to add items. It also gives the follow-up workflow with set_declaration and explains that there is no matching delete tool, including what to do instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools