Skip to main content
Glama
brechanbech

xojo-mcp

by brechanbech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Search Documentation

search_docs
Read-onlyIdempotent

Search the local Xojo documentation by case-insensitive literal substring to find guides, tutorials, and API pages for concepts, how-tos, error messages, or uncertain class names.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
queryYesText to find, matched case-insensitively as a literal substring (e.g. 'JSONItem', 'prepared statement')
max_resultsNoMost excerpts to return. Default 5.
context_linesNoLines to include before and after each match. Default 10.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.7.1
    • changedInput schema / properties / context_lines / description
      Previous value: -"Lines before/after match to include"New value: +"Lines to include before and after each match. Default 10."
    • changedInput schema / properties / max_results / description
      Previous value: -"Max sections to return"New value: +"Most excerpts to return. Default 5."
    • changedInput schema / properties / query / description
      Previous value: -"Search term (e.g. 'JSONItem', 'database')"New value: +"Text to find, matched case-insensitively as a literal substring (e.g. 'JSONItem', 'prepared statement')"
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds substantial context beyond them: results are unranked document order, excerpts carry section titles and '>>>' markers, multi-word queries must appear verbatim, and the tool reads installed docs and fails if none was found. This is exactly the behavioral detail an agent needs before invoking it.

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?

Front-loaded with the core action and search semantics, followed by return format, query guidance, sibling routing, and environment requirements. Every sentence contributes a distinct operational fact 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 fully explains the return shape (ordered excerpts, section headings, marked matching lines) and the no-match case. It also covers the environment prerequisite, leaving nothing material for an agent to guess.

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 the baseline is 3, but the description adds real meaning: query is a verbatim literal substring, multi-word phrases must match exactly, and max_results governs excerpt count. It says nothing extra about context_lines, which is left entirely to the schema, so it falls just short of a 5.

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?

States a specific verb and resource ('Searches the full text of the local Xojo documentation') plus the exact matching semantics (case-insensitive literal substring). It explicitly distinguishes itself from the sibling lookup_class, so an agent can choose between them without opening either schema.

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?

Gives explicit when-to-use cases ('concepts, how-tos, error messages, or a class whose name you are unsure of') and names the alternative with its selecting condition ('when you know the name, lookup_class returns its reference page directly'). It also preempts a common misread by saying 'No match is a normal result, not an error.'

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