Skip to main content
Glama
brechanbech

xojo-mcp

by brechanbech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Get System Log

get_system_log
Read-onlyIdempotent

Fetches recent System.DebugLog output from the macOS unified log for a Xojo debug run or built app. Returns labeled raw process entries when no Xojo log lines exist.

Instructions

Returns recent System.DebugLog output of a Xojo app from the macOS unified log (log show): a debug run started by run_project, or a built app. Only lines the Xojo framework logged are returned; when there are none but the process logged something else, up to 200 of those raw entries are returned instead, labelled as such. An empty result almost always means no System.DebugLog call ran, so add one and query again; prefer this over MessageBox for tracing. Needs no IDE.

Input Schema

NameRequiredDescriptionDefault
secondsNoHow far back to look, in seconds. Default 60, max 3600.
process_nameYesExact process name: the app's name plus '.debug' for a debug run (e.g. 'MyApp.debug'), or the app's name for a built app. Letters, digits, spaces, '.', '_' and '-' only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.7.1
    • changedInput schema / properties / process_name / description
      Previous value: -"Process name filter (e.g. 'MyApp.debug')"New value: +"Exact process name: the app's name plus '.debug' for a debug run (e.g. 'MyApp.debug'), or the app's name for a built app. Letters, digits, spaces, '.', '_' and '-' only."
    • changedInput schema / properties / seconds / description
      Previous value: -"How many seconds back to search (default 60, max 3600)"New value: +"How far back to look, in seconds. Default 60, max 3600."
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description still adds real behavioral detail: only framework-logged lines are returned, with a documented fallback of up to 200 raw entries labelled as such, plus the meaning of an empty result and the fact that no IDE is required. That is materially more than the annotations provide.

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?

Front-loaded with the core behavior and no filler sentences; each clause carries information. It is a dense single paragraph, and the trailing 'Needs no IDE' is the only bit that feels tacked on rather than essential.

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?

There is no output schema, and the description compensates by explaining what is returned (framework log lines, or up to 200 labelled raw entries) and what an empty result implies. An agent has everything needed to call it and interpret the response.

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

Parameters3/5

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

Schema description coverage is 100%, so both `seconds` and `process_name` are already documented with defaults, bounds, and naming rules. The description's mention of 'a debug run started by run_project, or a built app' lightly contextualizes process_name but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: returns recent System.DebugLog output of a Xojo app from the macOS unified log via `log show`. It is clear what comes back and under what circumstances (debug run via run_project, or a built app), but it never names the very similar sibling get_debug_log, so an agent must infer the boundary itself.

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?

Gives concrete operating context: use it for a debug run or a built app, prefer it over MessageBox for tracing, and if the result is empty add a System.DebugLog call and query again. It stops short of an explicit when-not-to-use or a named alternative among the siblings.

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