Skip to main content
Glama
brechanbech

xojo-mcp

by brechanbech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Get or Set Item Description

get_item_description
DestructiveIdempotent

Reads or updates the Inspector description of a Xojo project item or member, using a dot path or the current selection; omit the value to read it or provide text to replace or clear it.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
valueNoNew description, replacing the old one. Omit to read it instead.
locationNoDot-separated path, e.g. 'Module1.Helper'. Omit for the selected item.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.7.1
    • changedInput schema / properties / location / description
      Previous value: -"Dot-separated path to navigate to first"New value: +"Dot-separated path, e.g. 'Module1.Helper'. Omit for the selected item."
    • changedInput schema / properties / value / description
      Previous value: -"If provided, sets description; if omitted, reads it"New value: +"New description, replacing the old one. Omit to read it instead."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, it discloses meaningful behavior: an empty value clears the description, a set returns 'OK' and persists only until save_project, giving a location also changes the IDE selection, and the IDE must be running with the project open. These are exactly the side effects an agent needs.

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

Conciseness5/5

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

The description is front-loaded with the core read/set distinction and then tersely covers side effects and prerequisites. Every sentence adds useful information with no filler.

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?

With no output schema, the description still explains the return value ('OK' or the description text), covers persistence across save_project, notes the selection side effect, and states the required runtime environment. Nothing essential is missing.

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% and already documents both parameters, but the description adds meaning beyond the schema: it explains that an empty value clears the description and that supplying location also selects that item in the IDE.

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 dual verb (reads or sets) and resource (Description of a project item or member), and explicitly distinguishes it from code-related siblings by clarifying it is the Inspector note, not the item's code.

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

Usage Guidelines4/5

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

It clearly states the read vs. set behavior based on presence of the value parameter, and that omitting location defaults to the selected item. It does not explicitly name alternative tools like get_code or set_declaration, but the conditions for use are otherwise clear.

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